160 likes | 191 Views
Discover the essentials of requirements engineering, from problem analysis to implementation and testing, ensuring clear, traceable, and complete software requirements specifications. Learn about elicitation techniques, change control, and quality attributes.
E N D
REQUIREMENTS ENGINEERINGandSYSTEMS ANALYSIS Elements and Definitions
Software Requirements Specification - SRS Requirements System Design Detailed Design Implementation Installation & Testing Maintenance
Who does requirements engineering? customer requirements engineer system designer
What are the activities? customer needs problem analysis “complete” understanding of requirements product description consistent SRS
Problem Analysis: understand the problem (space) expand information specify constraints: find them analyze them resolve conflicts specify the solution space Product Description: describe the problem compress information set limits: constraints assumptions check completeness consistency
Levels of Software Requirements Business Requirements Customer Satisfaction Business Needs Vision & Scope Document Quality Attributes User Expectations User Requirements User Satisfaction Tester Support Business Rules Use Case Document System Requirements Functional Requirements Other Extra-functional Requirements Developers Support Constraints- e.g., standards, architecture Software Requirements Specification
Elicitation Change Control Analysis Version Control Modeling & Specification Tracing Verification & Validation Status Tracking Components of Requirements Engineering Requirements Engineering Requirements Development Requirements Management
Typical Methods & Techniques • interviews • hands-on experience • documentation analysis • scenarios • (formal) description • completeness and consistency checking • conflict resolution techniques
The Product: SRS • Standards: • IEEE / ANSI 830-1984 • DoD 2167A / DI-MCCR-80025A (SRS) • NASA SFW-DID-08 (SRS) • company internal standards?
Elements of an SRS • user goals • context description • behavioral/functional requirements • non-behavioral/extra-functional requirements • constraints • assumptions ===> WHAT
NOT included in an SRS: • project management • design information • quality assurance plans • staffing • cost analysis ===> HOW
An SRS should be: • understandable • modifiable • traceable • annotated • correct • non-ambiguous • complete • verifiable • consistent ===> formal vs. informal requirements specification
IEEE Std 830-1984 1. Introduction 1.1 Purpose of SRS 1.2 Scope of product 1.3 Definitions, acronyms, abbreviations 1.4 Overview
IEEE Std 830-1984 2. General description 2.1 Product perspective 2.2 Product functions 2.3 User characteristics 2.4 General constraints 2.5 Assumptions and dependencies
IEEE Std 830-1984 3. Specific requirements 3.1 Functional requirements 3.2 External interface requirements 3.3 Performance requirements 3.4 Design constraints 3.5 Attributes 3.6 Other requirements Alternatives!
End of Section 2a coming up: Data Flow Diagrams