[소프트웨어공학] #4 Requirement Engineering

11/14, 11/16

4-1: Requirement Engineering

서비스를 설립하는 단계

-고객이 시스템에 원하는 것

-운영과 개발시의 제약조건

 

시스템 요구사항

-시스템 서비스에 대한 설명

- 요구사항 공학 단계 동안에 생성되는 제약조건

 

요구사항 범위

- 최고 수준으로는 서비스의 추상화 상태 or 시스템 제약사항

- 자세한 수학적 기능 명세

 

요구사항의 타입

-사용자 요구사항: 자연어와 다이어그램. 운영적 제약조건. 고객이 작성

-시스템 요구사항: 시스템의 기능, 서비스, 운영적 제약조건에 대한 자세한 서술. 어떤것이 구현되어야할지 정의. 고객과 contractor의 계약

 

Reader

사용자요구사항-client manager/system end-users/client engineers/contractor mangers/ system architects

시스템 요구사항- system end-users/client engineers/system architects/software developers

 

stakeholders(이해당사자): 시스템에 영향을 미치는 사람이나 조직

-end users/system managers/system owners/ external stakeholders

 

Agile

-빠르게 변화하는 요구사항에 대응

-문서화가 적음

-증분 , 'user stories'로 요구사항 표현

-가끔은 몇몇 팀들로 pre-delivery analysis나 system developed 

개발적인 내용. 소스코드의 이해를 도와라

 

4-2: Functional and non-funcitonal requirements

기능적 요구사항: 서비스와 직접 관련된 것들. 시스템이 무엇을 할지(what the system should do). 시스템 서비스에 대해 자세히 기술

비기능적 요구사항: 서비스나 기능의 제약조건.

도메인 요구사항: 특정 domain에서의 요구사항

 

요구사항의 부정확성

-요구사항이 정확한 상태가 아닐 때 발생.

-부정확하고 애매한 요구사항은 개발자와 사용자에게 다르게 해석될 수있음.

 

완전성(complete): 필요한 모든 기술 구상

일관성(consistent): 충돌/모순 X

 

비기능적요구사항: 시스템의 속성이나 제약을 정의

-reliability

-response time(응답시간)

-storage requirements(저장공간)

-constraints are I/O device capability

-system representations(시스템 표현)

-etc.

 

구현

비기능적 요구사항은 시스템의 전반적 구조에 영향을 준다

 

제품요구사항: product가 내포해야하는 부분.

조직 요구사항: 조직의 정책/절차

외부 요구사항: 나라나 사용자 관련

 

 

Goal을 통해 requirement를 보다 객관적으로 파악한다.

 

 

 

4-3: Requirements enginerring processes

RE는 어플리케이션 도메인에 다양하게 의존.

도출/분석/검증/관리

RE는 반복적인 활동.

 

spiral view of the RE process

4-4: Requirements elicitation

requirement discovery라고도 부름.

고객과 함께 일하는 기술자가 아래의 것들을 찾아냄

- 어플리케이션 도메인의 특징

- 제공할 서비스

- 운영에 대한 제약사항

 

Stakeholders(이해관계자, 이해당사자)

- end-user, 관리자, engineer 등등

 

stage에 포함

-발견 및 이해

-분류 및 구성

-우선순위 부여 및 협상

-구체화/문서화

 

문제점

-stakeholder 스스로 자기가 원하는 것을 모름

-요구사항을 그들 고유한 언어로 표현하려함.

-조직적/정책적 요소들이 시스템에 영향

-요구사항 변경

 

 

Process acctivities

발견 및 이해: stakeholder들과 소통하여 그들의 요구사항을 찾아냄. (domain 요구사항도 여기서)

분류 및 구성: 유사한 애들끼리 묶음.

우선순위 및 협상: 우선순위를 정하여 충돌을 해결

구체화/문서화: 문서화

 

discover

- 정보를 모으고, 정보에서 요구사항을 정제한다.

ex) 인터뷰등.(오픈된 질문을 해야함), ethnography(제 3자가 설명<-자기것을 잘 설명하지 못하기 때문)

스토리/시나리오(어떻게 시스템이 동작하면 좋겠는지) 그 외에도, 고객이 직접 발표하는것(도메인 지식 이해에 좋음), 문서 분석, 브레인 스토밍 등

 

4-5: Requirements specification(요구사항 명세)

요구사항을 기록한 문서

이해가능해야함.

-user-requirement는 기술적인 background 없어도 이해할 수 있게.

-system requirement는 좀더 자세하게.(기술적 정보)

계약의 기준점이 될 수 있음.

 

명세를 쓰는 방법

