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

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

 

지난 포스팅이었던 요구사항정의서 작성하는 법에 이어서, 오늘은 잘 쓰는 요령을 따로 작성해보려고 한다.

 

지난 요구사항정의서 작성법이 궁금하다면, 아래 링크를 참고하기 바란다.

2024.08.27 - [슈르의 오피스라이프/SI 이야기] - [SI이야기][산출물] 요구사항정의서 작성하기

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

 

우선, 요구사항정의서 작성에 포스팅을 두 개나 쓰는 이유는 다른 산출물과는 달리 요구사항정의서는 프로젝트 끝날 때까지 관리하는 산출물이기 때문이다.

 

요구사항정의서의 생명주기(?)를 설명하자면, 분석 단계에 요구사항정의서를 처음 쓰게 된다. 이때 고객과 합의한 요구사항은 베이스라인이 되고 버전 1.0이 찍힌 그 순간부터 상호 간에 합의한 업무 범위라는 게 생기게 된다. 그렇다면 분석 단계에 정의한 요구사항을 프로젝트 끝날 때까지 잘 개발하면 되느냐? 꼭 그렇지만은 않다. 프로젝트가 길면 길수록, 크면 클수록 생각은 바뀌고, 몰랐던 새로운 변수들이 나오기 때문에 바뀌거나 추가될 수밖에 없다. (요구사항도 CRUD가 있다는 사실! 반농담 반진담)

 

단순히 요건의 설명이나 구현방식이 살짝 변경되거나 삭제되는 거라면 산출물 현행화하는 수준으로 끝날 수 있다.(물론 이 변경도 그 근기를 뒷받침해 줄 수 있는 증적, 즉 회의록이 같이 남겨져야 이상적이다.) 하지만 요구사항은 추가가 된다. 추가되지 않은 건 본 적이 없다. 그리고 한 개 추가되는 걸로 끝나는 법은 없다. 이런 것들이 한 건, 한 건이 발생할 때마다 고객사와 수행사 양사가 모두 예민해지게 된다. (물론, 고객님이 이긴다.)

 

즉, 내가 하고 싶은 말은 아무리 목숨 걸고 베이스라인을 분석 단계에 그으려고 해도 요구사항정의서는 계속 변화하기 때문에 요구사항을 완벽하게 freezing 하는 것은 불가능하다는 것이다. 

 

그렇다면 어떻게 해야 요구사항정의서를 잘 쓰는 게 될까? 개인적으로 터득한 요령은 다음과 같다.

 

1. (나중에 알고 보니 틀린 내용이었어도 좋으니) (나에게 유리하게) 자세하게 써라.

 

요구사항은 요구사항명과 세부 설명을 쓰게 되어있다. 어느 양식을 봐도 무조건 쓰게 되어있다. 차이가 발생하는 건 그 안에 내용을 어떻게 쓰느냐에 있다. 산출물 쓰기 싫어하는 사람들은 단순히 '로그인'이라는 요구사항을 작성해도 '사용자 로그인 기능을 제공한다'라고 쓴다.(실제로 지난 포스팅을 보면 예시가 그렇게 되어 있다.) 

 

하지만, 잘 쓰는 방법은 그 내용을 최대한 상세하게 쓰는 것이다.

 

잘 생각해 보면 로그인 방법도 한 가지가 아니다. ID/PW일 수도 있고, SSO일 수도 있고, 카카오계정, 구글 등 방법으로도 로그인을 제공할 수 있을 것이다. 고객은 다양한 방법을 제공할수록 좋으니 그 '사용자 로그인 기능을 제공한다'라는 표현에 그게 다 포함되어 있다고 생각할 수 있다. 설령 당시에는 고객이 ID/PW만 이야기했다고 해도, 그게 근기로 없다면 방어할 수 있는 방법은 없다.

 

그렇기 때문에 요구사항 설명에는 제공하는 로그인 방식을 다 적어야 한다. 예를 들면 이런 식이다.

 

예1 : 사용자에게 ID/PW 방식의 로그인 기능을 제공한다

예2 : 사용자에게 로그인 기능을 제공한다. 로그인 방식은 ID/PW, SSO 방식 두 가지이며 SSO 인증 처리는 고객사에서 제공해 주는 모듈을 활용한다.

 

예2의 경우는 고객이 제공해줘야 하는 요건까지도 정해서 적어버리는 것이다. 만약에 고객이 '아.. 그땐 될 줄 알았는데요, SSO 모듈도 개발을 해야 해요'라고 말하면 수행사는 당당하게 '오~ 노노~ 요구사항정의서 보세요. 고객사에서 제공해 주는 걸로 협의하셨잖아요. 저흰 그걸 가정하고 공수를 산정해서 일하고 있는걸요. SSO까지 우리가 하면 추가로 공수가 발생해서 못해요.'라고 대답할 수 있게 된다. 실제로 저렇게 말한다고 해서 고객이 접어주냐 하면 그렇진 않지만, 합리적인 고객은 정말로 자기가 하거나, 다른 요건을 빼주거나, 추가 계약을 통해서 해주기도 한다. ^^

 

