1. 4 REQUIREMENTS ANALYSIS II

2. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap: Chapter 4 Focus Identify corporate practices Obtain C-Requirements (previous chapter) Obtain D-requirements - unambiguous - traceable - atomic - testable - consistent - complete Select manner of organizing D-requirements Distinguish types of D-requirements Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

3. Chapter Learning Goals Be equipped with options for organizing D-requirements –by class –by use case –by feature –by event …... Be able to complete requirements –be detailed enough to enable all design and complete implementation –be able to express the non-functional requirements e.g., performance Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

4. 1. Introduction to "specific" (or "D-") requirements

5. RoadMap for Detailed (“D-”) Requirements 1. Select organization of D-requirements -- see section tbd 2a. Obtain D-requirements from C-requirements & customer 2b. Outline test plans -- see section tbd In parallel... 2c. Inspect -- see section tbd..

6. RoadMap for Detailed (“D-”) Requirements 1. Select organization for D-requirements -- section 5 3a. Obtain D-requirements from C-requirements & customer 3b. Outline test plans -- chapter eight 4. Validate with customer 5. Release -- see section tbd when unit approved by customer... Apply customer feedback In parallel... 3c. Inspect -- section 6.3 2. Create sequence diagrams from use cases -- section 4 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

7. 1. Functional requirements the application's functionality 2. Non-functional requirements 2.1 Performance –speed –capacity (traffic rates) –memory usage RAM disk 2.2 Reliability and availability 2.3 Error handling Types of Requirements 1/2 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

8. 2.4 Interface requirements how the application interacts with the user, and with other applications 2.5 Constraints –accuracy –tool and language constraints e.g. “FORTRAN 88 must be used” –design constraints –standards to be used –hardware platforms to be used 3. Inverse requirements what the application does not do Types of Requirements 2/2 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

9. The IEEE 830-1994 SRS Organization: Specific 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 -- Functional requirements Interface requirements

10. The IEEE 830-1994 SRS Organization: Specific 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 Functional requirements Other non-functional requirements Inverse requirements can be stated here Interface requirements

11. 3. Desired properties of D-requirements

12. Tracing a D-Requirement My-D-Requirement Design segment incorporating My-D-Requirement Requirement inspection report incorporating My-D-Requirement Design inspection report incorporating My-D-Requirement..

13. * Test report incorporating My-D-Requirement My-D-Requirement Test plan incorporating My-D-Requirement Design segment incorporating My-D-Requirement Requirement inspection report incorporating My-D-Requirement Test plan inspection report incorporating My-D-Requirement Design inspection report incorporating My-D-Requirement Code inspection report incorporating My-D-Requirement *key traces Code Implementing My-D-Requirement Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Tracing a D-Requirement

14. Module 1Module 2Module 3 Require- ment 1783 showName()computeBal()getInterest() 1784 showAccount()showAddress()showName() Table 4.1 Requirements Traceability Matrix Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

15. Design Element Tracing and Testing of Functional D-Requirements Functional Requirement 278Unit Test 2694 + Design validated by Design Element ABCD trace Implementation Design Element Code Element EFGH implemented by Requirements Analysis Testing applies to... trace Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

16. Design Element System Test Design Element tested by Implemented by whole application try to isolate relevant components Non-functional Requirement tests... Tracing and Testing Functional vs Non-Functional Requirements Functional RequirementUnit Test + Design Element Requirements phase Test phase tested by Inspect Implementation assignment Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.Graphics reproduced with permission from Corel.

17. The system shall display the difference in salary between the client and the world wide average for the same trade  -- can't be tested because the average mentioned cannot be determined (event though it exists). Testability..

18. The system shall display the difference in salary between the client and the world wide average for the same trade  -- can't be tested because the average mentioned cannot be determined (event though it exists).  Better: The system shall display the difference in salary between the client and the estimated world-wide average for the same trade as published by the United Nations on its website www.tbd at the time of the display....www.tbd Testability Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

19. The player can decide the qualities of Encounter characters.  At any time? Probably not. Would have to test under all circumstances, many not intended, incurring unnecessary expense, and producing a wrong result. Ambiguity..

