요구사항 확인하기

폭포수 모델 : 계획 > 요구사항 확인 > 설계 > 구현 > 시험 > 유지보수

 

시스템의 개발, 변경의 목적을 식별하기 위해 이해관계자들의 요구를 이해 및 조정하여 체계적으로 수집, 분석, 명세화, 확인하여야 한다.

 

요구사항을 확인 안하고 시스템을 개발, 변경한다는 것은 상상 할 수 없다.

 

요구사항을 확인하기 위한 절차

 

도출 > 분석 > 명세서 > 확인

 

요구 사항 도출(Elicitation) : 많은 요구사항 중에서 제대로 된 요구사항은 요구사항 도출 기법(예: 인터뷰, 설문조사, 워크샵 등등)을 통해서 도출할 수 있다.

 

요구사항 분석(Analysis)  : 도출된 요구사항을 분석할 때 요구사항 분석 기법을 동원해서 해야된다.

 

온라인 게시판을 만들자면 기능적/비기능적 요구사항을 확인하면 충분했는데 이제는 소프트웨어가 커져서 이렇케만 분석해서 명세서를 만들면 나중에 Snowball Effect를 필연적으로 만나게 된다. 

 

① 분류 기준 : 기능적/비기능적, 요구사항 범위, SDLC(Software Development Life Cycle))

② 개념모델링 : 실존하는 문제에 대한 모델링이 소프트웨어 요구사항 분석의 핵심이며, 모델은 문제가 발생하는 상황을 설명할 수 있어야 한다. 실존하는 문제를 모델링하기 위해서는 UML(Unified Modeling Language)를 사용한다.

③ 요구사항 할당 : 요구사항을 만족시키기 위한 아키텍처 구성 요소 식별. 아키텍처의 구성 요소들과의 관계에서 추가적인 요구사항이 도출될 수 있다.

④ 요구사항 협상 : 복수의 이해관계자의 요구가 충돌하는 경우, 요구사항과 리소스, 기능과 비기능사항이 서로 상충되는 경우에 협의를 통해서 조정해야 한다.

⑤ 정형분석 : 형식적으로 정의된 Semantic을 지닌 언어로 요구사항을 정확하고 명확하게 표현.

 

UML은 나중에 다루지만 그 특징은 다음과 같다.

UML은 가구명문가이다. (가시화언어, 구축언어, 명세화언어, 문서화언어)

 

명세서(SRS:Software Requirement Specification) 작성 : 요구분석 단계의 요구사항과 스펙을 정리한 산출문서로서 소프트웨어 개발프로젝트의 중심이다. 요구사항명세서와 기능명세서가 기본 산출물이 되며, 이를 기반으로 여러 이해관계자를 위한 명세서가 만들어진다.

 

요구사항 확인 : 요구사항 명세서가 최초 정의된 요구사항에 부합하는 지를 감리한다. 감리방법은 요구사항검토, 프로토타이핑, 모델검증, 인수테스트 등이 있다.