Requirements Engineering Flashcards
What is Requirements Engineering?
- Identify Stakeholders
- Understand Customer/User’s needs
- Requirements gathering and identification
- Clarify, Analyze, Define, Specify, Prioritize, Track, Validate Requirements
What happens without Requirements Engineering
- Many varied consequences
- System may fail or be useless
- Difference between quality and luxury
V Model
Stakeholder Requirements -> Acceptance Test.
System Requirements -> System Test.
Subsystem Requirements -> Integration Test
Component Requirements -> Unit Test
Coverage Analysis
Highest layer checks if lower layer requirements are satisfied
Traceability Analysis
- Impact Analysis: Change Management
- Derivation Analysis: Cost-Benefit Analysis
- Coverage Analysis: General Engineering Management Reporting
Requirements & Modelling
Mutually supportive. Requirements Modelling doesn’t exist. Model system not requirements.
Models of Requirements Engineering
Abstraction that focuses on some aspect of the system. Avoidance of irrelevant details.
Types of Requirements
Hardware Requirements:
- Performance Reqs
- Interface Reqs
- Speciality Engineering Reqs
- Environmental Reqs
Software Requirements:
- Functional Reqs
- Nonfunctional Reqs
Business Requirements
Essential, derived from business goals. Understand requirements.
Stated Requirements vs Real Requirements
Stated Reqs proved by customer at start and Real Reqs are the verified needs for a system. RA differentiate between them
High Level Requirements
Capture vision of customer, define scope, allow estimation of cost
Functional Requirements
Describe what solution must do. Operational requirements. Specify input and outputs and relationship between them.
Non Functional Requirements
System properties ex. safety or reliability
Derived Requirements
Refined from high level reqs. Distinguish between externally identified requirements and requirements derived under control of engineer.
Design Requirements and Considerations
When upgrading the system, old system usually has constraints and will be present in new system.
Performance Requirements
Defines how well functional requirements perform. Correspond to system level needs for availability, security and performance.
Interface Requirements
Difficult to define. Physical and functional relationships amongst elements between environment.
Verified Requirements
Real requirements that are met or satisfied in design solution. Checked before final system. Formal methods can be used.
Validated Requirements
Requirements implemented into system. Validated and proven
Qualified Requirements
Refers to validation or verification of item performance in applications and results from design and test data reviews and audits.
Unknowable Requirements
Experience shows that some requirements are unknowable from the start. Only become apparent as system evolves.
Developing Systems
Establish need for system. If purpose is unknown system will be unclear. Nature of explanation determines how rigorous the need is expressed.
Levels of Requirements Engineering
Problem Domain: Statement of needs
Solution Domain: Stakeholder Requirements, System Reqs, System Component Reqs, Subsystem Component Reqs.
Customer Acceptance
Agree input requirements with customer after defining risks. Generate requirements derived from input. Agree derived requirements with implementation team. Establish qualification strategy.
System Modelling for Requirements Engineering
Supports analysis and design process by introducing formality. Use Pictures. Formalize representations with standard syntax and provide medium for understanding ideas.
Benefits of Modelling
- Encourages use of precisely defined vocabulary.
- Allows system specifications and designs to be visualized in diagrams.
- Allows considerations of multiple interacting aspects and views
- Supports analysis of systems through a defined discipline
- Allows validation of some aspects of the system design
- Progressive refinement to detailed design
- Encourages communication between orgs
CORE
Designed to attempt defining problem itself. The central concept is the viewpoint and associated representation known as viewpoint heirarchy.
SADT
Method of structured analysis. Graphical, heirarchical approach to problem. Set of blueprints refining problem until solution achieved.
Basic elements of SADT
box, represents an activity or data. Joined by arrows representing data needed or provided by activity.
