1. 요구사항 명세
- 분석된 요구사항을 명확하고 완전하게 기록하는 것
- 소프트웨어 시스템이 수행하여야 할 모든 기능과 시스템에 관련된 구현상의 제약 조건 및 개발자와 사용자가 합의된 성능에 관한 사항 등을 명세
- 최종 결과물: 요구사항 명세서(SRS: Software Requirement Specification)
2. 좋은 요구사항을 작성하기 위해서
1) Necessary
- 각 요구사항이 왜 필요한지가 명확하게 설명되어야 함. 제거되어도 시스템 비즈니스 목표가 달성하는 데 영향이 없으면 필요하지 않은 것
- Gold plating 방지 (금칠하는 것)
- Gold plating: 고객이나 이해당사자가 요구하지 않았는데도 개발자 스스로 고객에게 이득이 된다고 믿는 부수적이거나 장식적인 기능을 추가하는 것 -> 프로젝트의 비용 증가, 개발 일정의 지연 - 필요한지 상위 요구사항을 보고 결정(비즈니스 목표(요구사항) <- 사용자 요구사항 <- 기능 요구사항)
2) Implementation Free
- 요구사항에 불필요한 설계 및 구현 정보(제약)가 포함되지 않아야 함
- 특정 사용자 인터페이스에 컨트롤을 이용해서 구현하는 경우 X
-> 특정 구현 기술을 지정해버리면 다양하게 설계할 수 있는 대안들을 고려할 기회를 놓쳐버림
ex) 토핑 양식에 토핑 목록이 표시됩니다. 사용자는 토핑 옆에 있는 checkbox를 선택하여 베이글에 추가할 수 있습니다.
3) Unambiguous
- 요구사항은 하나 이상의 의미로 해석되지 않아야 함
ex) 시스템은 출발지에서 목적지까지 가장 좋은 길을 찾을 수 있어야 한다.
-> 가장 좋은 길은 다양하게 해석할 수 있음
4) Complete
- 각 요구사항을 이해하는데 필요한 모든 정보를 가지고 있어야 하며 발생할 수 있는 모든 조건에 대해 기술하여야 함
ex) 교수는 id, 비밀번호 및 관련된 정보를 이용하여 시스템에 로그인 할 수 있어야 한다.
-> 관련된 정보를 이메일 주소와 같은 정보로 명확하게 기술 필요
ex2) 프리미엄 약정이 선택되지 않고 보험 증명이 제공되지 않으면 사용자에게 기본 약정이 자동으로 선택되어야 한다.
-> 프리미엄 약정이 선택되고 보험 증명이 제공, 프리미엄 약정이 선택되지 않고 보험 증명이 제공, 프리미엄 약정이 선택되고 보험 증명이 제공되지 않을 경우에 대한 요구사항 기술이 필요
5) Atomic
- 각 요구사항은 여러 요구사항으로 분리되지 않아야 함
ex) 시스템은 항공권 예약, 항공권 구매, 호텔 객실 예약, 자동차 예약, 명소 정보 제공의 기회를 제공해야 한다.
-> 각각 5개의 요구사항으로 분해해 따로 기능해야 함
6) Feasible
- 요구사항은 비용, 일정과 같은 제약 내에서 기술적으로 실행 가능해야 함
7) Traceable
- 요구사항은 요구사항의 소스(출처) 및 요구사항으로부터 파생된 다른 시스템 구성요소(설계, 코드, 테스트 케이스) 등과 연결되어야 함
- RTM(Requirement Traceability Matrix) : 테스트 케이스와 함께 사용자 요구사항을 매핑하고 추적하는 문서
-> 요구사항이 변하게 되면 어떤 부분이 영향을 받는지 쉽게 찾을 수 있음
8) Verifiable
- 요구사항은 검증 가능하여야 함
ex) 시스템은 현재보다 시간당 더 많은 처리를 할 수 있어야 함
-> 판단이 어려움
9) 품질 속성을 검증 가능한 시나리오로
품질 속성 템플릿 6가지
- 소스(source): 자극을 생성하는 개체
- 자극(stimulus): 시스템에 영향을 주는 조건
- 대상 또는 산출물(artifact): 자극에 의해 영향받는 시스템(부분)
- 환경(envirnoments): 자극이 발생된 상황
- 반응(response): 자극으로 야기되는 시스템 행위
- 반응척도(measure): 시스템의 반응을 평가하는 척도
10) Consistent
- 다른 요구사항과 모순이 없어야 하며 동일한 개념을 다른 용어로 사용하여 기술하지 않아야 함(일관성)
11) NonRedundant
- 각 요구사항은 한번만 표현되어야 하며 다른 요구사항과 중복되어서는 안됨
3. SRS IEEE-STD-830
- 소프트웨어 요구사항 명세서 국제 표준
1.1 Purpose(목적)
- 무엇을 위해 이 문서를 작성했는지를 설명
- 제품의 용도를 나열하지 않도록 주의
- 개발하고자 하는 시스템의 목적이 아니라 문서의 목적을 설명해야 함
1.2 Scope(범위)
- 개발할 소프트웨어에 대한 설명
- 필요하다면 "비전과 범위 문서" 참조
- SRS 범위 부분 -> 어떠한 소프트웨어를 개발하는지 간결하게 드러나기 때문에 이 부분만 봐도 대략적으로 핵심을 짧은 시간에 파악 가능
- 단순하게 기능 나열 X
- 프로젝트 이해관계자와 개발자들이 프로젝트를 진행하면서 목표가 무엇인지 이해하게끔 작성해야 함
2.1 Product Perspective(제품 조망)
- 제품을 외부에서 바라본 모습 설명
- 제품이 신규인지 기존 제품을 대치하는 것인지 차기 버전인지를 기술
- 큰 시스템의 일부라면 큰 시스템과의 인터페이스 기술
- 배경도와 같은 다이어그램을 사용하여 제품과 외부 시스템과의 관계를 보여줄 수 있음
2.2 Product Functions(기능)
- 제품이 가지고 있는 주요 기능을 개략적으로 나타냄
- 서술형보다는 목록 형태로 요약해서 기본적인 흐름에 대해서만 간단하게 작성함
- 기능에 대한 상세한 내용은 3장에 기술
2.3 User Characteristics(사용자 특성)
- 이 제품을 사용할 것을 예상되는 사용자를 식별하고 그들의 특징을 기술함
2.4 Constraints(제약사항)
- 반드시 사용하거나 피해야하는 특정 기술, 프로그래밍 언어와 데이터 베이스
- 사용할 웹 브라우저 유형이나 버전
- 코딩 표준
2.5 Assumptions and Dependencies(가정 및 의존성)
- 프로젝트를 수행하기 위하여 필요하거나 반드시 수행 또는 결정도어야 할 전제 조건 또는 선행되어야 할 사항
- 이러한 가정이나 의존성에 문제가 발생한다면 프로젝트가 위험
-> 실제 프로젝트를 진행할 때 만날 수 있는 리스크를 대처하는 데 목적
3.1 외부 인터페이스 요구사항
3.1.1 사용자 인터페이스 요구사항
- 프로젝트가 따르는 UI 표준이나 가이드
- 웹 적합성: 모든 사용자가 신체적, 환경적 조건에 관계없이 웹에 접근하여 이용할 수 있도록 보장하는 것
- 웹 호환성: OS, 브라우저에 상관없이 유사한 화면으로 동일한 정보에 접근이 가능해야 함
- 도움말 버튼처럼 모든 화면에 나타나는 표준 버튼이나 기능, 탐색 링크
- 시스템과 사용자가 어떻게 상호 작용하는지 기술
- 사용자 인터페이스에 대한 상세 설명은 사용자 인터페이스 설계 등과 같은 다른 문서를 이용하여 기술할 수 있음
3.1.2 하드웨어 인터페이스 요구사항
- 외부 하드웨어 장비 유형
- 소프트웨어와 하드웨어 간의 상호 작용
** 용어 정리
- TBD(To-Be-Determined): 추후 결정하여 작성
- N/A(Not Applicable): 해당 사항이 없음
- None: 해당 사항이 있지만 하지 않는다.
3.1.3 소프트웨어 인터페이스 요구사항
- 데이터베이스, 외부 라이브러리, 도구, 운영체제, 외부 소프트웨어와의 통신 등에 관한 인터페이스를 기술
3.1.4 커뮤니케이션스 인터페이스(Commuications Interface) 요구사항
- 시스템에 필요한 전자 우편, 웹 브라우저, 네트워크 서버 통신 프로토콜 등 통신과 관련된 요구사항을 기술
- 통신 보안, 암호화 문제, 데이터 전송 속도 등을 기술
3.2 Functions(상세한 기능적 요구사항)
- 2.2절에서 언급한 기능을 상세하게 기술하거나 사용자 요구사항으로부터 추출된 기능적 요구사항을 기술
3.3 Performance Requirements
- 성능에 관한 요구사항
3.4 Logical Database Requirements
- 데이터 항목 및 데이터 간의 논리적 관계를 ERD 등으로 모델링
- 데이터 보관 및 삭제 요구사항
- 데이터를 얼마나 오래 보관하고 어떻게 폐기를 해야하는지를 기술
- 데이터를 오용하지 않고 적절한 보안을 유지하더라도, 정해진 기간을 넘겨 보관하는 것은 위반 행위
3.5 Software System Attributes
- 보안성, 신뢰성, 가용성 등과 같은 품질에 대한 요구사항 기술
