Requirement Engineering - Hanyang · 2018. 4. 1. · CSE4006: Software Engineering - Scott Lee...

CSE4006: Software Engineering - Scott Lee

Scott Uk-Jin Lee

Division of Computer Science, College of Computing Hanyang University ERICA Campus

1st Semester 2018

Requirement Engineering

CSE4006 Software Engineering


Requirement Engineering (RE)

‘소프트웨어 시스템 구축에서 가장 어려운 부분은 무엇을 구축할지 결정하는 것’

요구공학(Requirement Engineering)은 다음을 가능하게 하는 메커니즘 제공 : • 고객이 정말로 원하는 것 이해 • 요구사항 분석 • 구현 가능성 평가 • 합리적 해결책 협상 • 해결책을 모호함없이 간결하게 명세 • 특정 프로세스, 프로젝트, 제품, 사람들의 필요에 맞춤

2


Requirement Engineering (RE)

Inception (인식)• 질의를 통하여 다음을 확립 :

• 문제에 대한 기본적인 이해 (what) • 해결책을 원하는 사람 (who) • 요구되는 해결책의 특징(nature) • 이해관계자와 소프트웨어 엔지니어 간의 예비 의사소통 및 공동작업의 효과

Elicitation (도출)• 모든 이해관계자로부터 요구사항 도출

Elaboration (구체화)• 데이터, 기능, 행동적 요구사항을 식별하는 분석모델 (analysis model) 생성

Negotiation (협싱)• 소프트웨어 엔지니어와 이해관계자 사이에서 실질적인 제품(deliverable system)에 대한 동의

3


Requirement Engineering (RE)Specification (명세)• 다음 중 하나 (혹은 그 이상) :

• 작성된 문서 • 모델들 • 사용사 시나리오 (유스 케이스) 모음 • 프로토타입

Validation (검증)• 다음을 찾는 뷰 메커니즘

• 내용이나 해석상의 오류 • 정확한 설명이 필요할 수 있는 영역 (모호성) • 누락된 정보 (불완전한 요구사항) • 불일치 (inconsistencies) - 대규모 제품 또는 시스템 설계 시 주요 문제점 • 비현실적인 (실현 불가능한) 요구사항

Requirements Management

4


RE - Inception • 이해관계자 식별

• 누구와 이야기 하여야 할까?

• 여러 관점을 인식 : 다른 이해관계자 → 다양한 시각과 의견

• 협업을 위한 노력 (이해관계자 사이에서)

• 첫 질문 (context-free) : • 누가 이 일을 요청 하였는가? • 누가 솔루션을 사용할 것인가? • 성공적인 솔루션의 경제적 이점은 무엇인가? • 필요한 솔루션에 대한 다른 출처(source)가 있나?

5


RE - Elicitation

• 공동(collaborative) 요구사항 수집 • 회의는 소프트웨어 엔지니어와 고객 모두가 진행 및 참석 • 의제 제안 됨

- 제품 요청과 함께 사전에 배포 됨 • 회의주재자(facilitator)는 고객, 개발자, 외부관련자가 될수 있으며 회의를 통제함

• 정의 메커니즘 (definition mechanism)의 사용 - 위크 시트, 플립 차트, 벽 스티커, 전자 게시판, 대화방, 온라인 포럼 등

6


RE - Elicitation • 목표:

• 문제 인식 • 솔루션의 요소들을 제안 • 서로다른 접근법에 대한 협상 • 솔루션에 대한 사전 요구사항을 명세

• 요구사항 수집

1. 공동(collaborative) 도출

2. 참석자 개인별 요구사항 목록 → 결합 된 요구사항 목록

3. 결합 된 요구사항 목록은 개발 시스템에 맞게 단축, 연장, 또는 수정 → 합의된 요구사항 목록

7


RE - Elicitation

8


Quality Function Deployment (QFD)

• QFD는 고객의 요구를 소프트웨어의 기술적 요구사항으로 변환하는 기술

