chap 1 sw development & requirement...

SW Development & Requirement Engineering

Chap 1

2017 –서강대 정보통신대학원

I. Introduction to RM

II. SW Development and RM

III. Requirement Engineering

IV. RE: Past, present and future

Q & A

2


What is a Requirement?

요구사항이란 과연 무엇일까?

요구사항을 어떻게 관리해야 할까?

3

4

defines the characteristics of the desired (required) system imposes constraints on the delivered system that are important to the customers or other stakeholders


IEEE Std-729/IIBA Alan Davis Traditional

“An Externally-Observable Characteristic of a Desired System.”

A Complete statement of What system will do without referring to How it will do it.

“A condition or capability need by a user(stakeholder) to solve a problem or achieve an objective.”

What is a Requirement definition?

5


Expectation

Problem description•고객 언어로 표현된 해결할 문제

•고객의 SW에 대한 승인 조건

Solution specification• 제약조건하에 고객 니즈 충족 방법

• 제품/서비스 만족을 위한 특성

Constraints

robust and meets all the stakeholders' expectations

Customer’sNeeds

DevelopmentEffortgap

what the system must do• focusing on user’s business needs• change over time

SW Requirements

요구사항은 고객이 실제로 원하는 것이다.


• “Time to Market with the Right Product” – better, cheaper, and faster

• "Right Product“ is based on requirements

•Gathering•Expressing•Organising•Reviewing•Changing•Tracing•Agreeing

Stakeholder’s needs Systematic activities

Customer perspective

Developer perspective

Good QualitySW Development

Good Requirement Management

SuccessfulSW Project

6

What is a Requirement Management?


Decision making

Negotiation

Value estimationCommunication

Trace

Risk ManagementProject Success

• Right decision making based on ‘precise data’

• determined and agreed by all the stakeholders before the SW can be built.

7

How is a Requirement Management?


Why is RM important

고객과의

합의 근거

프로젝트

산정 기반

시스템

신뢰성 기반

시스템

구현 기반

•Communication baseline : Common view

8

•Development baseline : Visibility

•Change Management baseline : Traceability

•V & V baseline : Quality

•Contact baseline: Cost/schedule estimation

•Improved requirements quality•Reduce costly rework and errors•Increase predictability and visibility

9


What is RM problem

•Understanding the problem•Change requirement•Feature(Scope) Creep•No documentation

•SW will continually change•SW will become increasinglyunstructured as it is changed

Why is RE difficult?

SW builder’s most important function :iterative extraction and refinement of requirements.

Belady & Lehman’sLaws

Requirements Secrets

1. The stated requirements are never the real requirements.

2. Half of the features are never used once .

3. More than half of the effort is wasted .

4. ibetter to invest more in an effective requirements processthat results in higher quality products being provided to test.

5. Communication on most projects is challenged


10

Top 3 Myths about RM

• A requirements document = Requirements Management.

• We already stared the project, it’s too late for RM.

• A requirements tool = requirements management.

SW 규모별 프로젝트 성공률


SW Project Success Ratio

11(Chaos Report, 2014)SW 프로젝트 성공

률

94 00 04 06 08 10 12Successful 16% 28% 29% 35% 32% 37% 39%

Failed 31% 23% 18% 19% 24% 21% 18%challenged 53% 49% 53% 46% 44% 42% 43%

0%

10%

20%

30%

40%

50%

60%

1994 2000 2004 2006 2008 2010 2012

SuccessfulFailedchallenged

satisfies user

needs

within budge

t

on time

ProduceQuality SW

developer

Size success cancelled failureLarge 9% 61.5% 29.5%

Medium 16.2% 46.7% 37.1%

Small 28% 50.4% 21.6%


SW Project Success & Fail factor

12

SW Project Fail Factor

Incomplete Requirements 13.1%Lack of User Involvement 12.4%lack of Resource 10.6%Unrealistic Expectations 9.9%Lack of Executive Support 9.3%Changing Req. & Specifications 8.7%Lack of Planning 8.1%No Need It Any Longer 7.5%Lack of IT Management 6.2%Technology Literacy 4.3%

SW Project Success Factor

User Involvement 15.9%Executive Management Support 13.9%Clear Statement of Requirements 13.0%Proper Planning 9.6%Realistic Expectations 8.2%Smaller Project Milestones 7.7%Competent Staff 7.2%Ownership 5.3%Clear vision & Objectives 2.9%Hard-Working, Focused Staff 2.4%