20.  Better version: Whenever all foreign players are absent from the area containing the player's main character, the player may change the quality values of this character, keeping the sum total of the quality values unchanged. The PlayerQualityWindow, (see section tbd) is used for this purpose. Changes take effect four seconds after the “OK” button is pressed. The player can decide the qualities of Encounter characters.  At any time? Probably not. Would have to test under all circumstances, many not intended, incurring unnecessary expense, and producing a wrong result. Ambiguity Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

21. Prioritizing D-requirements [essential] Every game character has the same set of qualities. [desirable] [optional] 1. Essential? 3. Optional? 2. Otherwise: Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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

23. Completeness No omissions which compromise the stated requirements. 1. The application shall display a video in stock when a title is entered at the prompt, or “OUT” when not in stock 2. The application shall display all of the store’s videos by any director whose last name is entered at the prompt. 2.1 Sequencing shall controlled by the forward arrow key.

24. No omissions which compromise the stated requirements. BEGIN REQUIREMENTS 1. The application shall display a video in stock when a title is entered at the prompt, or “OUT” when not in stock 2. The application shall display all of the store’s videos by any director whose last name is entered at the prompt. 2.1 Sequencing shall be controlled by the forward arrow key. 3. The application shall display all of the store’s videos by any actor whose last name is entered at the prompt. 3.1 Sequencing shall be controlled by the forward arrow key. END REQUIREMENTS Incomplete: specify how to “display” a video! Completeness:

25. Requirement Without Necessary Errors (Myers) A function that tells whether three numbers produce an equilateral triangle (whose sides are all equal), an isosceles triangle (containing exactly two equal sides) or a scalene triangle (a triangle which is neither equilateral nor isosceles).

26. 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. … More Complete

27. Consistency No contradictions among requirements. Requirement 14. Only basic food staples shall be carried by game characters... Requirement 223. Every game character shall carry water.... Requirement 497. Flour, butter, milk and salt shall be considered the only basic food staples. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

28. Write a Detailed Requirement 1 1. Classify requirement as functional or non-functional –IEEE SRS prompts for most non-functional –select method for organizing functional requirements 2. Size carefully –a functional requirement corresponds ± to a method –too large: hard to manage –too small: not worth tracking separately 3. Make trace-able if possible –ensure suitable for tracking through design and implementation 4. Make testable –sketch a specific test that establishes satisfaction Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

29. Write a Detailed Requirement 2 5. Make sure not ambiguous –ensure hard to misunderstand intention 6. Give the requirement a priority –e.g., highest (“essential”); lowest (“optional”); neither (“desirable”) 7. Check that requirement set complete –for each requirement, ensure all other necessary accompanying requirements are also present 8. Include error conditions –state what’s specifically required for non-nominal situations –include programmer errors for critical places 9. Check for consistency –ensure that each requirement does not contradict any aspect of any other requirement Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

30. 4. Sequence diagrams

31. Beginning of Sequence Diagram for Initialize Use Case dressing room: Area 1. create :Encounter- Game time

32. Beginning of Sequence Diagram for Initialize Use Case create main player character: Player Character dressing room: Area 1. create note 1 note 4 :Encounter- Game note 3 note 2 time Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

33. Encounter- game Sequence Diagram Showing Concurrency freddie: ForeignCharacter move mainPlayer- Character: PlayerCharacter create & display move create & display Player Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

34. User :Encounter- Game main player character: Player Character 1*.1 create 5. move Sequence Diagram for Initialize Use Case * Numbering keyed to use case 1. create 2. create 3b. set quality values :Player quality window dressing room: Area 4. select exit for character 3a. set quality values Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

35. Build a Sequence Diagram 1 1. Identify the use case whose sequence diagram you will build 2. Identify which entity initiates the use case –the user, or –an object of a class name the class name the object 3. Draw a rectangle to represent this object at left top –use UML object:Class notation 4. Draw an elongated rectangle beneath this to represent the execution of an operation 5. Draw an arrow pointing right from its top myObject :MyClass Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

36. Build a Sequence Diagram 2 6. Identify which entity handles the operation initiated –an object of a class name the class name the object 7. Label the arrow with the name of the operation –don’t show return 8. Show a process beginning, using an elongated rectangle 9…… Continue with each new statement of the use case. MyObject :MyClass MyObject1 :MyClass1 My operation Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

37. 5. Organizing D-requirements

