요구사항 개발 프로세스

1. 요구사항 개발 프로세스

• 요구사항 개발 프로세스는 개발 대상에 대한 요구사항을 체계적으로 도출하고 분석한 후 명세서에 정리한 다음 확인 및 검증하는 일련의 구조화된 활동이다.
• 요구사항 개발 프로세스가 진행되기 전에 타당성 조사(Feasibility Study)가 선행되어야 한다.

 

[도출(Elicitation)]  →  [분석(Analysis)]  →  [명세(Specification)]  →  [확인(Validation)]

 

 

타당성 조사(Feasibility Study): 개발 프로세스가 비즈니스 목적에 부합되는지, 혹은 예산은 충분한지 등에 대한 정보를 수집하는 것.

 

 

<여기서 Tip!>

시나공에선 이 개발과정을 "출 석 명 확"으로 외우는데  왜 이렇게 외우지???

이렇게 외우면 개념 이해도 못하고 막상 시험때 나오면 기억안난다. (ㄹㅇ 비효율 적이다.)

왜 이 순서인지 생각해 보면 그냥 머리에 박힌다.

 

1. 요구사항을 도출하고

2. 도출한 요구사항들 분석하고 (분별해서 걸러내는 과정도 있음)

3. 분석한 요구사항들 리스트로 작성하고

4. 작성한 요구사항들 검토하고!

 

생각해 보면 당연한 순서이다. 이제 세부 설명을 보자.

 

 

2. 요구사항 도출(Requirement Elicitation, 요구사항 수집)

•  요구사항 도출은 시스템, 사용자, 개발자 등 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항을 어떻게 수집할 것인지 식별하고 이해하는 과정이다.
• 개발자와 고객 사이의 관계가 만들어지고 이해관계자(Stakeholder)가 식별된다.
• 소프트웨어 개발 생명주기(SDLC) 동안 지속적으로 반복된다.

 

  <요구사항을 도출하는 주요 기법>

 

• 청취와 인터뷰
• 설문
• 브레인 스토밍 (3인 이상 자유롭게 의견을 교환하여 독창적인 아이디어를 도출해 내는 방법)
• 워크샵
• 프로토타이핑 (프로토타입을 통해 효과적으로 요구분석을 수행하는것)
• 유스케이스 (사용자의 요구사항을 기능 단위로 표현하는 것)

<여기서 Tip!>

도출기법인것과 아닌것을 고르라는 문제가 나올 수 있으니 외워놓자.

외우는 법은 "도출"을 할때 할만한 기법을 생각하면 된다.

그게아닌 설명이 필요한 기법은 눈에 익히면 된다.

 

그리고 "유스케이스" 이거 뒷 챕터에서 나온다. 요구사항 도출방법이란 걸 알아두자.

 

 

3. 요구사항 분석(Requirement Analysis)

• 요구사항 분석은 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정이다.
• 요구사항의 타당성을 조사하고 비용과 일정에 대한 제약을 설정한다.
• 서로 상충되는 요구사항이 있으면 이를 중재하는 과정이다.

 

 

  <요구사항 분석에 사용되는 대표적인 도구>

   (구조적 분석 기법)

• 자료 흐름도(DFD; Data Flow Diagram)
• 자료 사전(DD; Data Dictionary)
• 소단위 명세서(Mini - Spec)

 

<여기서 Tip!>

요구사항 정의 중 "분석" 파트는 다음챕터인 "요구사항 분석"  챕터에서  분석기법들의 여러 방법을 소개해 준다.

그중에는 구조적 분석기법인 자료흐름도와 자료사전 그리고 분석 도구인 CASE, HIPO 등 여러가지 분석기법들이 나온다.

이들을 연결해서 외워주면 더욱 정리가 잘 될 것이다. 

 

★ 다른 개념인것 마냥 관계없이 따로따로 외우면 한두개 쯤 무조건 기억 안난다.

★ 하지만 이렇게 챕터들과 연관성을 이해하면 분명 기억에 더 오래 남을 것이다.

 

4. 요구사항 명세(Requirement Specification)

• 요구사항 명세는 분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 것을 의미한다.
• 기능 요구사항은 전부 기술하고 비기능 요구사항은 필요한 것만 기술한다.
• 구체적인 명세를 위해 이전 과정인 "요구사항 분석"에서 사용되는 구조적 분석기법인 소단위 명세서(Mini - Spec)가 사용될 수 있다.

※ 소단위 명세서(Mini-Spec): 요구사항 분석의 구조적 명세기법 종류 중 하나이다.

 

5. 요구사항 확인(Requirement Validation)

• 요구사항 확인은 개발 자원을 요구사항에 할당하기 전에 요구사항 명세서가 정확하고 완전하게 작성되었는지를 검토하는 활동이다.
• 이해관계자들이 검토해야한다.
• 요구사항 관리 도구를 이용하여 요구사항 정의 문서들에 대해 형상 관리(SCM)를 수행한다.

 

6. 요구사항 명세 기법

요구사항을 명세하는 기법은 정형과 비정형 두 가지로 나뉜다.

 

  <정형 명세기법>

• 사용자가 이해하기 어려운 수학적 기호나 정형화된 표기법으로 작성된다.
• 요구사항을 정확하고 간결하게 표현할 수 있다.
• 작성자와 관계없이 일관성이 있어 완전성 검증이 가능하다.
• VDM, Z, PEtri-net, CSP 등이 있다.

 

  <비정형 명세기법>

• 자연어 또는 보기쉬은 다이어그램을 사용해서 내용의 이해가 쉬워 의사소통이 용이하다.
• 하지만 요구사항의대해 작성자에 따라 일관성이 떨어지고 해석이 달라질 수 있음.
• FSM, Decision Table, ER모델링, State Chart(SADT) 등이 있다.

<여기서 Tip!>

저번 챕터에서 말했듯이 이것도 "메타인지"이다. 아래처럼 외우자.

 

정형은 개발자들끼리 소통

비정형은 사용자, 의뢰자 들을 위한 소통

 

필자 생각회로) ER 다이어그램은 DB에서 배웠다.. ER모델은 DB 의뢰자도 이해하기 쉽게 작성하는 다이어그램이다. 

                         그럼 보기 쉬운건 비정형.. 어려운건 정형..