The document discusses refining a system definition through use case modeling. It explains how to detail use cases by structuring the basic and alternative flows of events. Guidelines are provided for writing use case reports and flows of events to clearly communicate system behavior to various audiences like users, designers, and testers.

1. Requirements Management with Use Cases Module 7 Refining the System Definition

3. Refining the System Definition: Overview Problem Solution Space Problem Space Needs Features Software Requirements The Product To Be Built Test Procedures Design User Docs Traceability

4. What Do Software Requirements Specify? System Inputs Outputs Functions Performance Environments Software requirements specify externally observable capabilities and conditions of the system

5. Specifying the Software Requirements Features Software Requirements Needs OR ? ? The Software Requirements Specification (SRS) defines the complete external behavior and characteristics of the system to be built. Supplementary Specifications Vision Document Traditional SRS Use-Case Model

7. Features Drive Software Requirements 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 Feat 63 - the defect tracking system will provide trending information to help the project manager assess project status Operator Project Manager

8. Focus on the Use-Case Model Approach Features Software Requirements Needs Supplementary Specifications Vision Document Traditional SRS Use-Case Model 

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.

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? F unctionality Feature Set Capabilities Generality Security U sability Human Factors Aesthetics Consistency Documentation R eliability Frequency/Severity of Failure Recoverability Predictability Accuracy MTBF P erformance Speed Efficiency Resource Usage Throughput Response Time S upportability Testability Extensibility Adaptability Maintainability Compatibility Configurability Serviceability Installability Localizability Robustness

52. What About a “Traditional” SRS Approach? Features Software Requirements Needs  Use-Case Model Supplementary Specifications Vision Document Traditional SRS Use-Case Model

59. Can We Combine The Two Approaches? Features Software Requirements Needs WP2: Traceability Strategies Vision Document Traditional SRS Handout Use-Case Model

60. Combining Use-Case Model and Traditional SRS SRS II 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 SRS Traditional SRS Ia + Need Traditional SRS Want Use Cases Illustrative Use Cases Use-Case Model Use-Case Model

85. RUP Workflow Detail: Refine the System Definition

86. RUP Workflow Detail: Refining the System Definition