Category:SE Requirements Engineering
Contents |
SE/Requirements Engineering [1 Core-Tier1 hour; 3 Core-Tier2 hours]
The purpose of requirements engineering is to develop a common understanding of the needs, priorities, and constraints relevant to a software system. Many software failures arise from an incomplete understanding of requirements for the software to be developed or inadequate management of those requirements.
Specifications of requirements range in formality from completely informal (e.g., spoken) to rigorously mathematical (e.g., written in a formal specification language such as Z or first-order logic). In practice, successful software engineering efforts use requirements specifications to reduce ambiguity and improve the consistency and completeness of the development team’s understanding of the vision of the intended software. Plan-driven approaches tend to produce formal documents with numbered requirements. Agile approaches tend to favor less formal specifications that include user stories, use cases, and test cases.
Topics:
[Core-Tier1]
- Describing functional requirements using, for example, use cases or users stories
- Properties of requirements including consistency, validity, completeness, and feasibility
[Core-Tier2]
- Software requirements elicitation
- Describing system data using, for example, class diagrams or entity-relationship diagrams
- Non-functional requirements and their relationship to software quality (cross-reference IAS/Secure Software Engineering)
- Evaluation and use of requirements specifications
[Elective]
- Requirements analysis modeling techniques
- Acceptability of certainty / uncertainty considerations regarding software / system behavior
- Prototyping
- Basic concepts of formal requirements specification
- Requirements specification
- Requirements validation
- Requirements tracing
Learning Outcomes:
[Core-Tier1]
1. List the key components of a use case or similar description of some behavior that is required for a system. [Familiarity]
2. Describe how the requirements engineering process supports the elicitation and validation of behavioral requirements. [Familiarity]
3. Interpret a given requirements model for a simple software system. [Familiarity]
[Core-Tier2]
4. Describe the fundamental challenges of and common techniques used for requirements elicitation. [Familiarity]
5. List the key components of a data model (e.g., class diagrams or ER diagrams). [Familiarity]
6. Identify both functional and non-functional requirements in a given requirements specification for a software system. [Usage]
7. Conduct a review of a set of software requirements to determine the quality of the requirements with respect to the characteristics of good requirements. [Usage]
[Elective]
8. Apply key elements and common methods for elicitation and analysis to produce a set of software requirements for a medium-sized software system. [Usage]
9. Compare the plan-driven and agile approaches to requirements specification and validation and describe the benefits and risks associated with each. [Familiarity]
10. Use a common, non-formal method to model and specify the requirements for a medium-size software system. [Usage]
11. Translate into natural language a software requirements specification (e.g., a software component contract) written in a formal specification language. [Usage]
12. Create a prototype of a software system to mitigate risk in requirements. [Usage]
13. Differentiate between forward and backward tracing and explain their roles in the requirements validation process. [Familiarity]
Pages in category "SE Requirements Engineering"
The following 12 pages are in this category, out of 12 total.
