1 / 8

Requirement Handling

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

donnajames
Download Presentation

Requirement Handling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Requirement Handling 2013.05.02

  2. 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

  3. 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

  4. 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

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

  6. 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.

  7. 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

  8. 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

More Related