1. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 1 Requirements Management with Use Cases Module 7 Refining the System Definition

2. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 2 Course Outline 0 - About This Course 1 - Best Practices of Software Engineering 2 - Introduction to RMUC 3 - Analyzing the Problem 4 - Understanding Stakeholder Needs 5 - Defining the System 6 - Managing the Scope of the System 7 - Refining the System Definition 8 - Managing Changing Requirements 9 - Requirements Across the Product Lifecycle

3. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 3 Refining the System Definition: Overview Problem Solution Space Problem Space Needs Features Software Requirements The Product To Be Built Test Procedures DesignUser Docs Traceability

4. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 4 What Do Software Requirements Specify? System Inputs Outputs Functions Performance Environments Software requirements specify externally observable capabilities and conditions of the system

5. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 5 Specifying the Software Requirements Features Software Requirements Needs Supplementary Specifications Vision Document Traditional SRS OR ?? The Software Requirements Specification (SRS) defines the complete external behavior and characteristics of the system to be built. Use-Case Model

6. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 6 Adapted from Alan Davis Software Requirements Specification (SRS) Roles of the SRS  Basis of communication between all parties  Input to design team  Input to software test and quality assurance  Input to user documentation  Contractual agreement between parties  The software manager’s reference  Controls evolution of system

7. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 7 Features Drive Software Requirements Feat 63 - the defect tracking system will provide trending information to help the project manager assess project status Trending information will be charted with a line graph showing time on the x axis, and number of defects found on the y axis. Trending periods can be entered in units of days, weeks or months. An example trend report is shown in Figure 1: Print Status Report Operator Project Manager

8. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 8 Focus on the Use-Case Model Approach Supplementary Specifications Features Software Requirements Vision Document Needs Traditional SRS Use-Case Model 

9. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 9 How Do Use Cases Help Define Requirements?  A use case models a dialogue between one or more actors and the system.  A use case describes the actions the system takes to deliver something of value to the actor.  A use case is initiated by an actor to invoke a certain functionality in the system.  A use case is a complete and meaningful flow of events, taken from the perspective of a particular actor.  Taken together, all use cases constitute all possible ways of using the system. Use-Case Model

10. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 10 How to Detail a Use Case  Make the description from the “Find Use Cases and Actors” activity gradually more detailed  Decide on the following to ensure consistency across use cases:  How does the use case start?  How does the use case terminate?  How does the use case interact with actors?  How does the use case exchange data with an actor?  How does the use case repeat some behavior?  Are there any optional situations in a use case’s flow of events?  How should the use case be described so that the customer and the users can understand it?

11. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 11 1. Brief Description 2. Flow of Events Basic Flow of Events Alternative Flows of Events 3. Special Requirements 4. Pre-Conditions 5. Post-Conditions 6. Extension Points 7. Relationships 8. Use-Case Diagrams 9. Other Diagrams/enclosures 1. Brief Description 2. Flow of Events Basic Flow of Events Alternative Flows of Events 3. Special Requirements 4. Pre-Conditions 5. Post-Conditions 6. Extension Points 7. Relationships 8. Use-Case Diagrams 9. Other Diagrams/enclosures Use-Case Report: Template The Use-Case Report contains information regarding an individual use case within the use- case model. TP: Use Case Report Template

12. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 12 Use-Case Properties in the Use-Case Report  Name (same as Use-Case-Model Survey)  Brief description (same as Use-Case-Model Survey)  Flow of events  The use case’s behavior  What the actors do, what the system does in response  Special requirements (optional)  Requirements that are not covered in flow of events  Usually non-functional constraints  Pre-conditions (optional)  Constraints on when the use case may start  Post-conditions (optional)  Constraints on the system after the use case has ended

13. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 13 Use-Case Properties in the Use-Case Report (cont.)  Extension points (optional)  Places in the flow of events to attach extensions  Relationships  Associations with actors and with other use cases  Use-Case diagrams (optional)  Visual model of all relationships involving this use case  Other Diagrams or enclosures(optional)  Interaction, activity, or other diagrams  Pictures of the user interface Hand-drawn sketches or screen-dumps from an user-interface prototype, clarifying the use case

14. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 14 Sample Basic Flow of Events Recycle Items 1. Start of Use Case The use case begins its flow of events when a can, bottle, or crate (a deposit item) is inserted by the customer. 2. Determine Type The system reads a bar code on the deposit item. It compares the code with a list of valid codes to determine whether this is a valid deposit item, and which type of deposit item it is. 3. Receive Next Deposit Item Once the type has been determined, the system updates the daily total for that deposit item type. Then, the system prepares itself to receive the next item. If an item is inserted, continue at 2. Determine Type.

15. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 15 Sample Basic Flow of Events (cont.) 4. Prepare to Print Receipt After having inserted a number of deposit items, the customer requests a receipt by pressing the receipt button on the customer panel. The system retrieves all information to be written on the receipt. For each type of item inserted, the system retrieves how many items of this type have been inserted by the customer, and the total value for the inserted quantity. 5. Print Receipt The system prints a receipt with the number of items the customer has inserted of each type, together with the total value of the deposited items. A new line is printed for each type of returned item. Finally, the total return-value is retrieved and is printed by the receipt printer. 6. End of Use Case The system prepares itself to receive the next customer by checking that there is sufficient room in deposit item bays and that the printer has enough paper.

16. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 16 Sample Alternative Flows of Events A1. Deposit Item Not Valid If in 2. Determine Type, the system has determined a deposit item is invalid, the system returns the deposit item to the customer. The deposit item will not appear on the receipt. A2. Printer Out of Paper If in 6. End of Use Case, the system has determined that not enough paper is in the printer, an alarm will be activated. Can you think of other alternatives?

17. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 17  Purpose:  Synchronize the project group’s ideas of the use case  Procedure:  Work together with the users  Sketch the outlines on large papers and display them  Expect to rewrite the outlines several times to get a stable set  Describe each step in 1-3 sentences  State clearly if steps can come in any order, or if they are repeated  Focus on the normal, regular, straight-forward way to do the use case Detailing the Basic Flow of Events

18. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 18 Exercise: Ways to Write a Flow of Events  Read the different flow of events descriptions on the following three (3) slides and answer the following questions:  Who is the intended audience?  Which is the easiest to understand (read)?  Which do you think is the easiest to write?  Is any one “better” than the others?  Which one do you prefer? Why?

19. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 19 Exercise: Flow of Events - Type I Orderers can create Orders to collect measurement data from the Network Elements. The system will assign the Order a unique name and default values for when and how long the measurement should be and also how often it is to be repeated. These values can of course be edited by the Orderer. The Orderer must further specify which measurement function, network element and measurements objects that are applicable. The Orderer can also add a personal comment to the order. When necessary information is defined a new Order is created and initialized with the defined attributes, the name of the creator, date of creation, and status of the order will be set to 'scheduled'. (Possible values for the status are: Scheduled, Executing, Completed, Canceled, and Erroneous). The user interface is then notified that a new Order has been created and receives a reference to the new Order so that it can be displayed.

20. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 20 1. Start of use case This use case starts when the actor Operator indicates to the system to create a measurement order. The system will then retrieve all Network Element actors, their measurement objects and corresponding measurement functions that are available to this particular Operator. Available Network Elements are those that are in operation and the Operator has the authority to access. What measurement function is available depends on what has been setup for a particular type of measurement object. 2. Configure Measurement Order The system allows the Operator to select which Network Elements to measure. The system then shows the measurement objects available for a selected Network Element. The Operator selects measurement objects, and measurement functions for each object. The system allows the Operator to enter a textual comment on the measurement order. The Operator indicates to the system to complete the measurement order. The system will respond by generating a unique name for the measurement order and setting up default values for when, how often, and for how long the measurement should be made. The default values are unique to each Operator. The Operator edits the default values. 3. Initialize Order The Operator indicates to the system to initialize the measurement order. The system will then record the identity of the creating Operator, date of creation and that the measurement order now has the status “Scheduled”. 4. The Use Case Ends The system confirms initialization of the measurement order to the Operator, and the measurement order is made available to other actors to view. Exercise: Flow of Events - Type II

21. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 21 Exercise: Flow of Events - Type III => 'Administrator order' (User identity) REPEAT <='Show administrator order menu' IF (=> 'Creating an Order' (Measurement function, network element, measurement object)) THEN The system finds a unique name, default values for when, how often and for how long the measurement should be executed. <= 'Show order' (Default attributes) REPEAT => 'Edit order' (Attribute to change, New value of attribute) <= 'Update screen' (New attributes) UNTIL (All attributes are defined) REPEAT IF (=> 'Edit order' (Attribute to change, New value of attribute)) THEN <= 'Update screen' (New attributes) ELSIF (=> 'Save order' (Order identity, Attributes)) THEN The order is created and initialized in the system with the defined attributes, the name of the creator, date of creation and the status 'scheduled'.) ENDIF UNTIL (=> 'Quit') ENDIF UNTIL 'Quit administrator order'

22. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 22 Exercise: Perspectives in Flow of Events  Now, read the different flow of events descriptions on the following two (2) slides and answer the following questions:  Who is the intended audience?  Which is the easiest to understand (read)?  Which do you think is the easiest to write?  Is one “better” than the other?  Which one do you prefer? Why?

23. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 23 Exercise: Outside Perspective Flow of Events 1. The use case starts when the subscriber lifts the phone, and gets a dial tone. 2. The dial tone disappears when the subscriber dials the first digit. 3. The subscriber dials the rest of the number and will then hear a ring tone if the called party is not busy. 4. The ring tone will disappear if the called party answers the phone call. 5. The call continues until both parties hang up their phones. 6. If the called party is busy the subscriber will hear a busy tone and will then hang up the phone. Local Call Subscriber

24. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 24 Exercise: Inside Perspective Flow of Events 1. The use case is initiated when the subscriber lifts the phone and the system finds the correct subscriber object, marks it busy and gives a dial tone to the subscriber. 2.The system turns off the dial tone when the subscriber dials the first digit. The system loads the digit into a register and will then wait to receive and store the rest of the digits. 3.When the system has received enough digits it will start to analyze the received digits. 4.When the whole number has been analyzed the system will find the corresponding subscriber object and check whether or not it is marked busy. 5.If the called party is not busy the system will busy mark the object and start... Local Call Subscriber

25. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 25 Who Reads the Flow of Events?  Customers: approve what system should do  Users: understand what system should do  Use-Case Specifier: document behavior  Reviewers: examine the flow of events  Designers: find design classes  System Tester: use as basis for test cases  Project Manager: manage the project  Technical Writer: write user’s guide

26. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 26 Flow of Events: Guidelines 1. Don’t describe what happens outside the system 2.Describe what data is exchanged between the actor and the use case 3.Do not describe the details of the user interface unless it is an important requirement 4.Describe the flow of events, not only the functionality. To enforce this, start every action with “When the [actor]... ” 5.Describe only the events that belong to the use case -- not what happens in other use cases or outside of the system 6.Avoid vague terminology such as “for example”, “etc. ” and “information” 7.Detail the flow—all “what’s” should be answered

27. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 27 Exercise: Detail the Basic Flow of Events  Describe each step in the basic flow of events for three (3) use cases in your project.  Start with the step-by-step outlines written for your use case model (in Unit 5)  Further describe with 1 or 2 sentences per step  Focus only on the normal “happy day” path through the use case. No alternative flows, yet!  Write neatly so that you can copy and distribute the text to the rest of the group.

28. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 28 Subflows: Structuring the Flow of Events  Why divide a flow of events into subflows?  Keep the main flow short and easy to read  Separate sequences that are only sometimes executed  Separate sequences that can be executed at several intervals in the same flow  Clarify traceability to other project elements

29. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 29 Use-Case Subflows as Separate Sections  Basic flow of events  What normally happens  Alternative flows of events  Use to specify Variants to the basic flow of events Optional flows of events Exceptions and errors  Occupies a large segment of the flow of events  Flow of events can be 5-15 pages long, depending on complexity of the use case

30. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 30 Flow of Events: Guidelines for Structure  Describe how the use case starts and ends  Start by defining the basic flow of events  Structure the basic flow of events into steps  Give each step a title  Describe all alternative subflows  Describe the order of the subflows  Only describe order of subflows as fixed, if it is  In other cases, point out that the order is unfixed

31. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 31 Structuring of Alternative Flows  Use one section for each alternative flow  What to define for an alternative flow  Where alternative flow starts  The condition for this alternative  The behavior in the alternative flow  Where basic flow is resumed

32. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 32 Specific Alternative Flows  Specific alternatives  Occur at a specific step in another flow.  Example: A1: Bottle stuck The customer inserts a bottle that falls over, is too big, or jams with another bottle. The sensors around the gate and the measuring gate detect this problem. The conveyer belt is stopped and an alarm is issued to call for the operator. The operator fixes the problem and the machine continues.

33. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 33 Specific Alternative Flows  The same flow may also be written with more specific references.  Example: A1: Bottle stuck In step 1. Start of Use Case in the basic flow, if a bottle gets stuck in the gate the sensors around the gate and the measuring gate will detect this problem. The conveyer belt is stopped and an alarm is issued to call for the operator. The operator fixes the problem and the machine continues in step 2. Determine Type in the basic flow.  Make a clear reference to  Where you pick up the sequence of actions  Where you hand it over to another flow

34. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 34 General Alternative Flows  An alternative flow may pick up the sequence of actions anywhere:  Example: A2: Front panel is removed If, at any point, somebody (probably the operator) removes the front panel of the machine, then the can compression is deactivated. It will not be possible to start the can compression with the front panel off. The removal will also activate an alarm to the operator. When the front panel is closed again, the machine will resume the operation.

35. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 35 Example: Flow of Events Basic Flow of Events 1. Start of use case This use case starts when... What measurement function is available depends on what has been setup for a particular type of measurement object. 2. Configure Measurement Order The system allows the Operator to select …The system then allows the Operator to edit the default values. 3. Initialize Order The Operator indicates to the system that … the measurement order now has the status “Scheduled”. 4. The use case ends The system confirms initialization of the measurement order to the Operator, and the measurement order is made available to other actors to view. Alternative Flows of Events A1. No Network Elements Available If in “Start of use case”, it turns out that now Network Elements are available to measure for this Operator, the system will inform the Operator. The use case then ends. A2. No Measurement Functions Available If in “Configure Measurement Order” no measurement functions are available for the selected Network Elements, the system will inform the Operator about this and allow the Operator to select other Network elements. A3. Cancel Measurement Order The system will allow the Operator to cancel all actions at any point during the use case. The system will then return to the state it had before the use case was started, then end the use case.

36. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 36 Exercise: Detail the Alternative Flows  Further detail at least three (3) alternative flows for each use case in the previous exercise  Continue the description of the flow of events of the use cases in your class project  Use the alternatives identified in the step-by-step outlines written for your use cases (in Module 5)  Describe clearly what will happen in each alternative  Write neatly so that you can copy and distribute the text to the rest of the group

37. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 37  Using pre- and post-conditions  Pre- and post-conditions are observable to the user  Use only if needed for clarification  A pre-condition  Constraint on when use case can start  NOT the event that starts the use case  A post-condition  Guaranteed true when use case ends  Should apply regardless of alternative flows  May contain different variants Use of Pre- and Post-Conditions

38. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 38 Example of a Pre-Condition Withdraw Cash Pre-condition  The customer has a personally-issued card that fits in the card reader, has been issued a PIN number, and is registered with the banking system. Use only if needed for clarification!

39. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 39 Example of Post-Condition Withdraw Cash Post-condition  At the end of the use case, all account and transaction logs are balanced, communication with the banking system is reinitialized, and the customer has been returned his card or informed of where it will be sent. Use only if needed for clarification!

40. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 40 Describing a Use Case: Things to Remember  Use a simple language  Use your glossary  State what system does and what user does  Number and name sections to simplify reviewing Remember the description is for people to read, not for computers

41. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 41 What about Non-Functional Requirements?  The “URPS” of FURPS  Usability  Reliability  Performance  Supportability  Compliance with Legal and Regulatory requirements  FCC  FDA  DOD  ISO  Design Constraints  Operating systems  Environments  Compatibility  Application standards What are some others? Where should they be specified?

42. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 42 Specifying Non-Functional Requirements  Some non-functional requirements apply to an individual use case and may be captured within the properties of a use case 1. Within the “Flow of Events” section of a use case Basic Flow Alternate Flows 2. In the “Special Requirements” section of a use case  Some non-functional requirements apply to the whole system 3.These should be specified in the “Supplementary Specifications” TP: Supplementary Specifications Template

43. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 43 The “URPS” of FURPS Grady, 1992 Which of these might be captured in the use-case model? With which ones might this not be possible or practical? What should you do with them? Functionality Feature Set Capabilities Generality Security Usability Human Factors Aesthetics Consistency Documentation Reliability Frequency/Severity of Failure Recoverability Predictability Accuracy MTBF Performance Speed Efficiency Resource Usage Throughput Response Time Supportability Testability Extensibility Adaptability Maintainability Compatibility Configurability Serviceability Installability Localizability Robustness

44. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 44 Examples: Non-Functional Requirements  The Recycling Machine  The machine can only handle one customer at a time.  The machine has to be able to recognize deposit items with a reliability of more than 95%. What are some others? Where should each of these be specified?

45. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 45 Specifying Usability Requirements  Usability: The ease with which the software can be learned and operated by the intended users  How to specify:  Training time requirements, measurable task times  Matches user abilities (unsophisticated/sophisticated)  Comparison to other systems that users know and like  On-line help systems, tool tips, documentation needs  Conformity with standards Examples: Windows, style guides, GUI Standards

46. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 46 Davis Workshop, 1993 Specifying Reliability Requirements  Reliability: The ability for the software to behave consistently in a user-acceptable manner  Measures  Availability (xx.xx%)  Accuracy  Mean time between failures (xx hrs)  Max. bugs per/KLOC (0-x)  Bugs by class - critical, significant, minor  Predictors  Lines of code  Complexity metrics

47. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 47 Davis Workshop, 1993 Specifying Performance Requirements  Performance: A measure of speed and efficiency of the running system  Measures  Capacity  Throughput  Response time  Memory  Degradation modes  Also consider the degree to which implementation makes wise use of scarce resources (processor, memory, disk, network bandwidth, etc.)

48. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 48 Davis Workshop, 1993 Specifying Supportability Requirements  Supportability: The ability of the software to be easily modified to accommodate enhancements and repairs  How to specify requirements  Languages, DBMS, tools, etc.  Programming standards  Error handling and reporting standards  If not observable, state as intent or goals  If not measurable or observable, it is not a requirement

49. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 49 What About Design Constraints?  A requirement should allow more than one design option  A design is a choice among options  A requirement that leaves no options is a design constraint  Distinguish it from other requirements  Place in a special section of your software requirements  Identify the source of each  Document the rationale for each

50. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 50 What How What How What How Stakeholder Needs Product or System Features Software Requirements Specification (Use Cases) Design Spec Test Procedures Documentation Plans “One man’s ceiling is another man’s floor” Davis, 1993 The What vs. How Dilemma Question: How can you tell a requirement from design? Answer: It depends on your point of view.

51. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 51 Exercise: Non-Functional Requirements  For your class project, list at least two non- functional requirements that would be documented in each of the following locations: 1. In the Flow of Events of a use case Basic flow Alternate flows 2. In the Special Requirements of a use case 3. In the Supplementary Specifications

52. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 52 What About a “Traditional” SRS Approach? Features Software Requirements Vision Document Needs  Use-Case Model Supplementary Specifications Traditional SRS Use-Case Model

53. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 53 Software Requirements Specifications 1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms, and Abbreviations 1.4 References 1.5 Overview 2. Overall Description 2.1 Product Perspective 2.2 Product Functions 2.3 User Characteristics 2.4 Constraints 2.5 Assumptions and Dependencies 3. Specific Requirements Appendices Index Software Requirements Specifications 1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms, and Abbreviations 1.4 References 1.5 Overview 2. Overall Description 2.1 Product Perspective 2.2 Product Functions 2.3 User Characteristics 2.4 Constraints 2.5 Assumptions and Dependencies 3. Specific Requirements Appendices Index A “Traditional” SRS Template: Based on IEEE 830 TP: SRS Template

54. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 54 IEEE 830 SRS: Chapter 3 - Specific Requirements  Feature  System mode  Type of user  Objects  Stimulus / Response  Functional hierarchy The answer is application dependent. You may wish to organize by Or even a combination of the above adapted from IEEE 1993 How do I organize specific requirements????

55. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 55 IEEE 830 SRS Example: Organization by Feature IEEE 1993 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 System Features 3.2.1 Feature 1 3.2.1.1 Purpose 3.2.1.2 Stimulus/Response Sequence 3.2.1.3 Associated Functional Requirements 3.2.n Feature n 3.3 Performance Requirements 3.4 Design Constraints 3.5 Software System Attributes 3.6 Other Requirements 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 System Features 3.2.1 Feature 1 3.2.1.1 Purpose 3.2.1.2 Stimulus/Response Sequence 3.2.1.3 Associated Functional Requirements 3.2.n Feature n 3.3 Performance Requirements 3.4 Design Constraints 3.5 Software System Attributes 3.6 Other Requirements Could include references to use cases here, if needed.

56. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 56 Sample Software Requirements: Recycling Machine FEAT 1 The Recycling Machine will provide facilities to recycle bottles, cans, and crates. SR 1 The Recycling Machine (system) shall accept 1 or more deposit items (cans, bottles, or crates) inserted during one deposit session. SR 1.1 A deposit session shall begin when the first deposit item is inserted and shall end when the receipt is printed. SR 1.2 The system shall read a bar code on the deposit item. The system shall validate the deposit item by comparing its code with a list of valid codes. SR 1.2.1 If a deposit item is not valid, the system shall reject and return it. SR 1.2.2 If a deposit item is valid, the system shall update the session total and the daily total for that deposit item type, and prepare itself to receive the next item.

57. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 57 Sample Software Requirements (cont.) SR 2 Upon receiving a press of the “print receipt” button on the control panel, the system shall print a receipt. SR 2.1 The receipt shall have one line for each type of deposit item: the number of items of that type which were returned and the total value of those items. SR 2.2 The bottom line of the receipt shall show the total return- value of all items deposited in one deposit session. SR 3 The system shall end a deposit session by preparing to receive the next customer. SR 3.1 The system shall check that there is sufficient room in deposit item bays and that the printer has enough paper. SR 3.2 If room or paper is insufficient, the system shall shut down and shall issue an alarm on the operator communication channel.

58. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 58 Software Requirements Specifications 1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms, and Abbreviations 1.4 References 1.5 Overview 2. Overall Description 2.1 Use-Case Model Survey 2.2 Assumptions and Dependencies 3. Specific Requirements 3.1 Use Case Reports 3.2 Supplementary Specifications Appendices Index Software Requirements Specifications 1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms, and Abbreviations 1.4 References 1.5 Overview 2. Overall Description 2.1 Use-Case Model Survey 2.2 Assumptions and Dependencies 3. Specific Requirements 3.1 Use Case Reports 3.2 Supplementary Specifications Appendices Index A “UC” SRS Template: Customized for Use Cases TP: (UC) SRS Template

59. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 59 Can We Combine The Two Approaches? Features Software Requirements Needs Vision Document Traditional SRS WP2: Traceability Strategies Use-Case Model

60. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 60 Combining Use-Case Model and Traditional SRS SRS II Illustrative Use Cases SRS Traditional SRS (all requirements) IIa (examples of usage, plus architecturally significant use cases - for design verification) Traditional SRS (all requirements) + SS Supplementary Specifications + I Use-Case Model SRS Traditional SRS Ia + Use-Case Model Need Traditional SRS Want Use Cases

61. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 61 ref - IEEE 1993 Qualities of a Software Requirement Specification  Correct  Complete  Consistent  Unambiguous  Ranked for importance and stability  Verifiable  Modifiable  Traceable  Understandable

62. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 62 Qualities of an SRS: Correct  A Requirements Specification is “correct” if:  Every requirement within it is something required of the system to be built  For example, every requirement in the SRS contributes to the satisfaction of some need Hint: Involve people who have the problem or mission. ref - Davis ‘93

63. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 63 IEEE 1993 Qualities of an SRS: Complete  A Requirement Specification is “complete” if it contains:  All significant requirements  Responses of the software to all inputs  Full labels and references to all figures, tables, and diagrams  Definitions of all terms and units of measure (Glossary / Data Dictionary)

64. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 64  A Requirements Specification is “consistent” if:  No subset of individual requirements described in it is in conflict. Hint: Trace all related requirements IEEE 1993 SR101: Pressing the on-button shall illuminate the power LED. SR841: On system start-up, no observable results shall occur. Qualities of an SRS: Consistent SR245: The power LED shall be illuminated when the system is powered up. (Inconsistent) (Consistent)

65. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 65 ref - IEEE 1993 “A shall do B to C” Req. 1 Qualities of an SRS: Unambiguous  A Requirements Specification is “unambiguous” if:  Every requirement within it has only one interpretation.

66. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 66 Exercise: Exploring Ambiguity Mary had a little lamb. In the space below, write (or draw) your detailed understanding of what this sentence means. ref - Gause & Weinberg, 1989

67. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 67 Exploring Ambiguity: Dictionary Definitions had -past of have have -1a: to hold in possession as property 4a: to acquire or get possession of: OBTAIN (best to be had) c: ACCEPT; to have in marriage 5a: to be marked or characterized by (have red hair) 10a: to hold in a position of disadvantage or certain defeat b: TRICK, FOOL (been had by a partner) 12: BEGET, BEAR (have a baby) 13: to partake of (have dinner) 14: BRIBE, SUBORN (can be had for a price) lamb - 1a: a young sheep esp. less than one year old or without permanent teeth b: the young of various other animals (as smaller antelopes) 2a: a person as gentle or weak as a lamb b: DEAR, PET c: a person easily cheated or deceived especially in trading securities 3a: the flesh of lamb used as food

68. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 68 Exploring Ambiguity: Analysis havelambInterpretation 1a1aMary owned a little sheep under one year of age or without permanent teeth. 4a1aMary acquired a little sheep under one year of age or without permanent teeth. 5a1aMary is the person who owned a little sheep under one year of age or without permanent teeth. 10a1aMary held a little sheep under one year of age or without permanent teeth in a position of disadvantage. 10b1aMary tricked a little sheep under one year of age or without permanent teeth. 121bMary gave birth to a young antelope. 122aMary is (or was) the mother of a particular small, gentle person. 133aMary ate a little of the flesh of lamb. 142cMary bribed a small person trading in securities who was easily cheated.

69. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 69 Gause & Weinberg, 1989 What to Do About Language Ambiguity  The Ambiguity Poll - create a measure that requires a solid understanding of the problem to estimate.  Memorization Heuristic - get various individuals to try to recall the problem statement from memory. Parts that are not clear are likely the most ambiguous.  Key Word Technique - determine the key operational words in the statement and list their definitions. Mix and match to determine different interpretations. (Use these terms for glossary.)  Emphasis Technique - emphasize different words until as many interpretations as possible are discovered.  Other Techniques - use other techniques, pictures, graphics, formal methods -- that’s what use cases are for!

70. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 70 Exploring Ambiguity: An Observation Techniques that reduce ambiguity in an SRS often decrease understandability and alienate customers and users. Our goal is to find the “sweet spot” where we attain the greatest understandability with the least ambiguity Understandability Ambiguity The sweet spot

71. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 71  Use natural language to describe the majority of the specification. Write as clearly and concisely as possible.  Use pictures, diagrams, dialogs, etc. to further illustrate the intent and features of the application  Augment with use cases and other formal techniques to fully define the functionality of the system. Ambiguity vs. Understandability: What to Do?

72. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 72 ref - IEEE 1993 Ranked by importance SR103 SR172 SR192 SR71 SR63 SR172 SR103 SR63 SR71 SR192 Ranked by stability Qualities of an SRS: Ability for Ranking  A Requirements Specification is able to be “ranked” for importance and stability if  Each requirement in it has an identifier to indicate the importance and stability of that particular requirement

73. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 73 IEEE 1993 - The system supports up to 1,000 simultaneous users - The system shall respond to an arbitrary query in 500 msec. - The color shall be a pleasing shade of green - The system shall be user friendly - The system shall export view data in comma separated format Qualities of an SRS: Verifiable  A Requirements Specification is “verifiable” if:  Every requirement in it is verifiable. [… to a degree that convinces everybody!]  There exists some finite, cost-effective process with which a person or machine can check that the product meets the requirement. Are these requirements verifiable? If not, what is a better way to state them? (Involve QA folks to help decide.)

74. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 74 IEEE 1993 Qualities of an SRS: Modifiable  A Requirements Specification is “modifiable” if:  Its structure and style are such that any changes to requirements can be made easily, completely, and consistently, while retaining the structure and style.  Features to facilitate this: Well organized Table of contents Index Cross references Minimum redundancy

75. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 75 ref - IEEE 1993 Qualities of an SRS: Traceable  A Requirements Specification is “traceable” if:  The origin of each of its requirements is clear and it facilitates the referencing of each requirement in future development Backward traceability (to previous stages of definition or development) Forward traceability (to all documents spawned by the SRS)  Hint: Make sure every requirement is referenceable Use unique numbers Use labels Use “shall" or other unique identifiers Use a requirements repository to maintain traceability

76. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 76 Qualities of an SRS: Understandable  A Requirements Specification is “understandable” if:  Both the user and supplier communities are able to fully comprehend the requirements stated in it  Hints:  Early document should focus on general description and features of the system  Requirements writers must understand both audiences  Use cases can help with understanding the system’s functional requirements and boundaries

77. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 77 How to Describe User Interfaces  Enclose sketches of proposed screen appearance with the use-case descriptions  Be careful not to specify too much of the design in the use-case documents

78. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 78 Shurtleff ‘94 Storyboarding  Movies, cartoons, and animated features all begin with storyboards that tell  Who the players are (actors)  What happens to them  How it happens

79. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 79 Shurtleff ‘94 Storyboarding: Benefits  Help gather and refine customer requirements in a user friendly way  Encourage more creative and innovative design solutions  Encourage team review and prevent features no one wants  Ensure that features are implemented in an accessible and intuitive way  Ease the interviewing process  Avoid the blank-page syndrome

80. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 80  An early demonstration of some or all of the externally observable behaviors of a system  Used to  Gain feedback on proposed solution  Demo the problem domain  Validate known requirements  Discover unknown requirements  Prototyping tools  Demo programs  Simulations Prototyping

81. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 81 Davis ‘95 Prototyping: Types  Throwaway  Serves solely to demonstrate that the technological or user interface risks of the proposed solution are feasible  Throw away - everything except knowledge gained  Evolutionary  Demonstrates viability of technology approach employed and user interface  Throw away - as much as necessary, saving knowledge gained and core technologies applied  Operational prototype  Final form, function, and fit, as well as technology  Throw away - as little as possible

82. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 82 Prototyping: Selecting Type to Use  For what purpose?  To elicit and understand requirements?  To prove and understand technology?  Both of the above?  Benefits of prototyping  Reduce risk  Enhance shared understanding  Improve cost and schedule estimates  Improve feature definition Often, important features are found to be of little value - and vice versa

83. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 83 How to Describe Communication Protocols  Specify a communication protocol if the actor is another system or external hardware  The description of the use case should state if some existing protocol is to be used  If the protocol is new, it will be fully described during object-model development

84. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 84 Adapted from Alan Davis What Is Not in an SRS?  Design - How to accomplish the requirements  Use the Design Model to specify sub-components of a system and/or their interfaces with other sub- components  Verification - How you’ll know the requirements have been met  Use the Test Model to specify test cases and test procedures  Project Data - When the requirements will be met  Use the Software Development Plan to specify schedules, verification and validation plans, and configuration management plans

85. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 85 RUP Workflow Detail: Refine the System Definition

86. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 86 RUP Workflow Detail: Refining the System Definition

87. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 87 Review: Refining the System Definition 1. What is in a software requirement specification?  What are its roles? 2.What properties of a use case are documented in the Use- Case Report? 3. What is the purpose of the flow of events in a use case?  Who is it written for?  What does the basic flow describe?  What different types of alternative flows may be identified? 4.What are pre- and post-conditions?  When should they be used? 5.What is the purpose of the “Special Requirements” of a use case? (Continued  )

88. Rational Requirements Management with Use Cases v5.5 Copyright © 1998-2000 Rational Software, all rights reserved 88 Review: Refining the System Definition 6. What are the types of non-functional requirements that should be tracked in your projects?  Which of these can be captured in use cases? Where should they each be specified? 7.Is your industry bound by legal or regulatory requirements?  If so, what types of specifications should be written to assure compliance? 8.What is a design constraint? Where is it documented? 9. List some quality measures of a requirement specification. 10. What is not included in an SRS?