물론 요구사항정의서의 요건은 다 테스트 ID까지 물리게 되기 때문에 로그인방식이 복수개면 요구사항을 여러 개 따는 것도 방법이다. 그건 작성자의 요령이 필요하다. 요구사항 ID 하나에 테스트를 여러 개 해도 되지만, 개발자/이해관계자가 꼬일 수 있기 때문에 그게 통제 가능한 수준으로 묶어서 관리하는 걸 추천한다. ID/PW는 김 과장이 개발하고 SSO는 박대리가 개발한다면 두 개로 쪼개는 게 좋을 수 있다. 테스트 과정에서 오류가 발생하면 담당자가 추적이 명확한 게 좋다. 

 

 

2. (요구사항정의서 작성자가 개발하는 게 아니라면) 설명을 개발자 가이드 문서라고 생각하고 작성해라.

 

모든 요구사항이 로그인처럼 명확하진 않다. '로그인 알지? (찡긋)'했을 때 '오 알죠! 맡겨주세요!' 하며 개발하는 개발자를 찾는 건 아주 드물다. 오히려 그 반대의 상황이 많다. 개발자가 요구사항정의서를 보고 '저... 이게 뭘 해야 한다는 거죠?'라고 묻는 상황이 발생한다는 뜻이다. 개발자가 요구사항정의서를 쓰고 직접 개발까지 한다면 걱정은 조금 덜하지만, 자세하게 써야 명확해진다.

 

이게 명확해야 하는 이유는 개발하는 방식의 차이가 발생하기 때문은 아니고(그건 자유롭게 잘하시면 됩니다), 데이터 I/O에 대한 오해가 발생할 수 있기 때문이다. 어떤 데이터가 들어왔을 때 어떤 데이터를 돌려준다는 게 명확하지 않으면 쪼개서 여러 명이 개발하는 경우 그 오해가 발생하기 때문이다. 최소한 키값(기준값)이 뭔지 적는다든지, 이 로그인 기능인 경우 SSO라면 그냥 SSO 로그인을 처리한다.로 끝내지 말고 'SSO 인증 키값을 리턴한다'라는 식의 명확한 값을 정의해 주면 좋다.

 

이런 I/O가 정의가 지금 단계에서 되면 나중에 테스트할 때 시나리오나 예시 데이터를 뽑기도 쉽고, 혹시나 다른 데이터를 더 리턴해달라고 고객이 이상한 소리 하면 1번의 예시로 또다시 이야기해 볼 수 있다. (이거 보세요, 리턴 값이 A인데 B를 더 달라고 하시면.... 되니?! 합의했잖아!) 

 

 

3. 아직 변수명을 선언하지 말아라.

 

가끔 변수명이나 서비스명이나 화면명을 넣고 싶은 충동이 생길 때가 있다. '에이 설마 바뀌겠어~'하면서 넣는 경우들이 있는데 이건 절대 비추다. ID값은 설계가 끝나야 그나마 freezing이 되기 때문이다. 이건 바뀌면... 추적이 잘 안 되거나 산출물을 전체 현행화하는 아주 수고스러운 일을 하게 된달까... 그러니 일단은 명확한 단어 수준으로 써서 현행화 걱정 없는 용어로 쓰는 걸 추천한다. 그게 변경된다고 고객이 산출물 검수를 안 해주거나 하진 않지만, 매우 꼼꼼한 고객을 만나거나, 외부 감사 대상 프로젝트에 걸리면 무조건 현행화하게 된다. (지적사항으로 온다. '이게 뭐죠?'라고 하면서)

 

 

4. 요구사항정의서는 최대한 자세하게 고객과 이야기해서 합의를 해라.

 

개인적으로 너무 싫어하는 일이다. 요구사항을 하나하나 설명하고, 합의를 구하고, 질문에 대한 대답을 하고... 이 과정을 싫어하기 때문이라기보다 겨우 다 정리했는데 마지막 순간이어야 하는 때에 고객이 더 말하거나 바꾸거나 흔들까 봐 무서운 거다. 그러면 또 고쳐야 하니까... 가끔은 나도 그 멘탈이 안될 때가 많다. 

 

하지만 설명을 안 하고, 충분한 합의를 안 하고, 회의록도 없이 산출물 던지고 넘어가지기를 바라고 슬쩍 지나가면, 이 요구사항정의서는 프로젝트 끝날 때까지 변경된다. 왜냐, 누구도 제대로 commit 하지 않았기 때문이다. 

 

고객의 눈을 바라보고 설명하고 합의를 구해라. 설명하는 당신의 노력, 진심, 꼼꼼함에 감동해서라도 수긍하게끔. 그렇게 베이스라인을 긋고 시작하면, 분석 단계가 끝났을 때 프로젝트 지휘봉을 들고 있는 자신의 모습을 볼 수 있을 것이다.

 

요구사항은 그렇게 정의하는 것이다.

 

2024.10.29 23:31