요구사항_기획자 몸에 맞는 SRS

---

사전학습 ->> [SW요구사항] 요구 사항 작성이 어려울때 하나씩 파헤치기 (경험기반)

 

 

기획자도 작성할 수 있는 수준의 SRS 를 제안해 본다.

>> 템플릿 확인하러 가기

1. 표지 작성

[OOO] 요구사항 명세서, 작성(배포)일, 작성자 소속

2. 문서 확인

고객사와 개발사, 이해관계자들의 협의를 위한 공간

3. 문서 이력 

문서의 변경 이력을 작성한다.

4. 서비스 개요

목적, 범위, 용어, 사양(성능), 설계, 참고 문헌 정의

5. 상위 수준 요구 사항

6. 기능 요구 사항

7. 비 기능 요구 사항

8. 이슈 리스트 (optional)

 

아래 링크에서 위 목차의 템플릿을 확인할 수 있다.
>> 템플릿 확인하러 가기

SRS 작성 템플릿

 

 

 

 

상기 7개의 필수 항목과 1개의 옵션 항목만 작성하더라도 개발에 전혀 문제가 없다.

실제 요구 사항 작성에 대해 살펴보겠다.

 

[사전확인] - 요구 사항_수집?분석?정의?명세? 우선 펼쳐보자

 

2.3. IA 기반의 사용자 시나리오를 작성

IA와 같은 시트에 작성하여 빠르게 수정, 작성을 할 수 있도록 했다.

A열은 요구사항 수집 ID

B열은 (Who) Actor 모델

C열은 (What) 데이터 모델

D열은 (How) CRUD 행위

E열은 CRUD 행의의 상세

 

UML 툴을 잘 사용하다면 보기 좋게 나오겠지만.... 난 개발이 싫다.

Actor 들의 온라인 강의 시나리오

 

상위 수준 요구 사항은

요구 사항 분석 시 작성한 IA의 사용자 시나리오를 기반으로 작성한다.

(위 더 보기의 시트에서) B, C, D 열을 한 문장으로 작성하면 된다. 

기능 요구 사항 상세는

상위 요구 사항을 상속받아, E열의 항목을 상세히 작성해주면 된다.

 

요구 사항 작성에 몇 가지 원칙을 적용하길 원한다.

---

 

첫 번째, 상황 + 액션 + 결과를 포함시켜라.

- 참고 : 유저 스토리는 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 로 연결하길 추천한다.

중복 작성을 막고 일관성을 유지하는데 한결 도움이 될 것이다.

 

또한 일관성은 첫 번째, 두 번째, 세 번째 내용을 모두 포괄하고 있다.

문서는 나를 위한 것이 아니라 보는 사람을 위해 작성한다. 의사결정권자, 리뷰자, 개발자 등 문서를 보는 다양한 사람들이 다른 추측이나 생각을 하지 못하도록 일관되고 명확하게 작성되어야 한다.

 

 

 

EOD