자연어: 사람이 쓰는 언어. 문장으로

구조화된 자연어: 자연어이긴 하나, 구조적/표준화된 형태로

Design description: 프로그래밍 언어 등

Graphical notations: UML과 같은 다이어그램

Mathematical specifications: 유한상태 머신과 같은 수학적 컨셉트 이용. 명확하지만, 이해하기는 어려움.

 

요구사항과 설계

요구사항은 시스템이 무엇을 해야하는지, 설계는 어떻게 그것을 하게하는지.

둘은 나눌 수 없다.(inseperable)

-시스템 architecture는 요구사항을 구조화하는 설계

-설계 요구사항을 생성한 다른 시스템과 상호 운영된다.

-비기능적 요구사항을 만족하는 특정 architecture의 사용은 domain 요구사항.

-규제 요구사항(regulatory requirement)의 결과

 

자연어

자연어 문장으로 요구사항을 씀.

비싸고, 직관적이고, 보편적: 고객과 사용자가 이해하기 쉽다 이말이다.

 

자연어-가이드라인

- 표준형태로 기술

- 일관된 방법으로 언어 사용(필수적이면 shall, 바람직하면 should 등)

- 텍스트 하이라이트로 키 식별

- 컴퓨터 전문용어 회피

- 요구사항의 필요성 설명(근거, 이유, 참조)

 

자연어-문제점

- 명확성의 부족(leak of clarity): 여러가지로 해석될 수 있음.

- 요구사항 혼선

- 요구사항 합병

 

구조화된 자연어

자연어를 쓰지만, 정해진 형식(standard way)으로 사용

 

form-based specifications

기능/입력조건/출력조건/정보에 대해/동작/사건&사후 조건/부가효과

 

tabular 명세

supplement 자연어 사용

다수의 활동의 가능한 대안 방안의 정의가 필요.

특히 가능한 대안적인 행동 과정을 여러 개 정의해야 할 때 유용.

 

Usecase

시나리오를 표현하는 모델링 언어(UML)

actor들을 정의하고 그와 상호작용하는 use case들을 식별.

모든 가능한 상호작용들이 usecase의 집합에 기술된다.

고수준의 시각적 모델

sequence diagram도 사용 가능. 더욱 세부사항을 표현.

 

The software requirements document

공식적 상태-시스템 개발자에게 요구된것

사용자 요구사항의 정의와 시스템 요구사항의 명세를 포함.

설계 문서가 아님. 무엇을 할지 서술해야함.

 

사용자들

고객/관리자/시스템 공학자/테스트 공학자/유지보수하는 분/

 

요구사항의 변동

시스템과 approach의 종류에 의존

방법론에 따라 문서의 상세한 정도가 조절

IEEE의 표준이 있지만, 대규모에 적합함.

 

개요-도입-용어사전-사용자요구사항정의-시스템 아키텍쳐-시스템요구사항 명세-시스템 모델-시스템 진화-부록-색인

 

4-6: Requirement validation(요구사항 검증)

시스템에 정의된 요구사항이 고객이 진정 원하는 것인지 검증하는 것.

변경은 비용이 비싸다.(최대 100배)

 

체크할 것

validity(유효성)

consistency(일관성)

completeness(완전성)

realism(실현성)

verifiability(검증가능성)

 

tech.

Requirements reviews: 읽어보면서 검토

-요구사항 정의가 공식화되었는지

-고객과 contractor staff가 리뷰에 참여

-격식or비격식

Prototyping: 프로토타입을 만들어서 확인

Test-case generation: 테스트 케이스로 요구사항의 적합성 판별

 

검증가능성/이해가능성/추적가능성/확장&적용가능성

 

4-7: Requirements change

비즈니스와 기술적 환경의 변경

-새로운 하드웨어

-다른 시스템과의 인터페이스의 필요성

-비즈니스 우선도의 변경

-새로운 법제와와 정규화가 소개되어 시스템이 그것을 준수할 필요가 있음.

-의뢰인(지불하는 사람)이 사용자와 같지 않을 수도 있음.

-대형시스템은 다양한 유저 공동체를 가지고 있고, 그들은 다양하고 다른 요구사항을 가지고 있음.

-우선순위가 상충되거나 모순될 수 있음.

 

관리

요구사항 변경에 대한 관리

새로운 요구사항이 나오면 병합되거나 변경되거나

 

요구사항 식별

변경관리 프로세스: 변경이 왜 일어났는지/어떤 영향을 주는지/기존 요구가 무엇이었는지.

추적가능성 정책

도구 지원

 

분석문제 및 변경 명세

변경분석 및 비용 산출

변경 구현