1. 3 REQUIREMENTS ANALYSIS I

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

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

4. 1. Introduction to requirements analysis

5. 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.

6. 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.

7. 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-requirements in standard document form (see case study) Review with customer Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

8. For all stages,track metrics, e.g., time spent quantity accomplished pages of C-requirements mins. 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-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.

9. 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

10. 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

11. 2. Customer interaction

12. Relatively high Relatively low Sources of Requirements: People vs. Other Approximate % of requirements gathered from people Type of application highly constrained unconstrained missile guidance system decision support system for military tactics

13. Relatively high Relatively low Sources of Requirements: People vs. Other (adapted from Brackett [Br] Approximate % of requirements gathered 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

14. 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.

15. 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.

16. 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

17. 4. Describing customer (C-) requirements

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

19. 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.

20. 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.

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

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

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

24. 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.

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

26. 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.

27. 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:..... Steps for ConstructingUser Interfaces* * adapted from Galitz [Ga2] ‡ a C-requirement process

28. 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

29. 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

30. 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]

31. 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]

32. Applying Principles of Good Screen Design: “Before” * see Galitz [Ga2] TypecheckingsavingmmfCD BranchMain St. Elm St.High St. Privilegesnewsletter discountsquick loans First name Middle name Last name Street City State/county OKApply CancelHelp Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

33. Applying Principles of Good Screen Design: “After” checking OKApplyCancelHelp Account typePrivileges 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 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

34. How Principles of Good Screen Design Were Applied checking OKApplyCancelHelp Account typePrivileges 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 Group like elements Border around like elements SymmetryBalance Proportion Use Captions Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

35. Window Usage 1of 2 2. Purpose: obtain additional information so as to carry out a particular task or command -- dialog window Properties of automobile 189 PropertyValue BrandToyota ModelCamry ID893-8913-789014 Help Word ___________________ This screen All screens 1. Purpose: display properties of an entity -- property window Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

36. 3. Purpose: provide information -- message window 4. Purpose: present a set of controls -- palette window 5. Purpose: amplify information -- pop-up window Window Usage 2of 2 ABC alert message Caution: “age” must be < 120 OK This is a popup window, designed to provide on-the-fly amplification ABC controls File Edit View Format Tools Help monitordiskkeyboardmodem Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

37. Provide a main menu Display all relevant alternatives (only) Match the menu structure to the structure of the application’s task Minimize the number of menu levels –Four maximum? Develop System Menus

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

39. 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.

40. Preliminary Encounter Screen Shot Name of adjacent area Name of adjacent area Name of adjacent area 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.

41. 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.

42. 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/2

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

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

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

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

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

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

49. 6. Updating the project to reflect C-requirements analysis

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

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

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

53. SRS rev. 2.1 5/27/98 1. Introduction rev 3 1.1.Purpose rev 2 1.2.Scope rev 3 1.3.Definitions, acronyms & abbreviations rev 2 1.4.References rev 1 1.5.Overview rev 3 2. Overall description rev 4 2.1.Product perspective rev 4 2.1.1. System interfaces rev 2 2.1.2. User interfaces rev 1 2.1.3. Hardware interfaces rev 1 2.1.4. Software interfaces rev 4 2.1.5. Communications interfaces rev 1 2.1.6. Memory constraints rev 4 2.1.7. Operations rev 1 2.1.8. Site adaptation requirements rev 4 2.2.Product functions rev 3 2.3.User characteristics rev 3 2.4.Constraints rev 3 2.5.Assumptions and dependencies rev 4 2.6.Apportioning of requirements rev 1 3. Specific requirements rev 6 -- see next chapter -- 4. Supporting information rev 3

54. 7. Future directions and summary of C- Requirements

55. 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 data flow- diagrams can be effective specifications as well Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

56. Student Guide and Case Study

57. This project // organization norm PreparationInterviewWrite-up (results of inspection) ReviewTotal Time spent (minutes) 200 mins170 mins270 mins250 mins14.8 hours % Time spent250/890 = 28% // 20% 170/890 = 19% // 23% 270/890 = 30% // 27% 200/890 = 22% // 29% Quantity produced 15 pages Productivity (= Time/quantity) 15/14.8 = 1.01 pages per hour // 0.95 Self-assessed quality (1-10) 9592 Defect rate 1.3 per page // 1.01 per page Process improvement Spend ~20% less time preparing Spread interview time more evenly among different people Material well written initially, but should be checked more thoroughly prior to inspection. Spend ±30% more time reviewing Table 3.2 Postmortem Results Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.