요구사항 문서에 대한 템플릿은 IEEE 표준 문서가 있지만 실무에서 사용하기는 번거롭고 가독성이 떨어진다. 그래서 회사별, 사람별로 다양한 요구사항 정의서를 가지고 있다.
우리가 흔히 보는 비즈니스 측면이 강조된 요구사항 문서는 대부분 PM 이나 기획자들이 작성을 할 것이다. 실제 개발에서 사용하는 요구사항 정의서는 선임 개발자나 아키텍트가 작성하여 BDD 에 유용하게 사용한다.
기획자도 SRS 쓸 수 있다.
1. 표지 작성
[OOO] 요구사항 명세서, 작성(배포)일, 작성자 소속
2. 문서 확인
고객사와 개발사, 이해관계자들의 협의를 위한 공간
3. 문서 이력
문서의 변경 이력을 작성한다.
4. 서비스 개요
목적, 범위, 용어, 사양(성능), 설계, 참고 문헌 정의
5. 상위 수준 요구 사항
6. 기능 요구 사항
7. 비 기능 요구 사항
8. 이슈 리스트 (optional)
상기 7개의 필수 항목과 1개의 옵션 항목만 작성하더라도 개발에 전혀 문제가 없다.
실제 요구 사항 작성에 대해 살펴보겠다.
상위 수준 요구 사항은
요구 사항 분석 시 작성한 IA의 사용자 시나리오를 기반으로 작성한다.
기능 요구 사항 상세는
상위 요구 사항을 상속받아 세부 태스크를 상세히 작성해주면 된다.
요구 사항 작성에 몇 가지 원칙을 적용하길 원한다.
첫 번째, 상황 + 액션 + 결과를 포함시켜라.
- 참고 : 유저 스토리는 Given When Then 에 맞춰 작성을 한다.
여기도 동일한 원칙을 적용하여 어떤 상황에서 어떤 행위를 하면 어떤 결과를 주는지는 명시하는 것이다.
필자는 (Screen - Action - Feedback) 이라고 원칙을 정했다.
=> A 화면(or 상태) 에서 Actor (or 시스템, 모델, 데이터) 의 행동에 의해 B 의 결과가 나타난다.
| 예시 |
| "사용자는 강사의 목록을 선택하여 강사의 상세 정보를 조회할 수 있어야 한다." => Screen : 강사 목록이 표시되는 위치 => Action : 특정 강사 목록을 선택 => Feedback : 강사의 상세 정보가 표시 |
| "사용자는 자신의 정보 상세를 조회한 상태에서 자신의 정보를 변경할 수 있어야 한다." =>Screen : 자신의 정보 상세 => Action : 정보 변경 => Feedback : 정보 변경 페이지로 이동 (결과 유추) |
| "사용자는 강의 목록을 강의 일시의 오름차순/내림차순으로 정렬하여 볼 수 있어야 한다." => Screen : 강의 목록이 표시되는 위치 => Action : 강의 시간의 정렬을 변경 => Feedback : 강의 목록의 정렬이 변경됨. (결과 유추) |
두 번째, 능동형, 수동형의 문장 구별해서 작성하라.
능동형은 주어 즉, Actor 기반으로 풀어가는 문장이다. 위의 3개의 예시가 능동형 문장이 된다.
반면 수동형 문장은 능동의 행위의 결과에 따라 동작되는 요구사항들을 작성한다.
| 예시 |
| "변경 내용이 취소되면 변경된 정보를 삭제하고 이전 정보로 복원해야 한다." - 수동형은 Screen - Action - Feedback 원칙에 적용되지 않는다. - 이전 요구사항의 Feedback(결과) 에 따라 시스템적 행위가 이루어지는 부분을 다루게 된다. => 이전 요구 사항 : "사용자는 변경 안내를 확인하고 취소할 수 있어야 한다." |
| 다른 예시 A1 - "사용자는 변경 안내를 확인하고 완료할 수 있어야 한다." A2 - "변경이 완료되면 변경된 정보를 저장할 수 있어야 한다." A3 - "변경이 완료되면 이전 내용을 백업하여 저장할 수 있어야 한다." |
세 번째, 서술형의 문장의 원칙을 지켜라.
요구사항을 서술형으로 작성하는 가장 큰 이유는 행동을 명확하게 하기 위함이다.
기본적으로 "할 수 있어야 한다.", "해야 한다." 라는 가능형으로 작성을 권한다.
두 번째 원칙에서 수동형이 있기 때문에 무조건 가능, 능동형으로 작성할 수는 없다.
이에 따라 "되어야 한다.", "될 수 있다." 의 문장도 구사될 수 있다.
| 서술형 | 사용 사례 |
| ~ 할 수 있어야 한다. | Actor 의 행위를 설명할 때 |
|
~ 해야 한다. (~ 데이터를 ) 표시해야 한다. (~ 조건에서 ) 가능해야 한다. |
조건이 있을 경우나 반드시 되어야 하는 필수 항목에 사용 |
| ~ 되어야 한다. | Actor 의 행위의 결과로 인해 시스템에서 반드시 동작해야 하는 기능을 설명 |
네 번째, 일관성을 유지해라
이 글에서 설명하는 요구사항은 데이터 드리븐 형태로 작성되기 때문에 동일한 데이터를 다양한 상황에서 사용하게 된다. 이에 따라 기본 화면을 구성하는 목록 조회, 상세 내용 조회 부분에서 상황별로 다른 항목을 조회하여 표시하는 경우가 생긴다.
이 부분을 간과하고 작성하다보면, A라는 데이터가 있다 없다 하여 UI 설계하는 자가 혼돈을 겪게 된다.
머릿속으로나 별도 공간에 공통부분을 작성하여 Reference ID 로 연결하길 추천한다.
중복 작성을 막고 일관성을 유지하는데 한결 도움이 될 것이다.
또한 일관성은 첫 번째, 두 번째, 세 번째 내용을 모두 포괄하고 있다.
문서는 나를 위한 것이 아니라 보는 사람을 위해 작성한다. 의사결정권자, 리뷰자, 개발자 등 문서를 보는 다양한 사람들이 다른 추측이나 생각을 하지 못하도록 일관되고 명확하게 작성되어야 한다.
댓글