기술보다 요구사항 관리적 측면

17.1% 16.4% 15.3%

9.8% 8.7%

불명확한요구사항

잦은 요구사항 변경

짧은 프로젝트 기간

자원부족 완료 후변경요구

국내 SW 실패 원인 (NIPA)


SW defect detection

Avg. for Defect Removal Efficiency (per FP) (U.S, 2007)

Defect Origin Defect Ratio

Defect Potential

Removal Efficiency

Defect Remaining

Req.Defect 20% 1.00 77% 0.23

Design Defects 30% 1.25 85% 0.19

Coding Defects 35% 1.75 95% 0.09

Doc. Defects 5% 0.60 80% 0.12Bad Fixes 10% 0.40 70% 0.12

Total 100% 5.00 85% 0.75

Requirements, 56%

Design, 27%

Coding, 7%

Other, 10%

Distribution of bugs origin (J.Martin)

13

49

34

13

5 20

5

10

15

20

25

30

35

40

45

50

Incorrect InformationOmissionsAmbiguitiesPoorly WrittenMisplaced

요구사항 에러 종류 (By Ivy Hooks)


SW Content Deficiencies

14

% of Features/Functions

Less than 25% 4.60%25 - 49% 27.20%50 -74% 21.80%75 - 99% 39.1%

100% 7.3%

Features/Functions

Large company 42%

Medium company 65%

Small company 74%

average 61%

For challenged projects,

• of originally-specified features • IT Product의 65%가 비사용,

• 60%는 시장에 미도달


Fault ratio “0” from requirement phase

• Missing Requirements: Domino Effect throughout the

project lifecycle

• Fedex’s 1:10:100 law

Product Quality

RequirementDefinition

Design Build Test Operations

15

Missing User

Requirement

Missing System

Requirement

Missing design

element

Missing function

Heinrich’s Domino Effect

초기 요구관리를 할수록

SW 품질은 높아진다


Change by incomplete Requirements

16

% Web MIS Outs COT Sys Mil Avg.

Monthly 4.00 2.50 1.50 3.50 2.00 2.00 2.58

Months 6.00 12.00 14.00 10.00 18.00 24.00 14.00

Total 24.00 30.00 21.00 35.00 36.00 48.00 32.33

Monthly Rate of Changing Requirements (crosstalk, 2005)

Changes in Requirements

(43%)

Changes in Data Formats

(17%)Emergency Fixes (12%)

Routine Debugging (9%)

HW Changes (6%)Documentation (6%)

EfficiencyImprovements (4%)

Other (3%)

Survey of 500 Major Projects’ Maintenance Costs

• 재작업 비용은 전체 개발비용의 30~50%

(Bohem & Papaccio, 1998)

• 요구사항 에러는 재작업 비용의 70~85%

(Leffingwell, 1997)


Increase cost by requirement change

SW 개발생명주기 단계별 변경비용 증가량

200:1 Cost saving

PhaseAvg. Cost torepair defect

NormalizedValues

Requirements $139 1

Design $455 3

Coding $1,000 7

System Testing $7,000 50

Production $14,000 100

17

effo

rt

time

typical

better

Development time is reduced

tool support(Telelogic, 2004)

Overruns Cost Time

Large company 178% 230%

Medium company 182% 202%

Small company 214% 239%

average 189% 222%

Restarts!- 94% by cost and time overrunsOverruns Cost Time

Under 20% 15.5% 13.9%

21 - 50% 31.5% 18.3%

51 - 100% 29.6% 20.0%

101 - 200% 10.2% 35.5%

201 - 400% 8.8% 11.2%

Over 400% 4.4% 1.1%


Overrun by requirement rework

(In Cancelled & Failure Project)

84%

72%79%

71% 74%

56%47%

54%46%

59%64%

68% 67%74%

69%

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

2004 2006 2008 2010 2012

TIME

COST

FEATURES

Time and cost and features overruns


RM and effort

020406080

100120140160180

0 5 10 15 20 25% Project Cost for Requirements

% P

roje

ct

Co

st

Ove

rru

n

요구관리

투입 예산

평균 예산

초과

5% 이하 125%

5~10% 83%

10%이상 30%

요구사항 투입노력 투입시간

Faster

Projects14% 17%

Slower

