Software Engineering Modern Approaches Eric Braude and Michael Bernstein 1 Chapter 12 © 2010 John Wiley & Sons Ltd. 2 Learning Goals of This Chapter Planning Maintenance • What ways are there to organize detailed requirements? • How do you express user interfaces in detail? • How do you express security requirements in detail? • What kinds of error conditions can be specified? • What is traceability and why is it important? • What ways are there to prioritize requirements? • Why associate requirements with tests? • How do agile methods relate to detailed requirements? • How do you use tools for requirements 3 analysis? Testing The Software Development Requirements Lifecycle analysis Implementation Design Phase most relevant to this chapter is shown in bold 3. Specific requirements (non-OO) 3.1 External interfaces 3.2 Functional requirements 3.3 Performance requirements 3.4 Logical database requirements 3.5 Design constraints 3.5.1 Standards compliance 3.6 Software system attributes 3.6.1 Reliability 3.6.2 Availability 3.6.3 Security 3.6.4 Maintainability 3.6.5 Portability 3.7 Organizing the specific requ. 3.7.1 System mode -- or 3.7.2 User class -- or 3.7.3 Objects (see right) -- or 3.7.4 Feature -- or 3.7.5 Stimulus -- or 3.7.6 Response -- or 3.7.7 Functional hierarchy -- or 3.8 Additional comments IEEE 830-1998 Detailed Requirements 3. Specific requirements (OO) 3.1 External interface requirements 3.1.1 User interfaces 3.1.2 Hardware interfaces 3.1.3 Software interfaces 3.1.4 Communications interfaces 3.2 Classes/Objects 3.2.1 Class/Object 1 3.2.1.1 Attributes 3.2.1.2 Functional requirements 3.2.1.3 Events . . . . ....... 3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.6 Other requirements 4 © 2010 John Wiley & Sons Ltd. The IEEE 830-1998 SRS Organization: Detailed Requirements with OO organization 3. Specific requirements 3.1. External interface requirements 3.1.1. User interfaces 3.1.2. Hardware interfaces 3.1.3. Software interfaces 3.1.4. Communications interfaces 3.2. Classes/Objects -- see section tbd -3.3. Performance requirements 3.4. Design constraints 3.5. Software system attributes 3.6. Other requirements Interface requirements Functional requirements Other non-functional requirements 5 © 2010 John Wiley & Sons Ltd. Organizing Requirements by Use Case: Video Store Example 1. User hits any key Activate Check in DVD 2. System displays main menu 1. User swipes bar code 2. System displays due data 3. ... clerk 1. . . . . Check out DVD Stock DVD 2. 1. User obtains “stock” screen 2. User enters name of DVD 3. . . . buyer © 2010 John Wiley & Sons Ltd. ......... 6 Organizing Video Store Requirements by GUI Stock DVD Title Figure 2 Number of copies 3.1 Selecting Procedures commit The GUI for selecting procedures shall be as shown in Figure 1. It shall be possible to select from the following procedures by clicking on a radio button, followed by the “go” button. …….. Sketch of Select Procedure GUI 3.3 Checking out DVD’s The GUI for checking out DVD’s shall be as shown in Figure 3. It shall be possible to … Check In DVD GUI Sketch Select Procedure Check Out DVD Stock DVD DVD name Register customer Figure 1 Check out DVD Figure 3 Check in DVD commit go 3.4 Registering Customers 3.2 Stocking DVD’s The GUI for stocking DVD’s shall be as shown in Figure 2. It shall be possible to enter a DVD into the system using the GUI in figure … The application shall save the title – expressed in up to 30 alphanumeric characters – and the number of copies. The latter shall range between 1 and 100, inclusive. ..… ….. Sketch of Register Customer GUI Register Customer First name Commit and check out DVD © 2010 John Wiley & Sons Ltd. Figure 4 Last name commit 7 1. Obtain domain classes & objects from use cases and high-level requirements diagrams 2. Add additional essential domain classes Inspect the resulting collection of classes 3 For each class, specify the required attributes specify the required functionality specify how its objects react to events draft test plans for each inspect the results Roadmap for Detailed Requirements Using the Class Style © 2010 John Wiley & Sons Ltd. 4. Inspect against high-level requirements 5. Verify with customer where possible When complete: 6. Release 8 Candidate Classes for Encounter Game Encounter Character Engagement Player Exit Area Combat Encounter Map Result Passageway (1) list every reasonable candidate class you can think of (this list), then (2) drastically cut down to a few essential classes. Room Rule Score Connection Hyperlink © 2010 John Wiley & Sons Ltd. Encounter Area Connection Engagement Display Foreign Character Game Character Player Window Exit Choice Window Quality Game Door 9 Classes for Encounter Video Game, Showing Only Inheritance Relationships EncounterCharacter EncounterAreaConnection ConnectionHyperlink PlayerCharacter ForeignCharacter PlayerQualityWindow Engagement EngagementDisplay Key: EncounterGame Area (1) list every reasonable candidate class you can think of then (2) drastically cut down to a few essential classes (this list). A class in design and code, blanks eliminated 10 © 2010 John Wiley & Sons Ltd. Methods of Organizing Requirements Organizing principle By Feature Advantages Maps well to why we are building the application Easy to understand Does not map well to OO code Hard to locate random requirement Easy to understand Use cases may overlap Hard to trace to design and code Coverage is limited Easy to understand Not every function appears in a GUI Functionality of GUI’s overlap Hard to trace to design and code Easy to understand Design thinking begins early Classification can be unclear to the customer Hard to allocate requirements to state Easy to trace to code Easy to locate random requirement Design thinking begins early Classification can be unclear to the customer By Use Case By GUI By State By Class © 2010 John Wiley & Sons Ltd. Disadvantages 11 • 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 Principles of Good Screen Design* • Apply a hierarchy to emphasize order of importance • Apply principles of pleasing visuals -- usually: – balance; symmetry; regularity; predictability – simplicity; unity; proportion; economy • Provide captions © 2010 John Wiley & Sons Ltd. * see Galitz [Ga2] 12 Applying Principles of Good Screen Design: “Before” Type checking Branch Main St. saving Elm St. Privileges newsletter mmf CD High St. discounts quick loans First name Middle name Last name Street City State/county OK Apply Cancel Help * see Galitz [Ga2] © 2010 John Wiley & Sons Ltd. 13 New Customers Applying Principles of Good Screen Design: “After” Name Address First Street Middle City Last State/county Branch Account type Elm St. High St. OK © 2010 John Wiley & Sons Ltd. Privileges checking saving mmf CD Main St. Apply Help newsletter discounts quick loans Cancel 14 New Customers Anticipate start Expected position Help Name Address First Street Align like elements Middle City Last State/county Border around like elements Branch Use Captions Account type Privileges checking saving mmf CD Symmetry Main St. Elm St. High St. Group like elements newsletter discounts quick loans Balance Proportion OK © 2010 John Wiley & Sons Ltd. Ensure consistency Apply Cancel How Principles of Good Screen Design Were Applied 15 1. Purpose: display properties of an entity -- property window Properties of automobile 189 Window Usage 1of 2 Property Value Brand Toyota Model Camry ID 893-8913-789014 2. Purpose: obtain additional information so as to carry out a particular task or command Help -- dialog window Word ___________________ This screen © 2010 John Wiley & Sons Ltd. All screens 16 3. Purpose: provide information -- message window Window Usage 2of 2 4. Purpose: present a set of controls -- palette window ABC alert message Caution: “age” must be < 120 OK ABC controls File Edit View Format Tools Help monitor 5. Purpose: amplify information -- pop-up window © 2010 John Wiley & Sons Ltd. disk keyboard modem This is a popup window, designed to provide onthe-fly amplification 17 Develop System Menus • 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 © 2010 John Wiley & Sons Ltd. 18 Common GUI Terms Cascading windows Tiled windows Icon New Customer Text box Name Screen First forward Last Radio button Button © 2010 John Wiley & Sons Ltd. back Account type checking saving mmf Cancel Privileges newsletter discounts Apply Check box 19 Graphics reproduced with permission from Corel. Detailed Security Requirements 1 1. User identification capabilities Rules on ID’s, name clashes, restrictions, etc. 2. Person or entity authentication capabilities Exact requirements permitting access to resources 3. Security logoff Measures to prevent unattended or unusual usage 4. Audit trails of security-related events Type, outcome, state at the time, date & time, source © 2010 John Wiley & Sons Ltd. 20 Detailed Security Requirements 2 5. Password specifications Length, composition, allows characters, etc. 6. Controls to ensure data integrity 7. Retrievable record of encryption methods 8. Information on security attributes of the system © 2010 John Wiley & Sons Ltd. 21 Requirement Without Necessary Errors (Myers) A function that tells whether three numbers produce an equilateral triangle (all sides equal), an isosceles triangle (exactly two sides equal), or a scalene triangle (all sides different). 22 © 2010 John Wiley & Sons Ltd. … More Complete A function that tells whether a triplet of numbers produces: (1) an equilateral triangle (whose sides are all greater than zero and equal), in which case it outputs ‘E’ at the prompt, or (2) an isosceles triangle (whose sides are greater than zero, exactly two of which are equal, and which form a triangle), in which case it outputs ‘I’ at the system, or (3) a scalene triangle (whose sides are all greater than zero, which form a triangle, and which is neither equilateral nor isosceles), in which case it outputs ‘S’ at the prompt, or (4) no triangle, in which case it outputs ‘N’ at the prompt. 23 © 2010 John Wiley & Sons Ltd. My-D-Requirement** Tracing a Detailed Requirement Requirement inspection report incorporating My-D-Requirement Design segment incorporating My-D-Requirement Design inspection report incorporating My-D-Requirement * Code Implementing My-D-Requirement Code inspection report incorporating My-D-Requirement Test plan incorporating My-D-Requirement Test plan inspection report incorporating My-D-Requirement Test report incorporating My-D-Requirement © 2010 John Wiley & Sons Ltd. * key traces ** D- = detailed 24 Requirements Traceability Matrix Module 1 Module 2 Module 3 Requirement 1783 1784 © 2010 John Wiley & Sons Ltd. getInterest() showAccount() computeBal() showAddress() showName() showName() 25 Tracing and Testing Functional vs. Non-Functional Requirements Inspect Design Element Design Element Design component Design Element Design Element Design Element Relevant components Non-functional Requirement Implementation Implemented by whole application tested by tests ... System Test 26 © 2010 John Wiley & Sons Ltd. Prioritizing Detailed Requirements [essential] Every game character has the same set of qualities. [desirable] Each area has a set of preferred qualities. [optional] The player’s character shall age with every encounter. The age rate can be set at setup time. Its default is one year per encounter. 27 © 2010 John Wiley & Sons Ltd. Associating a Requirement and its tests: Input and Expected Output © 2010 John Wiley & Sons Ltd. Test input for Requirement NNN Expected output Harry Harry X X " " (blank) "" (blank) 123456789012345 123456789012345 1234567890123456 123456789012345 ..... ..... 28 Agile Non-Agile Unit Tests and In-Code Comments as Detailed Requirements Customers shall be able to enter the name of a DVD in the text box, up to 20 alphanumeric characters. The application shall check this, with punctuation marks replaced by blanks, with the DVD inventory, and display accordingly “Sorry, we don’t stock this DVD” or “Added to your list.” public void testLookup() { // “Gone With The Wind” should be present dVDSearch.doSearch( “Gone With The Wind” ); ….. // “War and Peace” should be absent dVDSearch.doSearch( “War and Peace” ); ….. 29 © 2010 John Wiley & Sons Ltd. Combining Agile and non-Agile Methods /* Requirement 3.4.2: Customers shall be able to enter the name of a DVD in the text box, up to 20 alphanumeric characters. The application shall check this, with punctuation marks replaced by blanks, with the DVD inventory, and display accordingly “Sorry, we don’t stock this DVD” or “Added to your list.” */ public void testLookup() { // “Gone With The Wind” should be present dVDSearch.doSearch( “Gone With The Wind” ); ….. // “War and Peace” should be absent dVDSearch.doSearch( “War and Peace” ); ….. 30 © 2010 John Wiley & Sons Ltd. The Agile Programming Cycle 0. Understand high-level requirements 1. Understand next requirement 5. Refactor code – to clean up etc. As a pair* 4. Modify code base to pass the test. * (for many agile processes) © 2010 John Wiley & Sons Ltd. 2. Refactor code base to prepare for the requirement – if necessary 3. Write tests validating the requirement* 31 Example Spreadsheet for Tracking Requirements Requirement Priority Not Frac number Essential Optional started 1 Desirable Responsible engineer © 2010 John Wiley & Sons Ltd. 32 Example Spreadsheet for Tracking Requirements Status Requirement Priority Not Fraction com pleteReady for number Essential Optional started 1/3 2/3 Inspection Desirable Designed Inspected for Integration Unit tested tested Responsible engineer © 2010 John Wiley & Sons Ltd. 33 Hyperlink from Java Source to Corresponding D-Requirement Using javadoc /** <a href="RequAnal\# EngagingForeignCharacter "> Engagement Requirement 1 ("Engaging a foreign character") </a> The purpose of this method is stated in SRS. – not repeated with the source code. © 2010 John Wiley & Sons Ltd. 34 Hyperlink from Java Source to Corresponding D-Requirement Using javadoc /** <a href="RequAnal\# EngagingForeignCharacter "> Engagement Requirement 1 ("Engaging a foreign character") </a> . . . . Implementation comments . . . . */ public engageForeignCharacter( … ) { ..... } © 2010 John Wiley & Sons Ltd. 35 Status after initial draft Result of updating after high-level requirements Result of updating after detailed requirements Updating the Project on Completing Detailed Requirements Milestones Risks Schedule Personnel Cost Estimation © 2010 John Wiley & Sons Ltd. Initial More detailed More detailed Identify Retire risks identified previously; seek more risks Retire risks identified; identify more risks Very high level Preliminary project schedule More detailed: shows class & method development tasking Designate Crequirements engineers Engineers designated for D-requirements analysis Designate software architects First estimates based on job content Improved estimate using more specific function points and/or past experience with similar requirements36 Crude estimates This project // organization norm Time spent (minutes) % Time spent Preparation Interview Write-up (results of inspection) Review Total 200 mins 170 mins 270 mins 250 mins 14.8 hours 250/890 = 28% // 20% 170/890 = 19% // 23% 270/890 = 30% // 27% 200/890 = 22% // 29% Quantity produced 15 pages Postmortem Results Productivity (= Time/quantity) 15/14.8 = 1.01 pgs/hr // 0.95 Self-assessed quality (1-10) 9 5 Defect rate Process improvement 9 2 1.3 per page // 1.01 per page Spend ~20% less time preparing © 2010 John Wiley & Sons Ltd. Spread interview time more evenly among people Material should be checked more thoroughly prior to inspection. Spend ±30% more time reviewing 37 Encounter Courtyard Image (including game characters) kitchen Note: Each part of this figure is specified separately in section 3. COURTYARD living room dressing room User Interface for Status Elena Current life OK points: 56.38 Get status Graphics reproduced with permission from Corel. Set qualities End game © 2010 John Wiley & Sons Ltd. Strength Endurance Endurance Intelligence Patience Value 16.18 38 Encounter kitchen Courtyard Image COURTYARD dressing room living room Get status Set qualities End game © 2010 John Wiley & Sons Ltd. 39 Encounter Dressing Room Image DRESSING ROOM courtyard dungeon Get status Set qualities End game Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. © 2010 John Wiley & Sons Ltd. 40 Encounter Dungeon Image DUNGEON dressing room study Get status Set qualities End game © 2010 John Wiley & Sons Ltd. 41 Encounter Kitchen Image KITCHEN Get status Courtyard Set qualities End game Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. © 2010 John Wiley & Sons Ltd. 42 LIVING ROOM Encounter Living Room Image courtyard Get status Set qualities End game © 2010 John Wiley & Sons Ltd. study 43 Living room STUDY dungeon Encounter Study Image Get status Set qualities End game © 2010 John Wiley & Sons Ltd. 44 Encounter Area Configuration (Desirable Requirement) Kitchen Courtyard Living room Dungeon Study Dressing room Key: © 2010 John Wiley & Sons Ltd. = connection 45 User Interface for Status Elena Current life points: 56.68 Strength Endurance Endurance Intelligence Patience © 2010 John Wiley & Sons Ltd. Value 16.18 46 Graphics reproduced with permission from Corel. Foreign Character Freddie’s Image 47 © 2010 John Wiley & Sons Ltd. Graphics reproduced with permission from Corel. Player Character Image Options Elena Sean Boris 48 Graphics reproduced with permission from Corel. User Interface for Setting Quality Values Shawn Current life points: 100.0 Choose the quality you wish to set Choose the value of the quality selected 16.3 image 49 © 2010 John Wiley & Sons Ltd. Shawn Choose the quality you wish to set Current life points: 100.0 Image User Interface for Setting Quality Values Choose the value of the quality selected 16.3 Explanation The values of the qualities not specifically chosen remain in the same proportion to each other. Values less than 1.0 are counted as zero. E.g., before: strength = 10.0, endurance = 60.0, intelligence = 30.0, patience = 0.0 (current life points 10.0 + 60.0 + 30.0 + 0 = 100.0) change: strength from 10.0 to 20.0 after: strength = 20, endurance = 53.33, intelligence = 26.66 OK