• 고객의 요구사항 • normal requirement

- 그래픽 디스플레이, 특정 시스템 기능, 정의된 성능 수준 • expected requirement

- HCI/HMI 용이성, 전반적 작동 정확성, SW 설치 용이성 • exciting requirement

- 워드 프로세싱 소프트웨어에서 다양한 형식 제공

9


Quality Function Deployment (QFD)

• 기능 배포 (functional deployment)는 시스템에 필요한 각 기능을 결정 • 정보 배포 (information deployment)는 데이터 객체와 이벤트를 식별 • 작업 배포 (task deployment)는 시스템의 동작을 검사 • 가치 분석 (value analysis)은 위 3가지 배포에서 요구사항의 상대적 우선순위(priority)를 결정 • 가치는 고객이 인지하는 값이어야 함

10


RE - Elicitation Work Products

• 작업 산출물 (work product) = 요구사항 도출의 결과 • 필요성 및 실현가능성에 대한 기술 • 시스템 및 제품에 대한 범위를 제한적으로 기술 • 요구사항 도출에 참여한 고객, 사용자 및 다른 이해관계자의 목록 • 시스템의 기술적 환경에 대한 설명 • 기능별로 구성된 요구사항 목록 및 각각에 대한 도메인 제약 조건

(domain constraints) • 다양한 운영 조건에서 시스템 또는 제품 사용에 대한 통찰력을 제공하는 사용 시나리오 (usage scenarios)의 집합

• 요구사항을 더욱 잘 정의하기 위하여 개발 된 프로토타입

11


Use-Cases

• 시스템 사용의 흐름을 기술하는 사용자 시나리오의 집합

• 각 시나리오는 배우(actor)의 관점에서 기술 됨 • 배우(actor):

• 어떤 방식으로든 소프트웨어와 상호 작용하는 사람 또는 장치

• 역할을 나타냄 (e.g., 기계 운영자 = 4명의 배우: 프로그래머, 테스터, 모니터, 문제해결사)

• 각 배우는 시스템 사용 시 하나 이상의 목표(goal)을 가짐

12


Use-Cases

• 각 시나리오는 다음 질문에 응답 함 : • 주연 배우(primary actor), 조연 배우(secondary actor)는 누구입니까’? • 배우의 목표는 ? • 스토리 시작 전에 만족해야 하는 전제 조건(precondition)은 ? • 배우가 수행하는 주된 작업(work) 혹은 기능(function)은 ? • 스토리를 기술하며 고려해야 할 확장 기능은 ? • 배우의 상호작용에서 변경 가능한 부분이 있는지 ? • 배우가 취득, 생산, 또는 변경하는 시스템의 정보는 ? • 배우가 외부 환경의 변화에 대해 시스템에 알려야 하는가 ? • 배우가 시스템으로부터 필요로 하는 정보는 ? • 배우가 예상치 않은 변경에 대해 알기를 원하는가 ?

13


Example: SafeHome Project

14



15



16

Use-Case Diagram


Building Analysis Model

• 분석 모델(Analysis Model)의 요소 • 시나리오(scenario) 기반 요소

- 기능적 : 소프트웨어 기능에 대한 처리 서술(processing narratives) - 유스 케이스 : 배우와 시스템 간의 상호 작용에 대한 설명

• 클래스 (class) 기반 요소 - 시나리오에 함축 됨 (시나리오는 객체의 세트에 함축 됨)

• 행동 (behavioral) 요소 - 상태(state) 다이어그램

• 흐름 (flow) 지향 요소 - 데이터 흐름도 (data flow diagram)

17


Class Diagram • from the SafeHome system

18


State Diagram

19


RE - Negotiation

• 주요 이해관계자 파악 • 협상(Negotiation)에 참여할 사람들

• 각 이해관계자의 승리 조건 (“win condition”) 결정 • 조건이 항상 분명한 것은 아님