Projects7% 9%• RM에 프로젝트 비용의 8~14% 투자 시

비용초과나 일정지연이 감소 (NASA)

• 현재 RM에 평균 3~6% 투자19


work effort by RM activity

20


Twelve Requirements Basics for Project Success

Requirements Basics for Project Success

1. Includes a trained and experienced Requirement Manager or analyst.2. Partner with your customer.3. Enlist all members to perform requirements work.4. Invest in the project’s requirements process.5. Utilize an evolutionary or incremental approach to development6. Write a project vision and scope document.7. Use requirements elicitation techniques to evolve the real requirements 8. Proactively address requirements-related risks.9. Use an effective mechanism to control requirements changes 10.Use an requirements tool to maintain the requirements.11. Ensure that the requirements are accurate and not omitted. Ascertain the

rationale for every requirement (why it is needed).12. Conduct inspections of all requirements-related documents.

21


Definition of Requirement Engineering

22

a disciplined, process-oriented approach to the definition, documentation and maintenance of SW requirements throughout the SDLC

the branch of systems engineering concerned with

• the real-world goals for,

• services provided by,

• and constraints on a large and complex software-intensive system.

concerned with the relationship of these factors to

• precise specifications of system behavior,

• and to their evolution over time and across system families.


What is Requirement Engineering

23

solving real-world problems by forming precise statements

about their solutions.

Deep understanding of customer and

user needs

Deep understanding of business and

market

Deep understanding of application domain

and technology

Requirements engineering

Solution development and SE

요구사항 생성 및 관리를 위한 체계적/총괄적 접근


Sparks

FactoryForeman

The Product To Be Built

Video ClipOKFind

Finished Goods

Order Entry

Electrodes

RequirementEngineer • 방법론,기법,Tool

• Effort Estimation • Process 개선

• 의사소통 관리

• 조직/문화관리

• 인원 관리

Real World (Non-Engineering) Solutions (Engineering)

Req

uire

men

tEn

gine

erin

g

SW 개발

능력

비즈니스

영역 문제와

전략 이해

고객/조직 중심이 아닌 개발자 위주 관리의 위험

Flexibility

24

Characteristics of Requirements Engineering

Engineering + Non-engineering


RE Perspective

•수/발주자간 공통 기대/목적 제공

•비즈니스 요구의 가시성 확보

•Make business profit through SW•Business-Oriented Management

•Minimize dev. effort and defect •Process-Oriented Management

•수/발주자간의 의사소통 제공

•SW개발 정확성 및 변경최소화•고객 만족의 기준 제공

•SW 품질 및 신뢰성 확보

•Maximize customer satisfaction•Customer-Oriented Management

비즈니스관점

(Faster)

비즈니스관점

(Faster)

고객 관점(better)

고객 관점(better)

개발 관점(cheaper)개발 관점(cheaper)

고객

개발자

관리자

RequirementsEngineering

Qualitative

Traceability

Quantitative

25


3 Dimensional RE

Specification desired output

Agreement

Representation

complete

fair

opaque

informal semi-formal formal

Initial input

personal view

common view

RM Process

RM Tool RM Technique

RE Framework

26

R ERequirements management

Requirements development


• Definition and integration of the business, the user and SW product-level requirements.

• Elicitation, Analysis, Specification, Verification the requirements.

Consistent and tracking the status of the requirements

• Controlling the baselined requirements

• Processing(approving or disapproving) changes

• performing impact analysis for the requested changes

Acceptance Testing

Areas and activities of RE

27


RE Process

28


요구

분석

요구명세및 검증

SW 아키텍쳐

SW구현

요구공학 총체적 활동 요구공학 총체적 활동

요구사항 변경관리 활동 요구사항 변경관리 활동 요구사항 정의 활동 요구사항 정의 활동

SW설계

SW테스팅

요구

추출

SW Develop Lifecycle

SW Product Lifecycle

고객 관점 개발자 관점

RM process BaselinedRequirements

DevelopmentRequirements

Business Requirements RM Tools

SW 제품,서비스 개발

RE Process

비즈니스와 개발 활동을 연계

29


RE Process

•Define Business Req.• Identify stakeholder•Elicit requirement

•Model Req. •Prioritize Req. •Negotiate Req.

CandidateRequirements

FormalRequirements

BaselinedRequirements

•Req. change control•Req. traceability control•Req. version control

