기능사양서
Functional specification |
| 시리즈의 일부 |
| 소프트웨어 개발 |
|---|
시스템 엔지니어링 및 소프트웨어 개발에서 기능사양서(기능사양서, 사양서, 기능사양서(FSD), 기능사양서)는 시스템 또는 컴포넌트가 수행해야 할 기능(종종 요건사양의 일부)을 명시한 문서입니다(ISO/IEC/IEEE 24765-2010).[1]
이 문서에는 일반적으로 시스템 사용자가 필요로 하는 것 및 입력 및 출력(소프트웨어 시스템 등)의 요청된 속성이 설명되어 있습니다.기능사양서는 제품요건문서 'PRD'[citation needed] 등 요건문서에 대한 보다 기술적인 응답입니다.따라서 요건분석 단계의 결과를 취득합니다.보다 복잡한 시스템에서는 일반적으로 시스템 수준, 모듈 수준 및 기술 세부 수준 등 여러 수준의 기능 사양이 서로 중첩됩니다.
개요
기능 사양은 제안된 시스템의 내부 작동을 정의하는 것이 아닙니다. 시스템 기능이 구현되는 방법에 대한 사양은 포함되지 않습니다.
기능 사양의 기능 요건은 다음과 같습니다.
- 사용자가 OK(확인) 버튼을 클릭하면 대화 상자가 닫히고 이 대화 상자가 표시되기 전의 상태로 기본 창으로 포커스가 돌아갑니다.
이러한 요건은 외부 에이전트(사용자)와 소프트웨어 시스템 간의 상호 작용에 대해 설명합니다.사용자가 OK(확인) 버튼을 클릭하여 시스템에 입력을 제공하면 프로그램은 OK(확인) 버튼이 포함된 대화창을 닫고 응답합니다(또는 응답해야 합니다).
기능 사양 항목
목적
기능 사양에는 여러 가지 목적이 있습니다.팀 프로젝트의 주요 목적 중 하나는 소스 코드와 테스트 케이스를 작성하는 데 시간이 많이 걸리고 디버깅 기간이 경과하기 전에 프로그램이 무엇을 달성해야 하는지에 대한 팀의 합의를 얻는 것입니다.일반적으로 이러한 합의는 소프트웨어가 충족해야 하는 요건을 달성하기 위한 비용 효율적인 방법을 협상한 후 프로젝트에 대한 이해당사자의 1개 이상의 검토를 거쳐 이루어집니다.
과정
순서 있는 산업 소프트웨어 엔지니어링 라이프 사이클(워터폴 모델)에서 기능 사양은 구현해야 할 사항을 기술합니다.다음으로 시스템 아키텍처 문서에서는 선택한 소프트웨어 환경을 사용하여 기능을 구현하는 방법을 설명합니다.산업용, 프로토타입 시스템 개발에서 기능 사양은 일반적으로 요구사항 분석 후 또는 요구사항 분석의 일부로 작성됩니다.
기능 사양에 대한 합의가 이루어진 경우, 일반적으로 기능 사양은 "완전" 또는 "승인 완료"로 선언됩니다.그 후, 통상, 소프트웨어 개발 및 테스트 팀은, 기능 사양을 참조해 소스 코드와 테스트 케이스를 작성합니다.테스트가 실행되는 동안 프로그램의 동작을 기능 사양에 정의된 예상 동작과 비교합니다.
방법들
기능 사양서를 작성하는 일반적인 방법 중 하나는 간단한 와이어 프레임 또는 그래픽으로 설계된 정확한 UI 스크린샷을 그리거나 렌더링하는 것입니다.이 작업이 완료되고 화면 예제가 모든 이해관계자에 의해 승인되면 그래픽 요소에 번호를 매겨 화면 예제의 각 번호에 대한 지시 사항을 추가할 수 있습니다.예를 들어 로그인 화면에는 사용자 이름 필드 '1'과 비밀번호 필드 '2'가 있으며 각 번호는 소프트웨어 엔지니어가 사용하기 위해, 그리고 나중에 베타 테스트 목적으로 선언하여 기능이 의도한 대로 기능하는지 확인할 수 있습니다.이 방법의 장점은 화면 예제에 셀 수 없이 많은 추가 세부 정보를 첨부할 수 있다는 것입니다.
기능 사양의 예
소프트웨어 개발 사양의 종류
「 」를 참조해 주세요.
레퍼런스
외부 링크
| 필드 |  | ||||||
|---|---|---|---|---|---|---|---|
| 개념 | |||||||
| 오리엔테이션 | |||||||
| 모델 |
| ||||||
| 관련 필드 | |||||||
