Software Engineering: Requirements Analysis for Customer Perspective, Study notes of Software Engineering

Download Software Engineering: Requirements Analysis for Customer Perspective and more Study notes Software Engineering in PDF only on Docsity!

REQUIREMENTS ANALYSIS

(Customer Perspective)

GA Tech CS 3300 AY 2002

Fall 2001

Chapter Learning Goals

• Distinguish C- (Customer) requirements

from D- (Detailed) requirements

• Be equipped with ways

to express C-requirements

• exploit use cases
• exploit state diagrams
• sketch user interfaces
• Be able to write first parts of a

Software Requirements Specification

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

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.

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.

Typical RoadMap for Customer (“C-”) Requirements

1. Identify “the customer” -- see section 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-requirements in standard document form (see case study)
        4. Inspect C-requirements
           5. Build D-requirements (next chapter)

On customer approval ...

Review with customer

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

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. Overview
2. 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 requirements

3. Specific requirements -- see chapter four --
4. Supporting information -- see chapter four --

tbd: get copyright permission from IEEE

Example Application: 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 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.

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

Example Application: 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. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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 meeting

After interview:

5. Draft SRS C-requirements using a standard

6. E-mail customer for comments

Handle Interviews

Initialize Use Case for Encounter

Encounter foreign character

player

designer (^) Set rules

actors Encounter

Travel to adjacent 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.

Initialize

Use case

Use case details

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

Engage Foreign Character Use Case

player

designer

Initialize

Use case

Encounter

Travel to adjacent 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.

Engage foreign character

Use case details

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

Partial Encounter State-Transition Diagram

Setting up Preparing

Waiting

Complete

setup

Foreign

character

enters

area

Engaging

Player

clicks

qualities

menu

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

Using Conditions in State-Transition Diagrams

Engaging

Waiting

[foreign

character

absent]

[foreign

character

present]

Player

moves to

adjacent

area

event

condition

condition

state

state

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

Setting qualities

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 area Player quits

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

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 ÝÝÝÝ **explain every term **** ]
  • system experience high / moderate / [ low ÝÝÝÝ provide examples & animations ]
  • experience with similar applications high / moderate / [ low (^) ÝÝÝÝ provide examples & animations ]
  • education advanced degree / [ college / high school ÝÝÝÝ use 12th-grade terms ]
  • reading level >12 year’s schooling / 5-12 / [ < 5 (^) ÝÝÝÝ use very simple language ]
  • typing skill 135 wpm / 55 wpm / [ 10 wpm ÝÝÝÝ provide smaller text boxes; provide samples; emphasize fill-in-the-blank forms ]
• Physical characteristics of the user
  • Age young / middle aged / [ elderly ÝÝÝÝ use age-appropriate examples ]
  • Gender male / female
  • Handedness left / right / ambidextrous
  • Physical handicaps blind / defective vision / deaf / motor handicap

Know Your Users 1*

• adapted from Galitz [Ga2] ** suggested actions for the latter, added by the author

• 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]

Express Customer Requirements 1/

• 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”. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

• 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 rectangles
2. Identify the data sources & destinations; show as names between two horizontal lines
3. 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 rectangles
2. Show initial state with special arrow
3. Identify the events (happenings external to the unit) that cause transitions among the states; show as labeled arrows
4. Identify sub-states; show as rectangles within rectangles

Express Customer

Requirements 2/

Chapter Summary

• C-requirements for customer
  • include user interfaces
• D-requirements for developers
• Use standard SRS (e.g. IEEE)
• Use cases shown very effective
  • reuse as test cases
• State- and class diagrams can be effective

specifications as well

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