본문으로 이동

기능 요구사항

한울위키, 우리 모두의 백과사전.
imported>TedBot님의 2025년 8월 12일 (화) 07:20 판 (봇: 틀 이름 및 스타일 정리)
(차이) ← 이전 판 | 최신판 (차이) | 다음 판 → (차이)

소프트웨어 공학시스템 공학에서 기능 요구사항(Functional requirement)은 시스템 또는 그 구성 요소의 기능을 정의하며, 이 기능은 입력과 출력 사이의 동작에 대한 요약(또는 명세나 진술)으로 기술된다.[1]

기능 요구사항에는 계산, 기술적 세부사항, 데이터 조작 및 처리, 그리고 시스템이 수행해야 할 기타 특정 기능이 포함될 수 있다.[2] 동작 요구사항은 시스템이 기능 요구사항을 사용하는 모든 경우를 설명하며, 이는 유스 케이스에 기록된다. 기능 요구사항은 "품질 요구사항"으로도 알려진 비기능 요구사항에 의해 뒷받침되며, 이는 설계 또는 구현에 제약(예: 성능 요구사항, 보안 또는 신뢰성)을 가한다. 일반적으로 기능 요구사항은 "시스템은 <요구사항>을 수행해야 한다"는 형식으로 표현되는 반면, 비기능 요구사항은 "시스템은 <요구사항>이 되어야 한다"는 형식을 취한다.[3] 기능 요구사항 구현 계획은 시스템 설계에 상세히 기술되고, 비기능 요구사항은 시스템 아키텍처에 상세히 기술된다.[4][5]

요구공학에서 정의된 바와 같이, 기능 요구사항은 시스템의 특정 결과를 명시한다. 이는 비용 및 신뢰성과 같은 전반적인 특성을 명시하는 비기능 요구사항과 대조된다. 기능 요구사항은 시스템의 애플리케이션 아키텍처를 주도하는 반면, 비기능 요구사항은 시스템의 기술 아키텍처를 주도한다.[4]

어떤 경우에는 요구사항 분석가가 기능 요구사항 집합을 수집하고 검증한 후 유스 케이스를 생성한다. 기능 요구사항 수집 및 변경의 계층은 광범위하게 말하면 다음과 같다: 사용자/이해관계자 요청 → 분석 → 유스 케이스 → 통합. 이해관계자는 요청을 하고, 시스템 엔지니어는 요구사항의 측면을 논의하고 관찰하며 이해하려고 시도하고, 유스 케이스, 개체 관계 다이어그램 및 기타 모델이 요구사항을 검증하기 위해 구축되며, 문서화되고 승인되면 요구사항이 구현/통합된다.[6] 각 유스 케이스는 하나 이상의 기능 요구사항을 통해 동작 시나리오를 보여준다. 그러나 분석가는 종종 유스 케이스 집합을 도출하는 것으로 시작하며, 이를 통해 분석가는 사용자가 각 유스 케이스를 수행할 수 있도록 구현해야 하는 기능 요구사항을 도출할 수 있다.

과정

일반적인 기능 요구사항은 고유한 이름과 번호, 간략한 요약 및 근거를 포함한다. 이 정보는 독자가 요구사항이 왜 필요한지 이해하고 시스템 개발 과정에서 요구사항을 추적하는 데 도움이 된다.[7] 요구사항의 핵심은 명확하고 읽기 쉬워야 하는 필수 동작에 대한 설명이다. 설명된 동작은 조직 또는 비즈니스 규칙에서 비롯될 수도 있고, 사용자, 이해관계자 및 조직 내 다른 전문가와의 도출 세션을 통해 발견될 수도 있다.[7] 많은 요구사항이 유스 케이스 개발 중에 발견될 수 있다. 이 경우 요구사항 분석가는 이름과 요약을 포함하는 임시 요구사항을 생성하고, 나중에 더 잘 알려지면 채워질 세부 사항을 연구할 수 있다.

같이 보기

각주

  1. Fulton R, Vandermolen R (2017). 〈Chapter 4: Requirements - Writing Requirements〉. 《Airborne Electronic Hardware Design Assurance: A Practitioner's Guide to RTCA/DO-254》. CRC Press. 89–93쪽. ISBN 9781351831420. 2018년 6월 15일에 확인함. 
  2. 〈Supplement 4-A, A Procedure for Requirements Analysis〉. 《Systems Engineering Fundamentals》 (PDF). United States Government US Army. 2001. ISBN 978-1484120835. 2017년 1월 31일에 원본 문서 (PDF)에서 보존된 문서. 2016년 3월 18일에 확인함. 
  3. Loucopoulos, P. (2005). 〈Chapter 4: Requirements Engineering〉. Clarkson J, Eckert C (편집). 《Design Process Improvement: A Review of Current Practice》. Springer-Verlag. 116–139쪽. ISBN 9781846280610.  밴쿠버 양식 오류 (도움말)
  4. Adams, K.M. (2015). 〈3.2 Definitions for Functional and Non-Functional Requirements〉. 《Non-functional Requirements in Systems Analysis and Design》. Springer. 45–50쪽. ISBN 9783319183442. 
  5. Jönsson P, Lindvall M (2006). 〈Chapter 6: Impact Analysis〉. Aurum A, Wohlin C (편집). 《Engineering and Managing Software Requirements》. Springer Science & Business Media. 117–42쪽. ISBN 9783540282440. 
  6. MITRE Corporate Communications and Public Affairs. 〈Requirements Engineering: Eliciting, Collecting, and Developing Requirements〉. 《The MITRE Systems Engineering Guide》. MITRE Corporation. 304–13쪽. ISBN 9780615974422. 2018년 6월 15일에 확인함. 
  7. Stellman, Andrew; Greene, Jennifer (2005). 〈Chapter 6: Software requirements〉. 《Applied Software Project Management》. O'Reilly Media. 97–130쪽. ISBN 9780596553821. 2018년 6월 15일에 확인함.