80 likes | 99 Views
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
E N D
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 • 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