Chapter 1 The Essential of Software Requirement

1

© Karl E. Wiegers

Topics

1.1 Introduction

1.2 Difficulty of defining Requirements

1.3 Definition of Requirement

1.4 Types and levels of Requirement

1.5 Requirement Engineering

1.6 Critical Role of Requirement

(Bad and Good Requirement)

2

1.1 Introduction

Failure to understand

and

control requirements

is

the number 1 cause of project failure.

3

“The single hardest part of building a software system is deciding precisely what to build. … No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.” Frederick Brooks in No Silver Bullet: Essence and Accidents of Software Engineering

4

 The Customer’s Frustration  Using a product that doesn’t support an essential

task.

 Being at the mercy of a developer whose priorities may not be yours

5

 The Developer’s Frustration

• Learning of essential functions after system has been implemented •Being requested to modify a feature that is exactly what was asked for

 It involves the largest number of stakeholders

6

– Customers – Users – Requirements analysts – Developers – Testers – Document writers – Managers – Legal staff – Manufacturing staff – Support staff (sales, help desk,…)

1.2 Why is Difficult?

 Shortcomings of Requirements Gathering

 Informal gathering process

 Implied functionality

 Wrong or unspoken assumptions

 Inadequate (incomplete, ambiguous, conflicting) requirement specifications

 Casual change process—decisions not recorded, undesirable changes creep in

7

1.3 Definition of Requirement

Informal Definitions

 External behavior and appearance of system

 “What should be implemented.”

 “System property or attribute, perhaps a constraint.”

8

More Formal Definitions (IEEE Glossary)

 “Condition or capability needed by a user to solve a problem or achieve an objective”

 “Condition or capability that must be met by a system…to satisfy a contract…”

 “A documented representation of a condition or capability in part 1 or 2”

9

Requirements are a specification that should be implemented.

They are descriptions of how the system should behave , or a systems property or attribute.

They may be a constraint to the development process of the system

(Summerville)

10

1.4 Types and Levels of Requirement

 Functional Requirement Description of a behavior that the system

will show under a specific condition.

It is influenced by:  Business Requirements (vision and scope)  User Requirements (use cases)  System Requirements (when there are

multiple subsystems)

11

12

13

 Nonfunctional Requirement

Description of a property or characteristic that a system must exhibit or restriction/constraint it must respect.

 Quality Attributes (performance, availability, security, usability, integrity, efficiency, robustness)

 Constraints (limits on choices)

14

What’s Excluded?

 No design or implementation detail

◦ It’s too early, the “what” isn’t finished ◦ It’s too limiting, designers need freedom

 No project planning (it’s not the right place)

 No testing information (but testers will use requirements to determine test goals)

15

1.5 Requirement Engineering (Development and Management)

16

1.5.1 Development involves 4 activities

 Elicitation

 Identifying user classes

 Bringing out needs from representative users

 Understanding their tasks and goals

 Understanding the related business objectives

17

Analysis

 Distinguish task goals from functional and nonfunctional requirements, rules, suggestions, extraneous information

 Allocate top-level requirements to architecture components

 Understand importance of quality attributes

 Negotiate priorities

18

 Specification

 Translate user needs into written specifications and models

Validation  Review documented requirements

◦ Ensure common understanding between user and developer

◦ Correct problems before development starts

19

1.5.2 Requirements Management

It involves:

 “Establishing and maintaining an agreement with the customer…”

 Follows the Requirements Development activity

 Maintain a controlled baseline

20

Some Activities are:  Defining baseline—snapshot of current

agreement  Reviewing change proposals, evaluating impact

before approval  Incorporating changes in controlled way  Keeping project plan current  Negotiating new commitments (cost, schedule)  Tracing individual requirements to design, code,

test ◦ Ensure that everything needed is included ◦ Prevent unwanted features from appearing

 Tracking status and change activity ◦ Know what’s proposed, in-work, finished ◦ Know the trends

21

22

1.6 Critical Role of Requirement

 There Are Always Requirements

 Even for internal projects, there’s still a user group with needs and goals

23

 Consequences of Bad Requirements

 Rework—doing the design, the code, the testing over (and over, and over, and …)

 Cost of rework grows as discovery time becomes later

24

 Causes and Effects of Bad Requirements

 Insufficient user involvement

◦ leads to late-breaking requirements ◦ delays project completion

 Creeping user requirements

◦ frequent changes too easily accepted by developers

◦ no adherence to vision and scope ◦ architecture stability decays

25

 Ambiguous requirements

◦ Multiple interpretations ◦ Different expectations by stakeholders ◦ Developers waste time filling in details

 Gold-plating

◦ Developers add features to impress customer ◦ May add little value, but still cost time and

money, detracting from actual needs

26

 Minimal specifications

◦ Saving writing time costs design and implementation time

 Overlooked users

◦ Unknown stakeholders aren’t heard until very late, when they say the system’s not usable

 Inaccurate planning

◦ Poorly understood requirements lead to optimistic over-commitment

27

Benefits of Good Requirements

 Fewer defects

 Less rework

 Faster development

 Better estimates

 Less chaos

 Higher satisfaction for user and developer

28

 Excellent Requirements

 Complete

◦ No missing details; use TBD to flag gaps in knowledge

 Correct

◦ From a credible user, preferably several  Feasible

◦ Avoid impossible (and extremely difficult) requirements

◦ Use incremental development, prototypes to evaluate questionable requirements

29

 Necessary ◦ Make sure user has authority

 Prioritized ◦ Prepare for trade-offs, problems later in

project  Unambiguous ◦ Ensure single, consistent interpretation by all

readers ◦ Define specialized terms, avoid software

jargon  Verifiable ◦ Correctness of un-testable requirements

depends on opinion, not objective evidence

30

 Excellent Specification

 Complete

◦ No missing features ◦ Focused on user tasks, not system functions

 Consistent

◦ No conflicts between functional or nonfunctional requirements

 Originator recorded, to enable resolution when needed

 Modifiable

◦ Revised with change history ◦ Each requirement uniquely identified

 Traceable

31

END

32

Our website has a team of professional writers who can help you write any of your homework. They will write your papers from scratch. We also have a team of editors just to make sure all papers are of HIGH QUALITY & PLAGIARISM FREE. To make an Order you only need to click Ask A Question and we will direct you to our Order Page at WriteDemy. Then fill Our Order Form with all your assignment instructions. Select your deadline and pay for your paper. You will get it few hours before your set deadline.