REQUIREMENTS ANALYSIS - C1. Plan project Integrate & test system Analyze requirements Design...

REQUIREMENTSANALYSIS - C1

Plan project

Integrate & test system

Analyze requirements

Design

Maintain

Test unitsImplement

Identify corporate practices

Obtain customer’s wants and needs (C-requirements)

Express C-requirementsproseuse casesstate diagramsdata-flow diagrams

Refinerequirements

(next chapter)

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Software Engineering Roadmap: Chapter 3 Focus

Chapter Learning Goals

• Distinguish C- (Customer) requirements from D- (Detailed) requirements

• Express C-requirements– exploit use cases – exploit state diagrams– exploit data flow diagrams – sketch user interfaces

• Be able to write first part of a SRS - Software Requirements Specification


Introduction to requirements analysis

C- vs D-Requirements

SRS (IEEE)

1. Introduction

2. Overall description

3. Specific requirements

4. Supporting information

C-requirements

D-requirements

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Graphics reproduced with permission from Corel.

Why Must Requirements be Written Down?

• Define the goals of the project

• Sets customer expectations

• Basis of the contract between customer and supplier

• Writing is thinking

• Allows thorough inspection and testing

• Can be kept up to date

• Allows tracking - estimates/actuals

• Team communication tool

To Be Performed With Each Requirement

Each requirement must be … expressed properly, made easily accessible, numbered, accompanied by tests that verify it, provided for in the design, accounted for by code, tested in isolation, tested in concert with other requirements, and validated by testing after the application has been

built. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

For all stages,track metrics, e.g.,• time spent• quantity accomplished

pages of C-requirementsmins. of customer interaction per pg.

• self-assessed quality (1-10 scale)• defect rates from inspections

Typical RoadMap for Customer (“C-”)

Requirements

1. Identify “the customer” -- see section 2.2

2. Interview customer representatives• identify wants and needs • exploit tools for expression (section 3.1 - 3.4)

• sketch GUI’s (section 3.5)

• identify hardware

3. Write C-requirementsin standard document form (see case study)

4. Inspect C-requirements

5. Build D-requirements(next chapter)

On customer approval ...

Review with customer


IEEE 830-1993 SRS Table of Contents

1. Introduction 1.1. Purpose 1.2. Scope 1.3. Definitions, acronyms & abbreviations 1.4. References 1.5. Overview2. Overall description 2.1. Product perspective 2.1.1. System interfaces 2.1.2. User interfaces 2.1.3. Hardware interfaces 2.1.4. Software interfaces 2.1.5. Communications interfaces

2.1.6. Memory constraints 2.1.7. Operations 2.1.8. Site adaptation requirements 2.2. Product functions 2.3. User characteristics 2.4. Constraints 2.5. Assumptions and dependencies 2.6. Apportioning of requirements3. Specific requirements -- see chapter four --4. Supporting information-- see chapter four --

tbd: get copyright permission from IEEE

Requirements: Necessity not Luxury

• A defective requirement is 20-50 times more expensive to repair at end of a project than at beginning ($100 -> $2000-5000)

• Requirements analysis is something we must afford to due

• So why do we not do it?

• So why do we not do it well?

Instead … code and test, code and test

Customer interaction

Project Stakeholders

Stakeholder Perspective• Owner Scope• Users Requirements (what)• Designers Arch./Design (how)• Builders Implementation/

TestingWhat the Designers andBuilders developed

What the Ownersare willing to pay

What the Users wanted

http://images.google.com/imgres?imgurl=http://www.vinography.com/archives/images/pennies.gif&imgrefurl=http://www.vinography.com/archives/ramblings_and_rants/&h=144&w=180&sz=5&hl=en&sig2=a9somOnL-_1QtA56O50N8w&start=3&tbnid=HnrO1L95W483WM:&tbnh=81&tbnw=101&ei=yyylRf3wIYn2aL7cjcsO&prev=/images?q=pennies&svnum=10&hl=en&lr=&sa=G

http://images.google.com/imgres?imgurl=http://www.adlertech.com/Site%2520Graphics/Amer%2520dollars%2520sm.jpg&imgrefurl=http://www.jaani.net/view/crime_and_security&h=187&w=216&sz=14&hl=en&sig2=FBmxUpRLHi95fi6upvWn3w&start=4&tbnid=ATqDbRqZvkUliM:&tbnh=93&tbnw=107&ei=6SylRZ6qL6D8aKul8NAO&prev=/images?q=dollars&svnum=10&hl=en&lr=

Relatively high

Relatively low

Sources of Requirements: People vs. Other

Approximate % of requirementsgathered from people

Type of application

highly constrained

unconstrained

missile guidance system

flight control system for airliner

enhancement to corporate accounting system

manufacturing control system

