Eliciting requirements from our customers Types of requirements Notations and methods for capturing...

42
• Eliciting requirements from our customers • Types of requirements • Notations and methods for capturing requirements • Reviewing requirements to ensure their quality • Documenting requirements for use by the design and test teams Chapter four Capturing the R equirements

Transcript of Eliciting requirements from our customers Types of requirements Notations and methods for capturing...

Page 1: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

• Eliciting requirements from our customers• Types of requirements• Notations and methods for capturing

requirements• Reviewing requirements to ensure their

quality• Documenting requirements for use by the

design and test teams

Chapter four Capturing the Requirements

Page 2: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

Case: Our real-time example is based on the embedded software in the Ariane-5, a space rocket belonging to the European Space Agency (ESA). On June 4, 1996, on its maiden flight, the Ariane-5 was launched and performed perfectly for approximately 40 seconds. Then, it began to veer off course. At the direction of an Ariane ground controller, the rocket was destroyed by remote control. The destruction of the uninsured rocket was a loss not only of the rocket itself, but also of the four satellites it contained; the total cost of the disaster was $500 million (Newsbytes home page 1996; Lions et al. 1996).

The reason: there was no discussion in the requirements documents of the ways in which the Ariane-5 trajectory would be different from Ariane-4.

Is requirement analysis really important?

Page 3: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

In 1994, the Standish Group surveyed over 350 companies about their over 8000 software projects to find out how well they were faring. The results are sobering. 31% of the software projects were canceled before they were completed. Moreover, in large companies, only 9% of the projects were delivered on time and cost what they were budgeted, and 16% met those criteria in small companies (Standish 1994).

Page 4: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

To understand why, Standish (1995) asked the survey

respondents to explain the causes of the failed projects.

The top factors were reported to be

1. incomplete requirements (13.1%)

2. lack of user involvement (12.4%)

3. lack of resources (10.6%)

4. unrealistic expectations (9.9%)

5. lack of executive support (9.3%)

6. changing requirements and specifications (8.7%)

7. lack of planning (8.1%)

8. system no longer needed (7.5%)

Page 5: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

4.1 The Requirements ProcessRequirement: a feature of the system or a description of something

the system is capable of doing in order to fulfill the system’s purpose

Page 6: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

Requirements Elicitation

Identify people, processes, and resources involved in system and document the relationships among them. Three kinds of requirements:– those that absolutely must be met– those that are highly desirable but not necessary– those that are possible but could be eliminated

Example: A Credit Card Billing System

List current charges, sum them, and request payment by a certain data

Separate the charges by purchase type to assist the purchaser in understanding buying patterns

Print the credits in black and the debits in red

Page 7: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

Requirement Analysis

Each of the system’s requirements deals with objects or entities, the states they can be in , and the functions that are performed to change states or object characteristics.

Example: A System to Generate Paychecks

System Objects: an employee, a person who is paid by the company

System Limit: an employee may be paid no more than 40 hours a week

Relationships: employee X is supervised by employee Y if you can authorize a change to X’s salary.

What

Page 8: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

Two Kinds of Requirements documents• Requirements definition: complete listing of what

the customer expects the system to do• Requirements specification: restates the definition in

technical terms so that the designer can start on the design

• Configuration management: supports direct correspondence between the two documents

Set of procedures that track

– requirements that define what the system should do

– design modules that are generated from requirements

– program code that implements the design

– tests that verify the functionality of the system

– documents that describe the system

Page 9: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

Functional and non-functional requirements

• Functional requirements – Describe what the system should do

Functional requirements include:– What inputs the system should accept– What outputs the system should produce– What data the system should store that other

systems might use– What computations the system should

perform– The timing and synchronization of the above

Page 10: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

•Non-functional requirements –Constraints that must be adhered to during development

All must be verifiable

Non-functional requirements include three main types

1. Categories reflecting: usability, efficiency, reliability, maintainability and reusability

• Response time• Throughput• Resource usage• Reliability• Availability• Recovery from failure• Allowances for maintainability and enhancement

• Allowances for reusability

Page 11: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

2. Categories constraining the environment and technology of the system.

• Platform

• Technology to be used 

3. Categories constraining the project plan and development methods

• Development process (methodology) to be used

• Cost and delivery date – Often put in contract or project plan instead

Page 12: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

4.2 Types of requirements

• Physical environment

• Interfaces

• Users and human factors

• Functionality

• Documentation

• Data

• Resources

• Security

• Quality assurance

Page 13: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

4.3 Characteristics of requirements

• Are they correct?

• Are they consistent?

• Are they complete?

• Are they realistic?

• Does each describe something the customer needs?

• Are they verifiable?

• Are they traceable?

Page 14: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

4.6 Prototyping requirements

• Throw-away prototypes• Evolutionary prototypes• Rapid prototypes

Example: A tool to track a user’s exercise each day

Requirement: user can enter the date for each exercise routine

