3 REQUIREMENTS ANALYSIS I Software Engineering Roadmap Chapter

3 REQUIREMENTS ANALYSIS I

Software Engineering Roadmap: Chapter 3 Focus Obtain customer’s wants and needs (C-requirements) Identify corporate practices Refine requirements (next chapter) Express C-requirements prose use cases state diagrams data-flow diagrams Plan project Analyze requirements Maintain Integrate & test system Design Implement Test units Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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 – exploit data flow diagrams – sketch user interfaces • Be able to write first part of a SRS - Software Requirements Specification (part of S 1) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

1. Introduction to requirements analysis

C- vs D-Requirements SRS (IEEE) 1. Introduction 2. Overall description Crequirements Drequirements 3. Specific requirements 4. Supporting information 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.

1. Identify “the customer” -- see section 2. 2 Typical Road. Map for Customer (“C-”) Requirements 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 Review with customer 3. Write C-requirements in standard document form (see case study) For all stages, track metrics, e. g. , 4. Inspect • time spent C-requirements • quantity accomplished pages of C-requirements mins. of customer interaction per. On pg. customer approval. . . • self-assessed quality (1 -10 scale) 5. Build D-requirements • defect rates from inspections (next chapter) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

IEEE 830 -1993 SRS Table of Contents tbd: get copyright permission from IEEE 1. Introduction 2. 1. 6. Memory constraints 1. 1. Purpose 2. 1. 7. Operations 1. 2. Scope 2. 1. 8. Site adaptation 1. 3. Definitions, acronyms requirements & abbreviations 2. 2. Product functions 1. 4. References 2. 3. User characteristics 1. 5. Overview 2. 4. Constraints 2. Overall description 2. 5. Assumptions and 2. 1. Product perspective dependencies 2. 1. 1. System interfaces 2. 6. Apportioning of 2. 1. 2. User interfaces requirements 2. 1. 3. Hardware interfaces 3. Specific requirements 2. 1. 4. Software interfaces -- see chapter four - 2. 1. 5. Communications 4. Supporting information interfaces -- see chapter four --

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

2. Customer interaction

Project Stakeholders Stakeholder Perspective • • Scope Requirements (what) Arch. /Design (how) Implementation/Testing Owner Users Designers Builders What the Users wanted What the Owners are willing to pay What the Designers and Builders developed

Sources of Requirements: People vs. Other decision support system for military tactics unconstrained Encounter video game corporate accounting system manufacturing control system Type of application enhancement to corporate accounting system flight control system for airliner highly constrained Relatively low missile guidance system Approximate % of requirements gathered from people Relatively high

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

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

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 Handle Interviews 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

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 actors player designer Encounter Use case details Initialize Use case 1. System displays player’s Initialize main character in the dressing room. Travel to 2. System displays a window adjacent for setting his character's area qualities. 3. Player allocates the qualities of his main Encounter character. foreign 4. Player chooses an exit character from the dressing room. 5. System moves player’s main character into the area Set rules on the other side of the exit. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Engage Foreign Character Use Case Encounter Use case Initialize player Travel to adjacent area Engage foreign character designer Set rules Use case details 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. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Conceptual Model of the System Player 1 n Plays Has 1 1 1 Encounter. Game Entity Relationship Model or Object Model Has 1 Foreign. Character Main. Character 1 1 Has n Engagement n 1 Area Takes place in 1

Data Flow Diagram: Explanation of Symbols Processing element Direction of data flow Check deposit Get deposit Account # & deposit Data type

Data Flow Diagram: Explanation of Symbols Processing element Direction of data flow Check deposit Input Get deposit User Account # & deposit Output Data type Printer …. . . balance query account Data store database account data Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Create account summary

member banks bank name Partial Data Flow Diagram for ATM Application Get deposit Get inquiry User error account # & deposit account display Validate inquiry Validate deposit account # & deposit Display account data Do deposit transaction error Make inquiry account # Printer balance query account database account data Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Create account summary

Partial Encounter State-Transition Diagram Preparing Setting up Complete setup Waiting Player clicks qualities menu Foreign character enters area Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Engaging

Using Conditions in State-Transition Diagrams state event Waiting Player moves to adjacent area condition [foreign character present] [foreign charact er absent] condition Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Engaging state