corporate accounting system

Encounter video game

decision support system for military tactics

Summary of C-Reqs for Encounter (1/2)

• Role-playing game which simulates all or part of the lifetime of the player's character.

• Game characters not under the player’s control are called "foreign" characters.

• Game characters have a number of qualities such as strength, speed, patience etc.

• Each quality has a value

• Characters "encounter" each other when in the same area, and may then "engage" each other.


Summary of C-Reqs for Encounter (2/2)

• The result of the engagement depends on the values of their qualities and on the area in which the engagement takes place.

• Player characters may reallocate their qualities, except while a foreign character is present.

• Reallocation taking effect after a delay, during which the player may be forced to engage.

• Success is measured …

• by the "life points" maximum attained by the player - or -

• by living as long as possible.


What needs to be done with these requirements?

• Enhance / refine / remove ambiguities via communications with customer

• Determine the musts, wants and nice to haves

• Organizing and numbering the requirements for tracability

Before interview: 1. List and prioritize “customer” interviewees

– most likely to determine project’s success 2. Schedule interview with fixed start and end times

– at least two from development team should attend– prepare to tape?

At interview: 3. Concentrate on listening Don’t be passive: probe and encourage

– persist in understanding wants and exploring needs– walk through use cases, also data flow? state diagrams?

Take thorough notes 4. Schedule follow-up meetingAfter interview: 5. Draft SRS C-requirements using a standard 6. E-mail customer for comments

Handle Interviews

4. Describing customer (C-) requirements

Objective – To capture the application model or “concept of operation” as desired

by the customer/user.

Modeling Tools for Capturing Requirements

• List of requirements

• Use case diagrams

• Entity relationship diagrams (ERD)

• Data flow diagrams

• State (transition) diagrams

• Screen prototyping (story-boards)

Initialize Use Case for Encounter

Encounterforeign

character

player

designer Set rules

actors Encounter

Travel toadjacent

area

Initialize

1. System displays player’s main character in the dressing room.2. System displays a window for setting his character's qualities. 3. Player allocates the qualities of his main character. 4. Player chooses an exit from the dressing room.5. System moves player’s main character into the area on the other side of the exit.

InitializeUse case

Use case details


Engage Foreign Character Use Case

player

designer

InitializeUse case

Encounter

Travel toadjacent

area

Set rules

Engage Foreign Character

1. System displays the foreign character in the same area as the player’s.

2. System exchanges quality values between the two characters.3. System displays the results of the engagement. 4. System displays player’s character in a random area.

Engageforeign

character

Use case details


Conceptual Model of the System

Player

EncounterGame

Area

MainCharacter

ForeignCharacter1

1

n

111

1

n

Plays Has

Has

Has

Engagement

1

n

Has

Takes place in1

1

Entity RelationshipModel or Object Model

Data Flow Diagram: Explanation of Symbols

Account #& deposit

Get deposit

Check deposit

Processingelement

Data typeDirectionof data flow

Data Flow Diagram: Explanation of Symbols

Account #& deposit

balancequery

User

accountdatabase

accountdata

Get deposit

Create account

summary

Check deposit

Printer

Input

Output

Processingelement

Data typeDirectionof data flow

Data store

…...


Partial Data Flow Diagram for ATM

Application

account #& deposit

balancequery

account #& deposit

account #

User

Makeinquiry

accountdatabase

deposittransaction

accountdata

Get deposit

Get inquiry

Validateinquiry

Do deposit

transaction

Create account

summary

Validate deposit

errorerror

Printer

memberbanks

bank name

Display account

account #

accountdata

accountdisplay


Partial Encounter State-Transition Diagram

Setting up Preparing

Waiting

Complete setup

Foreign character

enters area

Engaging

Player clicks

qualities menu


Using Conditions in State-Transition Diagrams

Engaging

Waiting

[foreign character absent]

[foreign character present]

Player moves to adjacent

area

eventcondition

condition

state

stateAdapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Settingqualities

Sketch of Encounter State-Transition Diagram

Setting up

Engaging

Waiting

Player completes

setup

Player dismisses

report window

Reporting

Foreign character

enters area

Encounter completed

Player dismisses

set qualities widow

Player requests status

Player requests to

set qualities Foreign

character enters area

[foreign character absent]

[foreign character present]

Player moves to adjacent

areaPlayer quits


Conceptualizing a System in terms of the User Interface

• Customers/Users often conceive a system in terms of its user interface

• Screen prototyping and story boarding (screen facade but no code) works well in connection with Use Case

Step 1: Know your user (C)‡

Step 2: Understand the business function in question (C)

Step 3: Apply principles of good screen design (C, D)

Step 4: Select the appropriate kind of windows (C, D)

Step 5: Develop system menus (C, D)