Page 15: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

Paper Prototyping

Page 16: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

4.4 How to Express Requirements

Analysis modeling uses a combination of text and diagrams to represent software requirements (data, function, and behavior) in an understandable way

Two types of analysis modeling are commonly used:

structured analysis

object-oriented analysis

Structured Analysis

•Analysis products must be highly maintainable, especially the software requirements specification.

•Problems of size must be dealt with using an effective method of partitioning.

•Graphics should be used whenever possible.

•Find something to help with requirements partitioning and document the partitioning before specification.

•Devise tools that describe logic and policy better than narrative text.

 

Page 17: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

Analysis Model Elements

Objectives Describe what the customer requires

Establish a basis for the creation of a software design

Define a set of requirement that can be validated once the software is built

ERD DFD

STD

DDDescription of data objects

process specification

control specification

Page 18: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

•Data Dictionary(DD) - contains the descriptions of all data objects consumed or produced by the software

•Entity Relationship Diagram (ERD) - depicts relationships between data objects

•Data Flow Diagram (DFD) - provides an indication of how data are transformed as they move through the system; also depicts functions that transform the data flow (a function is represented in a DFD using a process specification or PSPEC)

•State Transition Diagram (STD) - indicates how the system behaves as a consequence of external events, states are used to represent behavior modes. Arcs are labeled with the events triggering the transitions from one state to another (control information is contained in control specification or CSPEC)

Page 19: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

Data Modeling

Data Modeling Elements

•Data object - any person, organization, device, or software product that produces or consumes information

•Attributes - name a data object instance, describe its characteristics, or make reference to another data object

•Relationships - indicate the manner in which data objects are connected to one another

LJL

BLF

White

Blue

Coupe

Sedan

XZ765…

Q12A45…

750iL

Taurus

BMW

Ford

ownerColor Type ID#ModelManufacturer

instance

Identifier

Attributes

Page 20: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

Data object Attributes

Name

Address

Age

Driver's license ID

Manufacturer

Model

ID

Color

Relationships

possession

Page 21: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

Cardinality and Modality

•Cardinality - in data modeling, cardinality specifies how the number of occurrences of one object are related to the number of occurrences of another object

1: 1

1: N

M:N

•Modality - zero (0) for an optional object relationship and one (1) for a mandatory relationship

Customer Mend action

Cardinality: one customer waits for mend actio

n

Modality: must a mend action must correspond to a customer

Cardinality: maybe have many mend actions

Modality: optional exist the situation of needless mend

action

Page 22: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

Entity-Relation Diagram (ERD)

Entity Student Instructor Class

Enrolled in TeachRelations

single entity many entities

must optional

Attributes Name ID#

Page 23: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

…………

Instructor Student

Enrolled inTeach

Class

I D # I D #

Name Name

Sex Sex

Title

Instructor ID

Class ID

Grade

Student ID

Class ID

CreditI D #Subject

Provides representations of all data objects.

Page 24: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

Functional Modeling and Information Flow

• Data Flow Diagram-Shows the relationships of external entities, process or transforms, data items, and data stores

•DFD cannot show procedural detail (e.g. conditionals or loops) only the flow of data through the software

input Data storage

function Data flow

output

Page 25: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

physician patientSee doctor system

Bill

medication

Medical experience and knowledge

Page 26: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

FAB

AV

W

X

Y

Z z1 z2

z3

Bf1f2

f3

f4 f5

f6

f7

X

Y

x1 x2

y1 y2Z

f4.1

f4.2

f4.3

f4.4

f4.5

Refinement from one DFD level to the next

Page 27: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

Behavioral Modeling

•State transition diagrams represent the system states and events that trigger state transitions

•STD indicates actions (e.g. process activation) taken as a consequence of a particular event

•A state is any observable mode of behavior

statestate

new statenew state

event causing transitionaction that occurs

Page 28: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.
Page 29: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

Data Dictionary Contents

Name: Aliases: Where used: How used: Content description : Supplementary information

