[SI이야기][산출물] 요구사항정의서 작성하기

<DALL-E로 생성한 이미지> 요구사항정의서 쓰는 슈과장

 

SI 프로젝트에서 작성하는 산출물 중에서 가장 중요한 산출물은 요구사항정의서다. SI프로젝트 착수 후에 진행하는 분석 단계는 요구사항정의서를 작성하기 위해 진행한다고 생각하면 된다. As-Is를 분석하기 위한 모든 회의, 인터뷰, 자료 분석은 전부 다 정확한 To-Be를 그리고 그걸 요구사항정의서에 담기 위해서다. 그렇기 때문에 이 산출물은 아무리 작은 프로젝트를 수행해도 필수 산출물로 지정이 되고, 다른 산출물과 달리 이 산출물은 검수하는 순간까지 열어보고 다시 열어보고 또 확인하게 되는 산출물이다. 그 요구사항정의서를 쓰는 법에 대해 이야기해 보겠다.

 

우선, 요구사항정의서는 아래의 내용이 들어간다. (예시)

요구사항 ID	유형	요구사항명	요구사항 설명	우선 순위	작성자	작성일	비고
REQ-001	기능	사용자 로그인	사용자는 시스템에 로그인할 수 있어야 한다.	높음	홍길동	2024-08-26
REQ-002	비기능	시스템 응답 시간	시스템은 2초 이내에 응답해야 한다.	중간	이순신	2024-08-26
REQ-003	기능	비밀번호 변경 기능	사용자는 비밀번호를 변경할 수 있어야 한다.	높음	성춘향	2024-08-26
REQ-004	비기능	데이터 암호화	모든 데이터는 AES-256 암호화로 저장되어야 한다.	높음	홍길동	2024-08-26
...	...	...	...	...	...	...	...

 

각 항목별로 적어야 하는 내용은 다음과 같다.

 

1. 요구사항 ID : 각 요구사항 별로 고유하게 부여하는 식별값

 

요구사항 ID에서 중요한 건 내용을 보지 않고도 이게 어느 영역에 해당되는 요구사항인지 알 수 있어야 하고, 요구사항의 단위가 너무 크지도, 작지도 않아야 한다는 것이다.

 

은행 업무로 예를 들면 수신, 여신, 카드, 외환이라는 업무가 이번 구축 범위라고 했을 때 각 업무별로 ID 채번 규칙을 만들어주는 것이다. 수신은 SS, 여신은 YS, 카드는 CD, 외환 FX 등 의 형태로 만들어서 REQ-SS-001의 형태로 적는 것이다. 이렇게 하면 영역별로 요구사항을 적어서 줬을 경우 단순히 복사 붙여 넣기를 해서 취합했을 때 번호가 밀리거나 꼬이는 불상사를 방지할 수 있다. 요구사항 채번 번호는 세 자릿수(000) 면 대체로 다 수용이 된다. 만약 그것보다 더 필요한 것 같다면 네 자릿수로 만들지 말고 가운데 체계를 더 구체적으로 잡는 걸 추천한다. 여신도 개인여신, 기업여신이 있다고 하면 YSC, YSB 등의 형태로 하는 것이다.

 

물론 이 채번 규칙은 요구사항정의서를 작성하기 전에 품질관리자가 체계를 잡아서 공지를 해줘야 한다. 갑자기 세분화한다는 신묘한 상황이 발생하고 있다면 뭔가 비효율적으로 진행하고 있다는 것이다.

 

 

2. 요구사항 유형: 기능 요구사항, 비기능 요구사항 등 요구사항의 유형 구분

요구사항 유형이 작성하면서 정말 헷갈리는 부분이다. 갑자기 템플릿을 받았는데 '기능' '비기능'을 써야 하는 걸 보면서 질문을 하게 되어있다. ''기능'은 뭐고 '비기능'은 뭐죠?'라고... 

 

간단하게 설명하면 나중에 그 요구사항이 충족되었는지 알기 위해 테스트를 1 아니면 0으로 할 수 있냐 없냐를 구분하는 기준이라고나 할까. 요구사항 1을 테스트할 때 'ID/PW를 입력하면 로그인이 된다'라고 테스트가 가능하다면 기능이다. 하지만 구축하는 시스템의 응답 시간이 2초 이내여야 한다는 건 1 아니면 0의 테스트로는 진행이 안 되는 성능 요구사항이다. 그래서 이런 경우는 비기능으로 따로 구분해서 관리하게 되어있다. 

 

즉, 기능/비기능을 구분할 때는 단위/통합테스트 대상으로 넣을 수 있냐 없느냐로 구분하면 될 것 같다. 저런 구분이 없다면 그냥 순서대로 다 확인을 하면 되긴 하지만, 요즘은 저 요구사항 구분에 따라 뒤로 추적/관리/테스트하는 다 다르기 때문에 처음에 잘 구분하는 게 좋다. (애매한 요구사항이 나오면 유리한 쪽으로 넣는 게 현명하다.)

 

 

