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
6.
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
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
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.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
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
44.
45.
46.
47.
48.
49.
50.
51.
52. What About a “Traditional” SRS Approach? Features Software Requirements Needs Use-Case Model Supplementary Specifications Vision Document Traditional SRS Use-Case Model
53.
54.
55.
56.
57.
58.
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
![Course Outline ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)