the primary name of the composite data item other names for the data item data transforms (processes) that use the composite data item the role of the data item (input, output, temporary storage, etc. a notation for representing content (presented on next slide) specific information about data types, pre-set values (if known)

Page 30: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

The Notation of DD’s Content Description

Data Structure mark sense

= make up of

Sequence + add

Choose [ | ] or

Iteration {}n n times’ repeat

( ) optional data

** limitative note

Page 31: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

telephone numberintegrated

office phone system

Name: Aliases: Where/How used: Description: Format:

telephone number phone number, number read-phone-number (input) display-phone-number (output) analyze-long-distance-calls (input) telephone no. = [ local extension | outside no. | 0 ] outside no. = 9 + [ service code | domestic no. ] service code = [ 211 | 411 | 611 | 911 ] domestic no. = ( ( 0 ) + area code ) + local number area code = *three numeral designator*

Build the requirements dictionary:

alphanumeric data

system output

Page 32: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

4.7 Requirements documentation

• Requirements definition document: what the customer wants– general purpose– background and objectives of system– description of customer-suggested approach– detailed characteristics– operational environment

• Requirements specification document: what the designers need to know

Page 33: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

Example4..1.3.1 INITIATE TRACK ON IMAGE. Logical processing shall be done toINITIATE TRACK ON IMAGE. This shall have as input HANDOVER DATA.This shall have as output HOIQ, STATE DATA, and IMAGE ID. This logicalprocessing shall, when appropriate, identify a new instance of IMAGE. Thislogical processing, when appropriate, shall identify the type of entity instance asbeing IMAGE ON TRACK. NOTE: A request for pulses is made by entering aformal record into the HOIQ which feeds the pulse-send procedures.

ALPHA: I NI TI ATE_TRACK_ON_I MAGE.I NPUTS: HANDOVER_DATA.OUTPUTS: HOI Q. STATE_DATA, I MAGE_I D.CREATES: I MAGE.SETS: I MAGE_ON TRACK.DESCRI PTI ON: “( 4. 1. 3. 1) A REQUEST FOR PULSE I S MADE BY

ENTERI NG A FORMAL RECORD REQUEST I NTO THE HOI Q WHI CH FEEDS THE PULSE SENDI NG PROCEDURES. ”

Page 34: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

4.8 Participants in requirements process

• Contract monitors

• Customers and users

• Business managers

• Designers

• Testers

• Requirements analysts

Page 35: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

Developers don‘t understand operational needs.How developers see users How users see developers

Users don‘t know what they want.Users can‘t articulate what they want. Developers place too much emphasis on

technicalities.Users have too many needs that are politically

motivated.Developers try to tell us how to do our jobs.

Users want everything right now. Developers can‘t translate clearly-stated needs into a successful system

Users can‘t prioritize needs. Developers say no all the time.Users refuse to take responsibility for the system.

Developers are always over budget.

Users are unable to provide a usable statement of needs

Developers are always late.

Users are not committed to system development projects.

Developers ask users for time and effort, even to the detriment of the users?important primary duties.

Users are unwilling to compromise. Developers set unrealistic standards for requirements definition.

Users can‘t remain on schedule. Developers are unable to respond quickly to legitimately changing needs

Page 36: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

4.9 Requirements Validation

The purposes of requirements analysis:

• Provide a way for customers and developers to agree on what it is the system is to do

• Provide guidelines for the system designers

Requirements Validation: the process of determining that the specification is consistent with the requirements definition.

Two steps:

•Make sure that each specification can be traced to a requirement in the definition document

•Check the definition to see each requirement is traceable to the specification

Page 37: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

Table 4.6. Requirements validation techniques.

Manual techniques ReadingManual cross-referencingInterviewsReviewsChecklistsManual models to check functions and relationshipsScenariosMathematical proofs

Automated techniques Automated cross-referencingAutomated models to enact functionsPrototypes

Page 38: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

Requirements review

• Review goals and objections of system.• Compare requirements with goals and objectives.• Describe operational environment.

Examine– interfaces– information flow– functions

Check for omissions, incompleteness, inconsistency.• Document risk.• Discuss how system will be tested.

Page 39: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

4.10 Measuring Requirements

Page 40: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

4.11Choosing a specification technique

• Applicability• Implementability• Testability/simulation• Checkability• Maintainability• Modularity• Level of abstraction/expressibil

ity• Soundness

• Verifiability• Run-time safety• Tools maturity• Looseness• Learning curve• Technique maturity• Data modeling• Discipline

Page 41: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

Information system example

Adver t i si ng Campai gn = *Ent i t y. Recor ds t he condi t i ons and ai msf or a campai gn t o adver t i se a pr oduct . *Campai gn Number + Campai gn St ar t Dat e + Campai gn End Dat e

+ Tar get Audi ence + Tar get Rat i ng Per cent age+ Campai gn Pr edi ct ed Rat i ng + Campai gn Budget Tot al+ Pi ccadi l l y Budget Amount + Campai gn Dur at i on+ {Requi r ed Spot Dur at i on}*Wor k necessar y t o r emove or j ust i f y t he r epeat i ng gr oup. *

Tar get Audi ence = *Dat a el ement . The audi ence at whi ch a campai gni s ai med. See Audi ence Type f or val ues. *

Audi ence Type = *Dat a el ement . Used t o cl assi f y r at i ngs fi gur es. *[Homes | Homemakers | Adults | Men | Women | Children]

Page 42: Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their.

Advertising agencies

Unavailable campaign

Predicted rating

Episode

Breakchart day Commercial break

Ratecard segment

Spot rate

Ratecard period

Advertising campaign

Advertising agency

Product

Campaign requirement

Suggested campaign

Unavailable campaign

Suitable time

Priced time

Commercial spot

Select suitable time

Price the time

Create suggested campaign