38. Ways of Organizing Detailed Requirements … Feature … Use case … Class … Function hierarchy … State by... Graphics reproduced with permission from Corel.

39. 3.1 External interfaces 3.2 Functions 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.7.8 Additional comments -- or 3. Specific requirements (non-OO) IEEE 830-1994 Specific (“D-”) Requirements

40. 3.1 External interfaces 3.2 Functions 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.7.8 Additional comments -- or 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 (direct or inherited) 3.2.1.1.1 Attribute 1....... 3.2.1.2 Functions (services, methods, direct or inherited) 3.2.1.2.1 Functional requirement....... 3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.6 Other requirements 3. Specific requirements (OO) 3. Specific requirements (non-OO) IEEE 830-1994 Specific (“D-”) Requirements

41. Organizing Requirements by Use-case: Video Store Example clerk 1. User swipes bar code 2. System displays due data 3.... Check in Check out 1..... 2. Activate 1. User hits any key 2. System displays main menu buyer Add video 1. User gets “stock” screen 2. User enters name of video 3............. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

42. Dispatcher Warehouse worker Use Case Generalizations & Extensions Warehouse A. System displays main options B. User selects icon Plan route Perform warehouse transaction Modify Stock A. System displays main options 1. User moves cursor to stock icon B. User selects icon 2. System displays stock window Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. «extends»

43. RoadMap for Detailed (“D-”) Requirements using the OO style 1. Obtain domain classes & objects from sequence diagrams 2. Add additional essential domain classes -- see section tbd Inspect the resulting collection of classes... Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

44. RoadMap for Detailed (“D-”) Requirements using the OO style 1. Obtain domain classes & objects from sequence diagrams 2. Add additional essential domain classes -- see section tbd Inspect the resulting collection of classes 3 For each class, specify the required attributes specify the required functionality specify the specific required objects specify how its objects react to events draft test plans for each inspect the results 4. Inspect against C-requirements 5. Verify with customer where possible When complete: 6. Release Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

45. Classes in Initialize Sequence Diagram EncounterGame - a class with a single object PlayerCharacter - with object mainPlayerCharacter Area - with object dressingRoom, and PlayerQualityWindow - a GUI class included to complete the use case. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

46. :Encounter- Game 1*. «create» Sequence Diagram for Initialize Use Case 1. «create» Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. main player character: Player Character dressing room: Area

47. User :Connection Hyperlink Sequence Diagram for Travel to Adjacent Area Use Case 1.1 hit 1.2 display other area :AreaConnection :Area 2.1 display 2.2 display :PlayerCharacter Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

48. Sequence Diagram for Engage Foreign Character Use Case 2. execute anEngagement : Engagement Encounter game freddie: Foreign Character 1.1 create; display 1.2 create Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

49. 1.1 create; display Sequence Diagram for Engage Foreign Character Use Case 2.1 execute 3.1 Display result 3.2 create :Engagement Display :Engagement 2.2 change quality values 1.2 create :Player Character :Encounter Game freddie: Foreign Character Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

50. Candidate Classes for Encounter Game (1) list every reasonable candidate class you can think of (this list), then (2) drastically cut down to a few essential classes. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

51. Candidate Classes for Encounter Game Area Encounter PlayerForeignCharacter EncounterCharacter PlayerWindow Game GameCharacter Quality Room Door Exit Rule Engagement Result Combat Score ExitChoiceWindow Map (1) list every reasonable candidate class you can think of (this list), then (2) drastically cut down to a few essential classes. Passageway EncounterAreaConnection EngagementDisplay ConnectionHyperlink Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Shaded: retain from sequence diagrams

52. Filtering Candidate Domain Classes 1 Encounter: Change to EncounterGame to make its purpose clearer Game: Not a domain class -- too general GameCharacter: too general to be within the domain Player: PlayerCharacter is more specific to the domain, and should replace it ForeignCharacter: OK  act differently from the player character Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

53. Filtering Candidate Domain Classes 2  Quality: OMIT -- try to handle as simple attribute of GameCharacter  Room: OMIT -- not sure if we need this; already have Area  Door: OMIT -- not sure we’ll need it -- see Exit  Exit: Not sure if we need this: leads to neighboring area -- try as simple attribute of Area -- OMIT for now  Rule: OMIT -- not sure we’ll need it  Area: OK Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

