INFOSYS 220 Chap.3 Elicitation and Prioritisation
Elicitation and Prioritisation
Gather evidence about work and value
Elicitation draws out information that may be incomplete, tacit or disputed. Interviews allow follow up and explanation; questionnaires can reach many respondents efficiently but cannot easily resolve ambiguity; observation reveals actual work but may be distorted by timing or observer effects; document analysis exposes rules and records but may preserve outdated practice.
Method choice should follow the question, stakeholder access and evidence risk.
Shape and control requirements
Business requirements state organisational goals, user requirements describe stakeholder needs, functional requirements define solution behaviour, nonfunctional requirements set measurable qualities or constraints, and transition requirements support the temporary move to a future state.
Prioritisation compares value, risk, dependency, compliance, cost and urgency. Validation asks whether a requirement supports a real need and value. Verification asks whether it is clear, consistent and agreed. Traceability links it backward and forward so change impacts can be found.
What this chapter covers
- 01
Interviews, questionnaires, observation and document analysis
- 02
Business, user, functional, nonfunctional and transition requirements
- 03
Clear, complete, correct and consistent requirement quality
- 04
MoSCoW and evidence based priority criteria
- 05
Validation against need and value
- 06
Verification, agreement and backward or forward traceability
Worked example · free
Elicit and rank a reporting requirement
- 2Select complementary evidence methods and justify them.
- 3Write distinct functional and nonfunctional requirements.
- 2Prioritise using value, risk and dependency.
- 1Name a validation check.
Key terms
- Elicitation
- Active discovery of stakeholder knowledge, needs, constraints and evidence about current or future work.
- Functional Requirement
- A statement of behaviour or information the system must provide to support a task.
- Nonfunctional Requirement
- A measurable quality, safeguard or operating constraint applied to the solution.
- Transition Requirement
- A temporary need for migration, training, continuity or another move into the future state.
- Validation
- Checking that a requirement supports stakeholder need, business goals and expected value.
- Verification
- Checking that a requirement is clear, consistent, feasible and agreed at the required quality.
- Traceability
- Links that connect a requirement to its origin, related requirements, designs, implementation and tests.
Elicitation and Prioritisation FAQ
Which elicitation technique is best?
No technique is universally best. Choose according to the evidence needed, stakeholder availability, sensitivity, scale and ambiguity. Combining methods is often stronger: observation can reveal actual work, while an interview explains why it happens and document analysis checks the governing rule.
What makes a nonfunctional requirement testable?
It names a quality or constraint, relevant conditions, a measure and an acceptable threshold. Saying that a system must be fast is vague. Stating a response target for a defined transaction and load creates evidence that design and testing can address.
How does validation differ from verification?
Validation asks whether the requirement is the right one for the business need and stakeholder value. Verification asks whether it is written and agreed well enough to use. A beautifully clear feature can pass verification while failing validation if nobody needs the outcome.
Does Must mean the stakeholder wants it strongly?
Not by itself. A Must should be supported by criteria such as compliance, essential value, safety, dependency or minimum viable operation. Priority is a decision about constrained delivery, not an intensity label. Record the rationale so later changes can be reviewed consistently.
Exam move
Build a requirement set from one observed process rather than inventing isolated sentences. Start with an elicitation plan that pairs each stakeholder question with a method and explains its limitations. Record observations separately from interpretations. Classify the resulting statements as business, user, functional, nonfunctional or transition requirements, then rewrite any item that contains several obligations.
For every nonfunctional requirement, add a condition, measure and threshold. Create a MoSCoW table, but include a reason column using value, risk, compliance, dependency, cost or urgency. Challenge one Must by asking what would happen if it moved later. Draw a traceability tree from business need to two requirements, one design element and one test. Then change a requirement and identify every affected branch.
Use two colours to distinguish validation evidence from verification evidence. For retrieval, compare interview and questionnaire strengths without declaring a universal winner, and explain when observation could mislead. Finish with a quality review: remove vague words, hidden design choices, pronouns without actors and requirements that cannot be tested.
A strong study answer should name the requirement type, explain the evidence, justify the priority and show its trace links.
Working through Elicitation and Prioritisation in INFOSYS 220? Sia is AskSia’s AI Information Technology tutor — ask any INFOSYS 220 Elicitation and Prioritisation question and get a clear, step-by-step explanation grounded in how INFOSYS 220 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.