Software Requirement - Part 1

Software Requirement에 대해 차근차근이 알아보려고 한다. (공부할겸..)

프로젝트를 시작할 때, 가장 중요한 것은 "무엇을 만드냐" 이다. 물론 토이 프로젝트로서 재미삼아 만들어 볼 순 있지만 그건 개인에 한정된 부분인 것이고 회사로 넘어가게 되면 프로젝트 하나하나가 큰 시간과 비용을 소모하는 일이기에 프로젝트를 명세하고 진행하는 것이 중요하다.

때문에 무엇을 만들어야하는지 명세하기 위해 Requirement 즉, 요구 사항을 수집하고 정의하는 것이 필수적이다.

위 그림을 보면 프로젝트 요구사항을 피라미드 형태로 구분되어있다. 즉, Top-Down 형태로 아래로 내려갈수록 좀 더 세부적인 요구사항을 정의하게 된다.

(잠깐, 위 그림은 Business, User, System 3가지로 구분되어 있는데 Business, User, System, Software 4가지로 구분하기도 한다.)

여기서 Business에 대해 알아보면,

- 조직의 성장과 연속성 공헌

- 재정 목표 충족

- 개인 목표 충족

- 사원에 대한 책임 충족

- 사회적 책임 충족

- 정부에 대한 책임 충족

- 주주에 대한 책임 충족

- 시장 위치 충족

- 업무 프로세스 향상

- 제품의 품질과 명성 관리

- 환경적 요소 변화 관리

등등 이론적으로 구분하면 여러가지가 있을 수 있다. 그러나 이렇게 구분해보면 괜히 어렵게 느낄수 있기 때문에 간단히 생각해보면 이해관계자(stakeholder)의 요구를 충족시켜야 하는 것이 Business Requirement라고 할 수 있다. 

(물론 해당 프로젝트에 관여하는 이해관계자가 많을 경우 서로 원하는게 다를 수 있다. 그래서 각 요구사항간의 traedeoff를 고려하면서 Business 관점인 요구사항을 정의해야 한다.)

그러나 실제 프로젝트를 진행할 때 고민해야 봐야 하는 부분은 현재 요구 사항이 어느 부분에 해당하는지 파악해야 하는 것이다. 

Business 요구 사항을 수집하고 있는 시점에서 뜬금없이 "난 DB로 MySQL, MongoDB 등등을 쓰고 싶다" 라는 것은 관점을 벗어난 요구 사항이고, 해당 요구 사항은 Business, User가 정해진 이후 System의 세부 요구 사항에 해당한다. 

(물론 Business 단계에서 이해관계자 간에 수익을 위해 Google Cloud, AWS 등등을 써야 한다는 의사 결정이 이루어 질 순 있다.)

이후에 좀 더 알아보겠지만 Software Requirement는 결국 프로젝트가 올바른 길을 갈 수 있도록 Guide 한다고 할 수 있다. (회사의 모든 자원은 결국 돈으로 귀결되기에..)

Reference

- https://javarevisited.blogspot.com/2015/01/difference-between-functional-and-nonfunctional-requirements-software-development.html