54.  Engagement: OK  Passageway: Use EncounterAreaConnection  Result: OMIT -- vague  Combat: OMIT -- not sure we’ll need it -- already have Engagement  Score: OMIT -- try as attribute of other classes  PlayerQualityWindow: needed for Initialize u. c.  ExitChoiceWindow: OMIT -- not needed  Map: OMIT -- not required yet  EngagementDisplay: OK -- needed by use case Filtering Candidate Domain Classes 3 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

55. Classes for Encounter Video Game Key: A class:Class with 1 object (1) list every reasonable candidate class you can think of then (2) drastically cut down to a few essential classes (this list): But retain classes used in sequence diagrams. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

56. Classes for Encounter Video Game, Showing Only Inheritance Relationships Area EncounterGame «singleton» Engagement PlayerCharacter «singleton» ForeignCharacter EncounterCharacter PlayerQualityWindow «singleton» Key: A class:Class with 1 object EngagementDisplay (1) list every reasonable candidate class you can think of then (2) drasti- cally cut down to a few essential classes (this list). EncounterAreaConnection ConnectionHyperlink Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

57. Select Domain Classes for Classifying Requirements 1. Develop a comprehensive, non-overlapping collection of use cases. 2. Create a sequence diagram for every use case. –take care in identifying the classes and objects 3. Gather the classes used in the sequence diagrams. 4. Determine essential additional domain classes. 5. Classify the detailed functional requirements by these classes. 5.1 list each attribute as a requirement 5.2 list each specific object of this class that must exist 5.3 list each function required of objects in this classification 5.4 list the events that all objects of the class must react to Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

58. Test input for Requirement NNN Expected output Harry XX " " (blank) 123456789012345 1234567890123456123456789012345..... Table 4.2 Test Input and Expected Output Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

59. Require- ment Trace- able back- ward Compl ete Con- sisten t Feasi ble Non- am- biguou s ClearPrecise Modifi- able Test- able Traceab le forward Note 14 Area Require- ment 1 Note 2 Note 1 Yes No 1YesNo 1No 2No 1, 2 Yes Area Require- ment 2 Yes No 3YesNo 3Note 3 Yes Area Requir e-ment 6 YesNote 5 YesNo 3 No 5Yes Table 4.3 Example of Inspection Results on D-Requirements Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

60. Example Spreadsheet for Tracking Requirements Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

61. Example Spreadsheet for Tracking Requirements Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

62. 5. Organizing D-requirements

63. Hyperlink from Java Source to Corresponding D-Requirement Using javadoc /** Engagement Requirement 1 ("Engaging a foreign character") The purpose of this method is stated in SRS. It is not repeated in the source code....

64. Hyperlink from Java Source to Corresponding D-Requirement Using javadoc /** Engagement Requirement 1 ("Engaging a foreign character").... Implementation comments.... */ public engageForeignCharacter( … ) {..... } The purpose of this method is stated in SRS. The purpose is not repeated with the source code. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

65. For example, if t is the table 57 211 12 -- then augmenting t with input (2, 4) yields the table 57 24 12 -- and augmenting t with input (3, 6) yields the following table. 57 211 12 36 Example of Z-specifications Hayes et al If t is the table ….

66. Z-specification for Augmenting a Table 1 t, t’ : N -> N l?, r? : N Augment function between integers value of t after application Declaration of variables and types Procedure name The set of natural numbers (see “Math” appendix) ? denotes input Hayes et al

67. Z-specification for Augmenting a Table 2 t, t’ : N -> N l?, r? : N t’ = t  {l?  r? } Augment Effect of application “t augmented by mapping l? to r?” Hayes et al

68. Z-specification for Lookup ( see Hayes) t, t’ : N -> N l?, r! : N Lookup Name of an output Hayes et al

69. Z-specification for Lookup t, t’ : N  N l?, r! : N Lookup Name of an output [ l?  dom( t )  r! = 0  t’ = t ]  [ l?  dom( t )  r! = t( l? )  t’ = t ] … is not an element of... Domain of the function … (i.e., the elements upon which it operates) and... The table t is unchanged or... Hayes et al

70. Domain element A Range element A(x) 14 26 33 44 56 68 Table 4.4 The Array A