Sketch of Encounter State-Transition Diagram Setting up Player completes setup Player dismisses set qualities widow Setting qualities Reporting Player dismisses report window Player requests status Player requests to set qualities Foreign character enters area Waiting Player moves to adjacent area Player quits [foreign character absent] Foreign character enters area Encounter completed Engaging [foreign character present] Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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 Steps for Constructing User Interfaces* (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) * adapted from Galitz [Ga 2] ‡ a C-requirement process

• Level of knowledge and experience – – – • Know Your Users* Characteristics of the user’s tasks and jobs – – – – • 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) 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 Gender Handedness Physical handicaps (young; middle aged; elderly) (male; female) * adapted from Galitz [Ga 2] (left; right; ambidextrous) (blind; defective vision; deaf; motor handicap)

• 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 Principles of Good – align like elements – group like elements Screen Design* – 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 * see Galitz [Ga 2]

Applying Principles of Good Screen Design: “Before” Type checking Branch Main St. Privileges saving Elm St. newsletter mmf CD High St. discounts quick loans First name Middle name Last name Street City State/county OK Apply Cancel Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Help * see Galitz [Ga 2]

Applying Principles of Good Screen Design: “After” New Customers Name Address First Street Middle City Last State/county Branch Account type Privileges checking saving mmf CD Main St. Elm St. High St. OK Apply Cancel newsletter discounts quick loans Help Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Anticipate start New Customers Name Address First Street Middle Align like elements Ensure consistency City Last Branch How Principles of Good Screen Design Were Applied State/county Border around like element Account type Use Captions Privileges checking saving Symmetry mmf CD Main St. Elm St. High St. Group like elements OK Proportion Apply Cancel newsletter discounts Balance quick loans Help Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Develop System Menus • Provide a main menu • Display all relevant alternatives (only) • Menu structure should match application tasks • Minimize the number of menu levels

Common GUI Terms Cascading windows Tiled windows Icon New Customer Text box Name Screen First forward Last Radio button Button back Account type checking saving mmf Cancel Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Privileges newsletter discounts Apply Check box Graphics reproduced with permission from Corel.

Preliminary Sketch of User Interface for Setting Game Character Qualities 16 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Preliminary Encounter Screen Shot Name of adjacent 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”. 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”); Express Customer show as rounded rectangles Requirements 2/2 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

5. Rapid prototyping, feasibility studies, and proofs of concept

Prototype Payoff: First Cut Calculate payoff in detail Perceived value of prototype low high Go for prototype Low prototype cost maybe yes High prototype cost no maybe Don’t bother with prototype Calculate payoff in detail Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Prototype Payoff from building prototype ($’s saved per $1 spent) full project expenditure optimal expenditure on prototype % expenditure on prototype 0% GUI only waste of resources Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. 100%

Prototype Payoff Calculations for E-commerce Clothing Application Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Feasibility Studies / Proof of Concept • Feasibility Study – An in depth cost / benefit analysis of the technical, operational or financial trade-off of a specific action – E. g. a new Internet site to sell videos on-line • Proof of Concept – To ensure the technological solution is valid or possible – E. g. mock-up of a new airplane for wind tunnel testing

6. Updating the project to reflect C-requirements analysis

Updating Project Plan After Obtaining C-requirements Status after initial draft Milestones Risks Schedule Personnel Cost Estimation Result of updating SPMP after obtaining C-requirements Initial More milestones; more specific Identify initial risks Retire risks identified previously; identify more risks now that more is known about the project Very rough Preliminary project schedule Designate Crequirements engineers Designated engineers for Drequirements analysis Very rough First estimates based on job content Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Typical Schedule After C-requirements Analysis Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

SRS rev. 2. 1 5/27/98 1. Introduction rev 3 2. 1. 6. Memory constraints 1. 1. Purpose rev 2 2. 1. 7. Operations 1. 2. Scope rev 3 2. 1. 8. Site adaptation requirements 1. 3. Definitions, acronyms & abbreviations rev 2 2. 2. Product functions 1. 4. References rev 1 2. 3. User characteristics 2. 4. Constraints 1. 5. Overview rev 3 2. Overall description rev 4 2. 5. Assumptions and 2. 1. Product perspective rev 4 dependencies 2. 1. 1. System interfaces rev 2 2. 6. Apportioning of 2. 1. 2. User interfaces rev 1 requirements 2. 1. 3. Hardware interfaces rev 1 3. Specific requirements 2. 1. 4. Software interfaces rev 4 -- see next chapter -4. Supporting information 2. 1. 5. Communications interfaces rev 1 rev 4 rev 3 rev 4 rev 1 rev 6 rev 3