3. 요구사항명: 요구사항의 간단한 제목 또는 명칭

요구사항 이름이다. '사용자 로그인'과 같이 이름만 봤을 때 어떤 요구사항인지 알 수 있는 게 핵심이다. 

 

 

4. 요구사항 설명: 요구사항에 대한 상세한 설명 및 구현 필요 사항

요구사항명을 썼으면, 그 이름만으로 알 수 없는 내용을 상세하게 설명해 주는 부분이다. 한 줄로 끝날 때도 있고, 구체적으로 구현 내용을 작성하기도 한다. 어느 수준으로 작성할지는 작성자의 재량이다.

 

작성할 때 중요한 건, 요구사항을 어떻게 얼마나 쓰는 게 나에게 유리한 지를 잘 생각하고 써야 한다. 고객이 원하는 내용이 다 담겼다는 걸 알려주기 위해, 때로는 고객이 IT의 이해가 너무 적기 때문이 잘 풀어서 쓰기 위해 자세하게 작성하기도 한다. 하지만 중요한 건 수행사 입장에서 현재 협의된 버전이 좋을 때 자세하게 적는 것이다. 그래서 고객이 신박한 아이디어를 내면서 같은 요구사항의 구현 사항을 달리 말할 때 freezing 되어 있는 요구사항정의서를 꺼내서 협의를 하는 것이다. 단순히 OK 해서 바꿔줄 수 없는 이유를 산출물의 탓으로 돌리는 것이다. 하지만 이 예시는 자주 발생하는 일은 아니니, 이 상황에 대한 가능성을 크게 고려할 필요는 없다. 그저, 요구사항정의서를 나에게 유리하게 써야 한다는 사실을 알아야 줬으면 좋겠다.

 

 

5. 우선순위: 요구사항의 중요도에 따른 우선순위 (높음, 중간, 낮음 등)

요구사항정의서에 있어서 하긴 하는데, 개인적으로 이 우선순위가 크게 프로젝트에 영향을 준 적이 없다. 추측으로는 이후에 뭔가 문제가 생기거나, 선택과 집중을 해야 하는 상황이 생긴다면 이 우선순위가 큰 고려사항이 될 듯한다. 근데 요구사항을 포기하거나 양보해 준 고객사를 본 적이 거의 없기 때문에.... 다 중요하다.

 

 

6. 작성자: 해당 요구사항을 작성한 사람의 이름

이건 작성자 하나만 넣는 경우도 있고, 요구사항 낸 사람을 추적하기 위해서 고객의 이름과 수행사 담당자 이렇게 두 가지 정보를 모두 담는 경우가 있다. 개인적으로는 둘 다 넣는 경우를 더 많이 봤다. 작성자만 넣는 경우는 고객 담당자가 너무 적어서(1~2명) 이런 걸 추적하는 상황이 발생하지 않은 경우이다. 보통은 담당부서(고객), 담당자(고객), 작성자(SI) 이렇게 쓴다.

 

 

7. 작성일자: 요구사항이 작성된 날짜

작성일자는 그 요구사항이 나온 날짜를 적는다. (분석단계 내내 우리는 요구사항을 모으고 있었다는 사실을 잊지 말자...) 그래서 작성일자는 협상일, 회의일 등 그 이야기가 나온 날짜로 적는다. 하지만 그런 게 중요하지 않은 경우가 대다수라, 대부분 산출물이 작성된 날짜로 들어가는 게 보편적이다. (나중에 요구사항이 추가되면 이 날짜가 중요해진다.)

 

 

8. 비고: 추가적인 메모나 참고 사항

이 비고는 다양한 용도로 쓰지만, 가장 좋은 용도는 근기를 남기기 위한 비고로 쓰는 게 제일 좋다. 모든 요구사항이 근기가 없을 수 있어서 비고로 두고 채우는 경우도 있고, 근기라는 컬럼을 만들어서 관리하는 곳도 있다.

 

그 요구사항이 나온 RFP, 협상회의록, 회의록, 인터뷰결과서 등을 하나하나 다 맵핑해서 적어주는 것이다. 그래서 나중에 '이 요구사항은 뭐지? 언제 나온 거지? 누가 말한 거지? 뭔 내용이지?'라는 궁금증이 생겼을 때 참고할 수 있는 문서를 알려주는 길라잡이 같은 역할을 하는 것이다. 그래서 모든 요구사항은 보통 다 근기가 있다. 만약 근기도 없는 요구사항을 적고 있다면, 수행사의 입장에서 쓰는 게 아니다. 손해 보는 장사를 하고 있는 것이니, 근기가 없다면 고객도 근기가 없는 것이니 지워버려라.

 

 

일반적인 요구사항정의서 작성 내용에 대해서 설명했다.

다음에는 요구사항정의서를 잘 쓰는 법에 대해서 이야기하겠다. ^^

 

2024.08.26 23:58