•Define specification criteria•Specify functional req.•Specify non-functional req.

•Verify SRS contents•Verify SRS structure•Establish req. baseline

ConsistentRequirements

Agreed Requirements

Ree. Elicitation Req. Analysis

Req. SpecificationReq. Verification

Req. Management

30


RE Process activity problem

Importance VS Satisfaction

94

84

95

87

73

63

59

45

41

32

41

28

33

22

0 10 20 30 40 50 60 70 80 90 100

Requirements Definition andElicitation

Requirements Analysis

Requirements Verification andValidation

Requirements Documentationand Reporting

RequirementsConfiguration/Change Control

Requirements Reuse

Integration with Other Tools

Importance satisfaction level(ISO/IEC JTC1/SC7 WG4, 2004)

31


The essence of RE by 6 key questions

Why do they want it? rationale analysis- reasons behind the requirements

32

What do they want? goal modeling- determining what they want

should be involved? stakeholder analysis- deciding who should be involved

Who

How will we know? acceptance criteria- important consideration

Whenshould we build it? Triage and prioritisation- when to satisfy particular requirements

Where (in what context) could it work? scenario modeling- identifying the context in which solution could work


RE Methodology

1.Purpose Business-Oriented RE: 프로젝트의 목적과 요구사항 범위에 대한 명확한 식별

2.Participants Multi-Viewpoint RE: Stakeholder 역할 및 관계 정의, 고객과의 의사소통 개선

3.Precision Customer-Oriented RE: 고객의 기대를 만족시키는 정확한 요구사항 정의

4.Priority Value-Oriented RE: 고객의 가치 평가기준 정의, 사용자 기대와 요구사항 균형

5.Product Quality-Oriented RE: 완전하고 명확한 기능과 품질 정의 및 trade-off

6.Process Process-Oriented RE: 체계적이고 내재화된 요구공학 프로세스의 적용

Voice of Customer

Customer Requirements

Product Requirements

Well-defined 요구관리를 위한 6P’s

33


RE tool

Requirement Management Requirement trace

versions and change Manage RM improvement

• Store requirements attributes • import and export requirements• Requirement retrieval, filtering, sort

and generate report

• Link between requirements• Link other system element• Trace requirement• Facilitate impact analysis• Track requirements status.

• Link requirement with other SW tool• Distributed process requirements • Support requirement reuse• Improve communication between

stakeholders

• Synchronize access control and CR• Establish requirements baseline• Manage Change history• previous version elicitation

RM Tool List RM Tool List

34


Integration RM with SW development

RequirementManagement

IntegrationManagement

CommunicationManagement

Human resourceManagement

RiskManagementQuality

Management

CostManagement

TimeManagement

ScopeManagement 사업수행기간 중

환경 변수 인지 체계적인 보고

와 정보의 공유

전문인력 확보

생산성 제한요인

각종 계약자 선정

및 관리 제한요인품질 준수 요건

및 제약 조건원가 준수 및

제약 조건

일정 준수 및

제약 조건

사업 범위 및

변경 요인

What to do?

When to do?

How much?Good Enough?

Partners !

People & Motivation

Understand & Be understood !

Know all and Apply !

35

1990’s requirements

1980’s specification

1970’s design

1960’s coding


RM RoadmapTraditional SE

RE Key topics of the decades

36Ref) Marjo Kauppinen and Eero Uusitalo, T-76.5615 Requirements engineering, Aalto Univ. 2011

국방산업으로부터 통신, 자동차, 금융 등으로 확산…

• Very light doc. of requirements

• Oral communication and frequent deliveries

• Role of RE is hidden

Debate Combination


RE approaches in practice

Past RETraditional approach

• Well-documented and modeled Req. : Standards and document templates

• A complete, consistent and unambiguous set of requirements : Development was document-driven

• Role of RE was critical

Current REAgile approach

37

Customer value creation

Creativity Service development

Deep understanding of customer needs:

core of RE: fundamental to value

creation

FutureTrend


Future trend

38

A set of ideas and requirements to be implemented

Eliciting & Analyzing

needs

Validating requirements

Representing requirements

Creatingideas

Handlingideas

Selectingideas


Future trend



FutureTrend

39

RE can play an important role in service development.

Technical requirements

Creativity


Software development

Agility

Service development

Requirements engineering


Future trend



FutureTrend

40

Q & A

41

chap 1 sw development & requirement...

Documents