1. Supplementary Specifications (Chapters 20,22 - Requirements Text) 1

2. Outline Refining the System Definition ◦ A More Rigorous Look at Requirements ◦ Supplementary Specifications 2

3. System Behavior Inputs Outputs Functions System Attributes Environmental Attributes 3

4. What Not to Put in Requirements Project Planning Information ◦ May be part of the contract, though Design Information “what vs. how” Is this a requirement? “This report will be prepared using visual basic crystal reports software” 4

5. Requirements versus Design Requirements comes before design Users make requirement decisions while developers make design decisions Does this model always work? 5

6. Requirements Three types ◦ Functional ◦ Non-functional (Quality attributes) ◦ Design The two important components that we will use are ◦ Use Case Model ◦ Supplementary Specifications 6

7. Discussion Can all functional requirements be captured using use cases? 7

8. Typical Nonfunctional Requirements These are the ones Leffingwell & Widrig detail: Usability ◦ Ease of use ◦ Bill of rights Reliability ◦ System availability Performance ◦ Response time Supportability 8

9. We’ll add a couple more of these… From Bass, et al’s architecture book, which we use in CSSE 374 and 377: Usability Availability ◦ Similar to Reliability Performance Modifiability ◦ Similar to Supportability Security ◦ New! Testability ◦ New!

10. Design Constraints Restriction of design options (e.g. what database to use) Process (e.g. must use ISO or IEEE software engineering standards) Regulations (e.g. FDA) Why are these in the requirements, if they involve design?. 10

11. “Other” Requirements Deliverables Technical Support Training Requirements 11

12. Supplementary Specifications Document Includes ◦ Nonfunctional Requirements, ◦ Design Constraints, and ◦ Other Requirements That are not confined to just one use case Leffingwell & Widrig’s template is available on Page 268/Appendix D We added some specific detail to the Quality Attributes specs, in your version out on Week 4, Day 1 12

13. How do you ”detail” a quality attribute? Do “Scenarios” in which they typically would apply Similar to, but not the same as Use Cases for functionality These Scenarios make it easier to see what to shoot for in meeting these requirements, like: ◦ How to design and implement for them ◦ How to test them in acceptance tests

14. What do the Quality Attribute Scenarios look like? Source of stimulus: Stimulus: Environment: Artifact: Response: Response measure:

15. Quality Attribute Example – Usability: Source: Users Stimulus: Minimize impact of errors Artifact: System Environment: At runtime Response: Wishes to cancel current operations Response Measure: Cancellation takes less than one second