Step 6: Select the appropriate device-based controls (C)

Step 7: Choose the appropriate screen-based controls (C)

Step 8: Organize and lay out windows (C, D)

Step 9: Choose appropriate colors (D)

Step 10: Create meaningful icons (C, D)

Step 11: Provide effective message, feedback, & guidance (D)

Steps for Constructing User Interfaces*

* adapted from Galitz [Ga2] ‡ a C-requirement process

• Level of knowledge and experience– computer literacy (high; moderate; low)– system experience (high; moderate; low)– experience with similar applications (high; moderate; low)– education (high school; college; advanced degree)– reading level (>12 year’s schooling; 5-12; < 5) – typing skill (135 wpm; 55 wpm; 10 wpm)

• Characteristics of the user’s tasks and jobs– Type of use of this application (mandatory; discretionary)– Frequency of use (continual; frequent; occasional; once-in-a-lifetime)– Turnover rate for employees (high; moderate; low)– Importance of task (high; moderate; low)– Repetitiveness of task (high; moderate; low)– Training anticipated (extensive; self-training through manuals; none)– Job category (executive; manager; professional; secretary; clerk etc.)

• Psychological characteristics of the user– Probable attitude towards job (positive; neutral; negative)– Probable motivation (high; moderate; low)– Cognitive style (verbal vs. spatial; analytic vs. intuitive; concrete vs. abstract)

• Physical characteristics of the user– Age (young; middle aged; elderly)– Gender (male; female)– Handedness (left; right; ambidextrous)– Physical handicaps (blind; defective vision; deaf; motor handicap)

Know Your

Users*

* adapted from Galitz [Ga2]

• Ensure consistency among the screens of designated applications, and among screens within each– conventions; procedures; look-and-feel; locations

• Anticipate where the user will usually start– frequently upper left -- place “first” element there

• Make navigation as simple as possible– align like elements– group like elements– consider borders around like elements

• Apply a hierarchy to emphasize order of importance• Apply principles of pleasing visuals -- usually:

– balance; symmetry; regularity; predictability– simplicity; unity; proportion; economy

• Provide captions

Principles of Good Screen Design*

* see Galitz [Ga2]

Applying Principles of Good Screen Design: “Before”

* see Galitz [Ga2]

Type checking saving mmf CD

Branch Main St. Elm St. High St.

Privileges newsletter discounts quick loans

First name

Middle name

Last name

Street

City

State/county

OK Apply Cancel Help


New Customers

checking


Account type Privileges

saving

mmf

CD

newsletter

discounts

quick loans

Branch

Main St.

Elm St.

High St.

New Customers

Name

First

Middle

Last

Address

Street

City

State/county


Applying Principles of Good Screen Design: “Before”

How Principles of Good Screen Design Were Applied

checking


Account type Privileges

saving

mmf

CD

newsletter

discounts

quick loans

Branch

Main St.

Elm St.

High St.

New Customers

Name

First

Middle

Last

Address

Street

City

State/county

Ensure consistency

Anticipate start

Align like elements

Grouplike elements

Border around like elements

Symmetry Balance

Proportion

Use Captions


• Provide a main menu / home page

• Display all relevant alternatives

• Menu structure should match application

tasks

• Minimize the number of menu levels

Develop System UI Structure

Hand Sketch User Interfaces

16


Preliminary Encounter Screen Shot

Name ofadjacent area




Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 20001), with permission. Graphics reproduced with permission from Corel.

Express Customer Requirements 1/2

• If the requirement is simple, and stands alone, express it in clear sentences within an appropriate section of the SRS

• If the requirement is an interaction between the user and the application, express via a use case. 1. Name the use case

2. Identify the “actor”

• the external user role-- usually a person

3. Write the sequence of user - application actions

• Minimize branching

• Use general form. Avoid specific names and values as in “Ed enters $300”. Instead, say “customer enters deposit amount”.


• If the requirement involves process elements, each taking inputs, and producing outputs, use data flow. 1. Identify the processing elements (usually high level); show

as circles or rectangles2. Identify the data sources & destinations; show

as names between two horizontal lines3. Show the data paths among processing elements.

Indicate types of data flowing on each

• If the requirement involves states that the application can be in (or parts can be in)1. Identify the states (each a passive

verb, e.g., “waiting”); show as rounded rectangles2. Show initial state with special arrow 3. Identify the events (happenings external to the unit) that

cause transitions among the states; show as labeled arrows4. Identify sub-states; show as rectangles within rectangles

Express CustomerRequirements 2/2

REQUIREMENTS ANALYSIS - C1. Plan project Integrate & test system Analyze requirements Design...

Documents

Transcript of REQUIREMENTS ANALYSIS - C1. Plan project Integrate & test system Analyze requirements Design...