Architect 공부 6일차 - 요구공학 및 품질속성

요구 공학 ( Requirements Engineering )

- 시스템의 목적을 식별하기위해 요구사항을 파악하고 이를 검증 및 관리하는 일련의 활동들

- S/W 개발 프로세스와 생명주기가 맞춰가며 진행된다.

 

요구사항

- 요구 공학 프로세스로부터 생성된 시스템 서비스(기능)와 제약사항(비기능)에 대한 설명

 

요구공학 프로세스는 아래 순서대로 진행된다.

 

1) 타당성 분석

해당 시스템이 개발할 가치가 있는지, 가능한지에 대한 사전 논의

- 기술적, 경제적 관점, 일정, 운영 측면에서 검토한다.

 

2-1) 요구사항 도출

- 시스템을 통해 해결하고자 하는 문제를 찾아내는 것.

고객들도 자신의 진짜 요구사항이 뭔지 모르기 때문에 이를 찾아내는 여러 방법들이 존재한다. 

( 브레인 스토밍, 롤플레잉, 인터뷰, 워크샵 등등 )

 

ex)

. 브레인 스토밍을 통해 각 이해관계자들의 다양한 요구사항들이 1차적으로 생성되고

. 이 중에 일부를 채택하여 요구사항을 명세화한다.

. 해당 요구사항에 대해 다양한 이해관계자들이 어떻게 생각하는지

  논의하고 합의점을 찾아, 모두가 납득할만한 요구사항으로 수정

 

2-2) 요구사항 분석

- 요구사항 모델을 통해 이해 관계자들의 이해를 돕는다. 

 

모델링 방법

. 구조 분석

ㅁ DFD ( Data Flow Diagram )

ㅁ STD ( State Transition Diagram )

ㅁ ERD ( Entity-Relation Diagram )

 

. 유즈 케이스 분석

ㅁ UC ( Use Case Modeling )

 

. 비용 기준 접근 : ROI

. 계층화 분석법(AHP) : 여러 대안들을 계층으로 나누어 다방면에서 판단하기 위한 분석법

 

3) 요구사항 명세

요구사항들을 문서화 하는 작업.

요구사항은 크게 기능 , 비기능 요구사항으로 나뉜다.

 

. 기능적 요구사항 : 시스템이 어떻게 동작해야하는지에 대한 설명. 제공하는 기능

. 비기능적 요구사항 : 시스템에 부과되는 제약 조건(품질 속성). 시스템의 품질에 대한 판단

※ 도메인 요구사항 : 시스템의 도메인으로부터 오는 요구사항. 기능 비기능 둘 다 가능

 

QAS : Quality Attribute Senario

- 품질 속성을 만족하는지 확인하기위한 시나리오.

구체적인 상황과 수치로 표현되어 요구사항 충족 여부를 확인할 수 있어야한다.

 

QAW : Quality Attribute Workshop

- 초기부터 이해관계자가 참석하여 품질 속성에 대해 의논하는 것.

- QAS로 문서화 되고 우선순위가 부여된 QA를 얻을 수 있다. 

 

. 순서

ㅁ 각 요구사항 들에 대해 이해 관계자 별로 우선순위 부여

ㅁ 요구사항의 품질 속성 정의 ex : 보안성, 가용성, 신뢰성, 안정성, 유지보수성 등등

ㅁ 그에 맞는 시나리오 부여

ex:

Requirement-ID	QA_###
Category	관련된 Quality Attribute가 무엇인지 기술함 (예, Performance, Reliability, Security 등)
Source	Stimulus를 발생시키는 주체가 무엇인지 기술함
Stimulus	시스템에 입력되는 내외부 자극이 무엇인지 기술함
Artifacts	Stimulus의 영향을 받는 시스템의 내부 모듈, 컴포넌트, 혹은 시스템 전체
Environment	해당 Stimulus 발생시 시스템의 환경
Response	기술된 Environment에서 Artifact이 Stimulus를 받아들인 후 취하는 Action이 무엇인지 설명함
Response Measure	위의 Response의 정도를 측정하는 단위가 무엇인지 기술함 (예, 초당 데이터 처리량, 반응시간, 시간일 경우 hour, minute, second 여부 등)
Description	위에 기술된 Source로부터 Response Measure까지의 내용을 하나의 문장으로 요약해서 기술함

 

 

4) 요구사항 확인 및 검증

 

 

5) 요구사항 변경 관리