71. Z-specification for Sorting Example t, t´ : N N dom(t´) = dom(t)  rng(t´) = rng(t)   x, y  dom(t), x  y  t´(x)  t´(y)   x  rng(t´), card[ t´ -1 (x) ] = card[ t -1 (x) ] Sort Partial function (see above) Range of t

72. Z-specification for Sorting Example t, t´ : N N dom(t´) = dom(t)  rng(t´) = rng(t)   x, y  dom(t), x  y  t´(x)  t´(y)   x  rng(t´), card[ t´ -1 (x) ] = card[ t -1 (x) ] Sort Partial function (see above) Range of t Number of elements in the set... Set of elements mapped onto x by t “implies”

73. Z-specification for Maximum t : N -  N m!, n! : N Maximum

74. Z-specification for Maximum t : N -  N m!, n! : N n!  dom(t)  m! = t(n!)   i  dom(t), [ t(n!)  t(i), and if t(n!) = t(i) then n!  i] Maximum Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

75. Pre- and Post-condition Form for Maximum t : N -  N m!, n! : N n!  dom(t)  m! = t(n!)   i  dom(t), t(i)  t(n!)  i  n! Maximum Precondition: t is an array of length lg > 0 Z-specification Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

76. Pre- and Post-condition Form for Maximum t : N -  N m!, n! : N n!  dom(t)  m! = t(n!)   i  dom(t), t(i)  t(n!)  i  n! Maximum Precondition: t is an array of length lg > 0 Postcondition: 0 <= n < lg // n index of max m = t[n] // m is max value t[i] <= m for i = 0, …, lg-1 if t[j] = m then j >= n // first Z-specification Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

77. Status after initial draft Result of updating after C-requirements Result of updating after D-requirements Milestones InitialMore detailed Risks Identify Retire risks identified previously; seek more risks Retire risks identified; identify more risks Schedule Very high level Preliminary project schedule More detailed: shows class & method development tasking Personnel Designate C- requirements engineers Engineers designated for D-requirements analysis Designate software architects Cost Estimation Crude estimates First estimates based on job content Improved estimate based on more specific function points and/or past experience with similar individual requirements Table 4.5 Updating the Project on Completing D-Requirements Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

78. Summary of This Chapter D-requirements for developers Goals: clarity, traceability Good organization helps –e.g., OO style Use formal methods sometimes Update SPMP as a result Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

79. Foreign Character Freddie’s Image Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.Graphics reproduced with permission from Corel.

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

81. User Interface for Setting Quality Values Sean Choose the quality you wish to set 16.3 Current life points: 100.0 Choose the value of the quality selected image... Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.Graphics reproduced with permission from Corel.

82. User Interface for Setting Quality Values The values of the qualities not specifically chosen remain in the same proportion to each other. Values less than 0.5 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.0 = 100.0) change: strength from 10.0 to 20.0 after: strength = 20.0, endurance = 53.3, intelligence = 26.7 16.3 Current life points: 100.0 Image Choose the quality you wish to set Choose the value of the quality selected Explanation Sean OK Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.Graphics reproduced with permission from Corel.

83. Case Study

84. dressing room kitchen living room COURTYARD OK Set qualities End game Note: Each part of this figure is specified separately in section 3. Get status Graphics reproduced with permission from Corel. Encounter Courtyard Image (including game characters)

85. Encounter Courtyard Image dressing room kitchen living room Set qualities End game kitchen COURTYARD Get status Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

86. courtyard DRESSING ROOM dungeon Set qualities End game Get status Encounter Dressing Room Image Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

87. Encounter Dungeon Image study dressing room DUNGEON Set qualities End game Get status Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

88. Courtyard KITCHEN Set qualities End game Get status Encounter Kitchen Image Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

89. LIVING ROOM courtyard study Set qualities End game Get status Encounter Living Room Image Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

90. dungeon Set qualities End game STUDY Get status Encounter Study Image Living room Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

91. Encounter Area Configuration (Desirable Requirement) Dressing room Courtyard DungeonStudy Key:= connection Living room Kitchen Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

92. User Interface for Status Elena Current life points : 56.68 Strength Endurance Intelligence Patience Value 16.18 Endurance Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.Graphics reproduced with permission from Corel.