REQUIREMENT HANDLING 2013 05 02 Requirement Analysis Phases

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, 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 (p 44) • 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 • Essential complexity vs. accidental complexity • Use the same language • UML, Sys. ML, drawings • Create requirement diagrams with connections • Understanding context • Linking requirements to testing • The Devil is in the Interfaces • Tracking and communicating changes • Communication, communication • Reusable components