블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 

'요구 사항 정의'에 해당되는 글 2

  1. 2013.11.13 요구 사항 정의 기법
  2. 2011.12.05 요구 사항 정의 프로세스도 변경해야...
 

요구 사항 정의 기법

아키텍쳐 | 2013.11.13 00:47 | Posted by 조대협


1. Feature를 정의하는 것을 목표로 한다.

2. Level 2~3 수준에서 Feature를 정의하고 내용을 Detail 쪽에 서술한다.

3. 스토리 기반으로 리뷰를 하면서, Feature를 합치거나 나눠본다. 기준은 스토리 기반으로 리뷰를 했을 때 흐름이 끊어지지 않아야 하며, UX 디자이너가 스스로 디자인을 그릴 수 있는 수준이 되어야 한다.

4. 전반부에는 최대한 디테일한 내용으로 해서 Feature들을 세분화 한후

5. 후분부에는 디테일 내용을 합쳐가면서 Feature로 리스트 업한다. 그리고 디테일한 내용은 Feature로 정의하지 않고 Feature의 detail description에 서술하는 전략을 사용한다.



기존의 개발 프로세스에서는 요구 사항을 받아서 개발하는 형태였는데, 이 요구 사항이 완벽하지 않다는 것은 누가나 알고 있고, 이를 전재로 해서, 변경 가능한 요구 사항을 기반으로 개발하는 프로세스가 애자일 프로세스 이다.
관리 관점 뿐만 아니라, 요구 사항을 수집하는 관점도 변화가 필요한데

요구 사항은 고객이 정해주는 것이 아니라, 스스로 정하는 것이다.
고객에게 요구 사항을 받은 것이 완벽하다고 판단하지 말고, 요구 사항이 부족한 부분은 Develop하고, 완벽하게 만들어 나갈것. 즉 고객이나 다른 사람에게 요구 사항 정의에 대해 의존하지 말고, 커뮤니케이션, 가정, 레퍼런스를 통하여 스스로 요구 사항을 정리할 수 있도록 해야 한다.
완벽하지 않은 요구 사항에 대해서는
1. 고객에게 요구 사항을 커뮤케이션을 통해서 물어볼 것.
2. 고객의 요구 사항이 확실하지 않다면, 유사 레퍼런스를 통해서 요구 사항을 정의하여, 고객과 협의한다.
3. 또는 요구 사항을 가정하되, 가정의 원칙을 고객의 비지니스 밸류(가치)를 우선으로 한다.

요구 사항은 변경이될 수 도, 바뀔 수 도 있다. 그러나 원칙이 되는 것은 고객이 얻고자 하는 비지니스 밸류가 되어야 하며, 개발팀 역시 고객의 비지니스를 이해하고 이를 통해서 요구 사항을 함께 정의해야 한다. 최고의 요구 사항은 "고객의 비지니스 가치이다."

요구 사항의 정의 기법은 Scrum UserStory나 다른 기법에서도 여러 방법으로 표현하고 있지만, 요약해보면
적절한 요구 사항 정의는,
"누가? 왜? 이 행위를 원하는 것이며" - Who & Why
"이 행위의 결과로 얻을 수 있는 비지니스 가치는 무엇인가" - What
그리고, "이 비지니스 가치를 얻기 위해 하는 행위가 무엇인가가 명확하게 정의되어야 한다" - How