• 협상하기 • “win-win”을 끌어낼 수 있는 요구사항의 집합 도출

20


RE - Validation • 각 요구사항은 시스템 / 제품의 전반적인 목표와 일치합니까 ? • 모든 요구사항은 적절한 추상화 수준에서 기술 되었나 ?

• 즉, 일부 요구사항은 이 단계에서 부적절한 수준의 기술적 세부사항을 제공하고 있는가 ?

• 요구사항이 실제로 필요한가 아니면 시스템의 목적에 필수적이지 않을 수 있는 애드온(add-on) 기능을 나타내는가 ?

• 각 요구사항은 경계가 분명(bounded)하고 모호하지 않은(unambiguous)가 ?

• 각 요구사항에 기여가 있는가 ? • 즉, 각 요구사항에 대해 언급 된 출처 (일반적으로, 특정 개인)가 있는가?

21


RE - Validation • 다른 요구사항과 충돌하는 요구사항이 있는가 ? • 시스템이나 제품이 설치될 기술적 환경에서 각 요구사항을 달성할 수 있는가 ?

• 각 요구사항은 구현되면 테스트가 가능한가 ? • 요구사항 모델이 구축 될 시스템의 정보, 기능 및 동작을 적절히 반영하는가 ?

• 요구사항 모델이 시스템에 대한 점진적 세부정보를 제공하는 방식으로 분할 되었나 ?

• 요구사항 모델을 단순화하기 위하여 요구사항 패턴이 사용 되었나 ? • 모든 패턴은 완전하게 검증(validation) 되었나 ? • 모든 패턴이 고객의 요구사항과 일치하는가 ?

22


RE - Specification (Guideline)

• 레이어 형식(layered format) 사용 : 레이어가 깊어지면서 증가하는 세부 사항을 묘사

• 일관된 그래픽 표기법을 사용하고 텍스트 용어 역시 일관되게 적용 (별칠(aliases) 사용 금지)

• 모든 약어는 정의 되어야 함 • 목차를 반드시 포함

• 이상적으로, 색인 / 용어정의 포함 • 간단명료한 스타일로 작성 (editing suggestion 참조) • 독자(reader)의 이장에서 생각

• 이 시스템에 익숙하지 않은 사람이 쉽게 이해할 수 있을까 ?

23


RE - Specification (Editing Suggestions)

• 애매한 용어 (vague terms)에 주의 • 때로, 가끔, 종종, 보통. 일상적으로,대부분, 대략, …

• 목록을 제시할때 완전하지 않더라도 이해 할 수 있는 항목 제시 • 기타 등등, 이하 생략, ~ 등 사용 금지

• 범위(range)는 가정(assumptions)을 내포하지 않도록 분명히 • 유효 코드 범위는 10 ~ 100까지 (integer, real, hex ?)

• 애매한 동사 및 문장 주어에 주의 • 처리한다, 조절한다, 매개변수를 초기화한다

• 대명사의 사용에 주의 • 그것은, 그것은, 이는, …

24


RE - Specification (Editing Suggestions)

• 용어(term) 또는 약어가 한번 명시되면, 그 항목에 대해서는 다시 정의하지 않아도 됨

• 구조(structure)에 대한 설명이 필요하면, 그림 그리기

• 구조체가 그림으로 기술 될 때, 그 구조의 서로 다른 구성요소들을 강조하기 위해 다시 그림

• 기호 수식을 사용할 때, 그 기호가 가지는 의미를 반드시 단어로 기술

• 계산(calculation)은 적어도 두 가지 이상의 예제를 가지고 설명 • 확고한 사실을 표현하는 경우, 증명이 필요

• 항상, 모든, 절대로, 결코

25

Requirement Engineering - Hanyang · 2018. 4. 1. · CSE4006: Software Engineering - Scott Lee...

Documents

Transcript of Requirement Engineering - Hanyang · 2018. 4. 1. · CSE4006: Software Engineering - Scott Lee...