ASEP Requirements Definition and Analysis 3 — Questions and Answers
Question 1: Which verification method is most appropriate for confirming that a system meets a quantitative performance requirement?
- Inspection
- Demonstration
- Test (Correct answer)
- Analysis
Correct answer: Test
Testing is the preferred verification method for quantitative performance requirements because it provides objective, measured evidence of compliance under controlled conditions.
Testing involves exercising the system under controlled conditions and measuring the results against specified criteria. It is the preferred method for verifying quantitative performance requirements because it provides objective, repeatable, measured evidence. Inspection verifies physical characteristics (dimensions, markings). Demonstration shows qualitative capability through operation without formal measurement. Analysis uses mathematical modeling or simulation when testing is impractical. The choice of verification method should be specified during requirements definition to ensure requirements are written in a verifiable manner appropriate to the selected method.
Question 2: What is the significance of the 'shall' keyword in requirements statements according to systems engineering standards?
- It indicates an optional feature
- It denotes a mandatory, binding requirement that must be met (Correct answer)
- It suggests a design recommendation
- It marks a requirement as low priority
Correct answer: It denotes a mandatory, binding requirement that must be met
In requirements engineering, 'shall' indicates a mandatory requirement that the system must satisfy, distinguishing it from 'should' (goal) and 'may' (optional).
In systems engineering requirements standards (including IEEE 29148 and INCOSE guidelines), 'shall' is the keyword that designates a mandatory requirement—a binding provision that the system must satisfy for compliance. 'Should' indicates a goal or non-mandatory recommendation, 'may' indicates an optional provision, and 'will' typically describes facts or declarations of purpose. The precise use of these keywords is critical because in contractual contexts, 'shall' statements define the acceptance criteria against which the delivered system will be evaluated. Misuse of these terms can lead to ambiguity about what is truly required versus desired.
Question 3: During requirements elicitation, why is it important to identify and resolve conflicting requirements early?
- Conflicts always improve system performance
- Unresolved conflicts lead to design compromises, rework, and potential system failures if discovered late (Correct answer)
- Conflicts are beneficial and should be preserved
- Early resolution reduces the number of total requirements
Correct answer: Unresolved conflicts lead to design compromises, rework, and potential system failures if discovered late
Unresolved conflicting requirements create design problems, force costly rework, and may lead to system failures if contradictions are discovered during integration or testing.
Conflicting requirements arise when different stakeholders have incompatible needs, or when requirements at different levels contradict each other. Early identification and resolution is critical because the cost of resolving conflicts increases exponentially with lifecycle phase—a conflict discovered during integration may require redesign of multiple subsystems. Conflict resolution techniques include stakeholder negotiation, trade studies, prioritization (MoSCoW or weighted scoring), and architectural analysis. The systems engineer plays a key role in surfacing these conflicts through cross-referencing, formal reviews, and modeling before design commitments are made.
Question 4: What distinguishes functional requirements from non-functional requirements in systems engineering?
- Functional requirements are less important
- Functional requirements describe what the system must do; non-functional requirements describe how well it must perform or constraints it must satisfy (Correct answer)
- Non-functional requirements do not need to be verified
- There is no meaningful distinction between them
Correct answer: Functional requirements describe what the system must do; non-functional requirements describe how well it must perform or constraints it must satisfy
Functional requirements define what the system must do (capabilities and behaviors), while non-functional requirements define quality attributes and constraints on how the system performs.
Functional requirements specify the functions, capabilities, and behaviors the system must provide—what it does. Examples include processing inputs, generating outputs, and performing calculations. Non-functional requirements (also called quality attributes or supplementary requirements) specify constraints on how the system performs those functions, including performance (response time, throughput), reliability (MTBF, availability), security (access control, encryption), usability, and maintainability. Both types are equally important and must be verifiable. A common mistake is treating non-functional requirements as secondary, but attributes like security and reliability often drive architectural decisions more than functional requirements do.
Question 5: What is the purpose of requirements decomposition in the systems engineering Vee model?
- To eliminate unnecessary requirements
- To progressively refine high-level requirements into increasingly detailed specifications at each level of the system hierarchy (Correct answer)
- To combine all requirements into a single document
- To assign requirements to the testing team
Correct answer: To progressively refine high-level requirements into increasingly detailed specifications at each level of the system hierarchy
Requirements decomposition breaks high-level requirements into progressively more detailed specifications at each hierarchical level (system, subsystem, component) along the left side of the Vee.
In the Vee model, the left (descending) side represents progressive decomposition: stakeholder requirements are refined into system requirements, which are allocated and decomposed into subsystem requirements, and further into component-level specifications. At each level, requirements become more detailed and specific, addressing the particular concerns of that hierarchical level. This decomposition ensures that every high-level need is addressed by one or more lower-level requirements, maintaining traceability. The right (ascending) side of the Vee then integrates and verifies at each corresponding level, confirming that the decomposed requirements are satisfied by the assembled system.
Question 6: Why should requirements include specific acceptance criteria?
- To make documents longer
- To enable objective verification by providing clear, measurable conditions that determine whether the requirement has been met (Correct answer)
- To limit the design team's creativity
- To satisfy documentation standards only
Correct answer: To enable objective verification by providing clear, measurable conditions that determine whether the requirement has been met
Acceptance criteria define the specific, measurable conditions that determine whether a requirement is satisfied, enabling objective and repeatable verification.
Acceptance criteria are the specific, measurable conditions associated with a requirement that determine whether it has been satisfied. Including them in requirements specifications ensures that verification activities have clear pass/fail criteria, eliminates ambiguity about what constitutes compliance, enables objective evaluation independent of who performs the verification, and facilitates test planning by defining what must be measured. Requirements without acceptance criteria often lead to disputes between developers and customers about whether the requirement has been met. Well-written acceptance criteria specify the conditions, inputs, expected outputs, and tolerances for verification.
ASEP Requirements Definition and Analysis 3
Which verification method is most appropriate for confirming that a system meets a quantitative performance requirement?