ASEP Requirements Definition and Analysis 2 — Questions and Answers
Question 1: What characteristic distinguishes a well-formed requirement from a poorly written one according to INCOSE guidelines?
- It uses technical jargon extensively
- It is singular, unambiguous, measurable, and verifiable (Correct answer)
- It describes the design solution in detail
- It references specific vendors or technologies
Correct answer: It is singular, unambiguous, measurable, and verifiable
INCOSE guidelines specify that well-formed requirements must be singular (addressing one need), unambiguous, measurable, and verifiable through testing or analysis.
According to INCOSE, well-formed requirements possess several essential characteristics: they are singular (each requirement addresses exactly one need), unambiguous (only one possible interpretation), measurable (quantified where possible), verifiable (can be confirmed through test, analysis, inspection, or demonstration), traceable (linked to a source and to design/test artifacts), and achievable (technically feasible within constraints). Poorly written requirements often combine multiple needs, use vague terms like 'adequate' or 'sufficient,' describe design solutions rather than needs, or cannot be objectively verified.
Question 2: What is the primary purpose of requirements validation as opposed to requirements verification?
- To ensure requirements are properly numbered
- To confirm that the requirements accurately reflect stakeholder needs and expectations (Correct answer)
- To verify that the system meets its requirements
- To allocate requirements to subsystems
Correct answer: To confirm that the requirements accurately reflect stakeholder needs and expectations
Requirements validation confirms that the documented requirements actually capture what stakeholders need, while verification confirms the system meets those requirements.
Requirements validation answers the question 'Are these the right requirements?' by confirming that documented requirements accurately represent stakeholder needs, expectations, and constraints. This is distinct from requirements verification, which answers 'Does the system satisfy its requirements?' and from system verification, which confirms the system was built correctly. Validation techniques include stakeholder reviews, prototyping, modeling, and scenario walkthroughs. Validation is critical because even perfectly implemented requirements are worthless if they do not reflect actual stakeholder needs—building the wrong system right is a costly failure mode.
Question 3: In requirements analysis, what does 'derived requirement' mean?
- A requirement copied from another project
- A requirement that emerges from design decisions, analysis, or architectural choices rather than directly from stakeholder needs (Correct answer)
- A requirement that has been deleted from the baseline
- A requirement that is optional
Correct answer: A requirement that emerges from design decisions, analysis, or architectural choices rather than directly from stakeholder needs
Derived requirements emerge from design decisions, architectural choices, or analysis rather than being directly traceable to an originating stakeholder requirement.
Derived requirements are requirements that are not directly traceable to a higher-level stakeholder or system requirement but instead emerge from design decisions, implementation constraints, architectural choices, or engineering analysis. For example, a stakeholder requirement for 99.99% availability might lead to a derived requirement for redundant power supplies—a design choice, not a stakeholder statement. Derived requirements must still be documented, managed, and verified. They are important to track because they represent engineering assumptions and decisions that need validation to ensure they correctly support the originating requirements.
Question 4: Which requirements analysis technique uses structured scenarios to explore system behavior under various conditions?
- Quality Function Deployment
- Use case analysis (Correct answer)
- Earned Value Management
- Work Breakdown Structure
Correct answer: Use case analysis
Use case analysis employs structured scenarios describing actor-system interactions to explore and document system behavior under normal and exceptional conditions.
Use case analysis is a requirements analysis technique that employs structured scenarios to describe interactions between actors (users, external systems) and the system under development. Each use case specifies a sequence of steps for normal operation (the main success scenario) and alternative/exception paths. This technique helps discover missing requirements by forcing analysts to think through complete interaction sequences, including error handling and edge cases. Use cases complement traditional shall-statement requirements by providing behavioral context and are particularly effective during stakeholder reviews because they tell a concrete story.
Question 5: What risk does requirements creep pose to a systems engineering program?
- It reduces the number of stakeholders
- It introduces uncontrolled growth in scope, potentially impacting cost, schedule, and technical performance (Correct answer)
- It simplifies the verification process
- It eliminates the need for trade studies
Correct answer: It introduces uncontrolled growth in scope, potentially impacting cost, schedule, and technical performance
Requirements creep is the uncontrolled addition of new requirements after baselines are established, which can increase cost, extend schedule, and degrade system performance.
Requirements creep refers to the uncontrolled, incremental addition of new requirements or expansion of existing ones after the requirements baseline has been established. It poses significant risks: increased development cost as new work is added, schedule delays as additional requirements must be designed, implemented, and verified, potential degradation of system performance as the design accommodates unplanned features, and increased integration complexity. Requirements creep is managed through formal change control processes, configuration management, and CCB review of all proposed requirements changes against their cost, schedule, and technical impacts.
Question 6: What is the purpose of a Requirements Traceability Matrix (RTM) in systems engineering?
- To list all project team members
- To document bidirectional links between requirements at different levels and to verification activities (Correct answer)
- To calculate project costs
- To define the organizational chart
Correct answer: To document bidirectional links between requirements at different levels and to verification activities
An RTM documents the bidirectional trace between requirements at all levels (stakeholder, system, subsystem) and links them to design elements and verification activities.
A Requirements Traceability Matrix documents the relationships between requirements at different hierarchical levels and between requirements and other lifecycle artifacts. Forward traceability links higher-level requirements to lower-level derived requirements and design elements, ensuring all requirements are addressed. Backward traceability links lower-level items to their originating requirements, confirming every design element has a justified purpose. The RTM also links requirements to verification methods and results, providing evidence of compliance. It is a living document that must be maintained throughout the lifecycle and is essential for impact analysis when changes are proposed.
ASEP Requirements Definition and Analysis 2
What characteristic distinguishes a well-formed requirement from a poorly written one according to INCOSE guidelines?