요구사항 개발 프로세스

 

 

요구사항이란?

원하는 서비스에 대한 설명 및 운영에 필요한 계약조건

 

• 모든 개발은 요구사항을 기본으로 하고 소프트웨어 개발시에 클라이언트가 이런 기능 있었으면 좋겠다 이런거 필요하다 요구 하는 요구사항등을 적어서 문서화하는 것을 말한다.
• 사용자 요구의 타당성을 조사하고 비용과 일정에 대한 제약을 설정한다.
• 사용자의 요구를 통해 목표를 정한다.
• 사실상 소프트웨어 개발의 첫 단계이기 때문에 매우 중요하다.

 

요구공학(Requirements Engineering) 개념

사용자의 요구가 반영된 시스템을 개발하기 위해 사용자 요구사항에 대한 도출, 분석, 명세, 확인 및 검증을 하는 구조화된 활동

 

그러니까 만약 A라는 회사에서 시스템 개발의뢰가 들어 오면 일단 일단 A라는 회사가 현재 쓰고 있는 시스템 분석을 을 한다. 이게 앞에서 공부한 현행시스템 분석과정이다.

이 과정이 끝난 후에 요구사항들을 문서로 정리하는 개념이 요구공학(Requirements Engineering)이다. 

 

 

요구사항 확인하기 단계

ⓐ 보통 UML(요구사항을 확인하고 정의하기 위해 사용하는 도구)를 이용

https://moo-you.tistory.com/195

UML 클래스 다이어그램

 

ⓑ 요구사항이 개발하고자하는 소프트웨어에 미칠 영향에 대해서 검토

ⓒ UML에서 만들어진 분석 모델을 검증 한다.

ⓓ 분석모델의 기술적인 타당성을 분석한다.

ⓔ 분석모델 검증

 

 

 

 

요구사항 개발 프로세스

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

도출 Elicitation	- 소프트웨어가 해결해야할 문제를 이해하고, 고객의 추상적 요구에 대한 정보를 식별하고 수집 방법 결정, 수집된 요구사항을 구체적으로 표현 - 주요활동으로는 고객 분석, 조직 환경 분석, 후보 요구사항 분류, 후보요구사항 정제, 요구사항 소스 관리가 있다.	사용자한테 필요한 내용이 무엇인지 도출한다. 요구사항의 출처가 누구인지 어느 부서인지 어디에 있는지 파악 설문조사, 대화등 다양한 방법중 어떤 방법으로 수집할 것인지 결정
분석 Analysis	도출된 요구사항에 대해 충돌, 중복, 누락 등의 분석을 통해 완전성과 일관성을 확보하는 단계	도출된 자료를 분석해서 골라내는 것 이건 충돌한다. 이건 비용이 많이 든다 이런 여러가지 분석 작업을 거친다. 요구사항을 최적화할 수 있도록 한다. 분석 기법에는 : DFD, DD, Mini-Spec, ERD, UML등이 있다.
명세 Specification	체계적으로 검토, 평가, 승인될 수 있는 문서를 작성하는 단계	도출과 분석을 통해서 나온 내용들을 문서로 작석해서 명세서를 만든다. 이 때 명세서로 만들어진 내용을 작업을 하게 된다. (계약서 역할)
확인 Validation	분석가가 요구사항을 이해했는지 확인(Validation)하고, 요구사항 문서가 회사와 표준에 적합하고 이해 가능하며, 일관성있고, 완전한지 검증(Verification) 하는 단계	명세된 내용이 맞는지 검증을 해야 한다.

 

 

 

요구사항 도출 주요 기법

도출단계에서 고객의 요구에 대한 관련 정보를 식별 수집하는 방법이 여러개가 있다고 했는데 그 중 주요 도출기법을 확인해보자

인터뷰 (Interview)	이해관계자와 직접 대화를 통해 정보를 구하는 공식적, 비공식적 정보 수집 방법 - 각 사용자들과 면담 인터뷰
브레인스토밍 (Brainstorming)	말을 꺼내기 쉬운 분위기로 만들어, 회의 참석자들이 내놓은 아이디어들을 비판 없이 수용할 수 있도록 하는 회의
델파이 기법 (Delphi Method)	전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 방법
롤 플레잉 (Role Playing)	현실에 일어나는 장면을 설정하고 여러 사람이 각자가 맡은 역을 연기함으로써 요구사항을 분석하고 수집하는 방법
워크숍 (Workshop)	단기간의 집중적인 노력을 통해 다양하고 전문적인 정보를 획득하고 공유하는 방법
설문조사 (Survey)	설문지 또는 여론조사 등을 이용해 간접적으로 정보를 수집하는 방법
프로토타입 (Prototyping)	사용자가 요구한 내용을 임시적으로 간단하게 만들어서 사용자 요구를 도출한다.

 

 

 

요구사항 명세 단계 주요 기법

사용자가 요구하는 요구사항을 받아 적어서 문서를 체계화해서 설계자 한테 넘겨주는 명세서를 작성하는 기법

비정형 명세 기법	사용자의 요구를 표현할 때 자연어를 기반으로 서술하는 기법	마음대로 하는 것 사용자가 충분히 알아들을 수 있도록 자연어를 기반으로 작성 상태, 기능, 객체 중심 서술 종류 : FSM, Decision Table, E-R, SADT 등
정형 명세 기법	사용자의 요구를 표현할 때 수학적인 원리와 표기법으로 서술하는 기법	수학처럼 공식이 정해진 것 어떤 특정한 규칙이나 룰 종류 : VDM, Z, CSP, CSS 등

 

 

 

요구사항 명세서 작성 원칙

명확성	각각의 요구사항 명세 내용은 하나의 의미만 부여한다.
완전성	기능, 성능, 범위, 제약사항등 모든 요구사항이 포함되어야 한다.
검증 가능성	요구사항의 충족 여부와 달성 정도에 대한 확인이 가능해야 한다.	프로그램은 어쨌든 오류가 있을 수 밖에 없고 검사는 당연히 있을 수 밖에 없고 검사는 미리미리 준비를 해야 한다.
일관성	요구사항의 내용 간 상호 모순이 없어야 한다.
수정 용이성	요구사항 변경 시 쉽게 수정 가능해야 한다.
추적 가능성	각 요구사항 근거에 대한 추적과 상호참조가 가능해야 한다.	문제의 원인을 추적가능해야 한다.
개발 후 이용성	시스템 개발 후 운영 및 유지보수에 효과적인 이용이 가능해야 한다.	나중에 새로운 시스템 만들때 재사용이 가능하도록 한다.