요구 사항 정의 프로세스도 변경해야...

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

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

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

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