Requirement Handling 2013.05.02

Requirement Analysis Phases Inception (initiation) Elicitation (gathering) Problems of scope Problems of understanding Problems of volatility Elaboration Developing a refined requirement model User scenarios Negotiation Agree on what you elaborated Specification SRS, RS, Requirement Specification Validation Requirements are stated unambiguously, consistent and error free as much as possible Technical review Requirements management Requirements are changing, follow them up

SRS Template Table of Contents Revision History 1. Introduction 1.1 Purpose 1.2 Document Conventions 1.3 Intended Audience and Reading Suggestions 1.4 Project Scope 1.5 References 2. Overall Description 2.1 Product Perspective 2.2 Product Features 2.3 User Classes and Characteristics 2.4 Operating Environment 2.5 Design and Implementation Constraints 2.6 User Documentation 2.7 Assumptions and Dependencies 3. System Features 3.1 System Feature 1 3.2 System Feature 2 (and so on) 4. External Interface Requirements 4.1 User Interfaces 4.2 Hardware Interfaces 4.3 Software Interfaces 4.4 Communications Interfaces 5. Other Nonfunctional Requirements 5.1 Performance Requirements 5.2 Safety Requirements 5.3 Security Requirements 5.4 Software Quality Attributes 6. Other Requirements Appendix A: Glossary Appendix B: Analysis Models Appendix C: Issues List

Theoretical Ideas #1 Identifying Stakeholders Recognizing multiple viewpoints Working toward collaboration Asking the questions Collaborative requirements gathering Facilitated Application Specification Technique (FAST) Grouping requirements Normal requirements (the “explicit” ones) Expected requirements (the “implicit” ones) Exciting requirements (beyond customer expectations) Usage scenarios, use cases

Theoretical Ideas #2 Building the Requirements Model (UML or simpler way) Scenario-based elements Class-based elements Behavioral elements Flow-oriented elements Analyze patterns

Practical Ideas #1 Don’t put your resume ahead of the requirements Business value Simplify essential complexity; Diminish accidental complexity Everything will ultimately fail Every safety mechanism we employ to mitigate one kind of failure adds new failure modes. Quantify “Fast” is not a requirement. Neither is “responsive.” Nor “extensible.” It’s never too early to think about performance Non-functional requirements Simplicity before generality, use before reuse Architectural tradeoffs (p44) You can’t have it all. It is virtually impossible to design an architecture that has high performance, high availability, a high level of security, and a high degree of abstraction all at the same time.

Practical Ideas #2 Use uncertainty as a driver Try before choosing Fight repetition Copy-paste means further possibility for abstraction Remember the kiss principle Software architecture has ethical consequences Multipliers, sign on a building analogy Skyscrapers aren’t scalable Warning: problems in mirror may be larger than they appear Multiply time and effort Security is not a feature Secure communication shall be considered from the beginning Seek the value in requested requirements (F-16) Customer does not know solution, but problems

Practical Ideas #3 Managing Complexity Use the same language Essential complexity vs. accidental complexity Use the same language UML, SysML, drawings Create requirement diagrams with connections Understanding context Linking requirements to testing The Devil is in the Interfaces Tracking and communicating changes Communication, communication, communication Reusable components