1.2The requirements definition process

Requirements definition is not the work of "writing down whatever stakeholders say." If requirements conflict among stakeholders, or if a vague requirement is agreed to as-is, rework occurs in downstream phases (design, development, testing), significantly affecting cost and schedule. A system architect is required to have the judgment to spot early signs of conflicting or ambiguous requirements and to design how the consensus-building process should proceed.

1.2.1Requirements elicitation and analysis

• Requirements elicitation is the activity of drawing out the requirements stakeholders hold—not just explicit requirements but also requirements implicit within the business—using methods such as interviews, workshops, on-site observation, and review of existing documents. Because stakeholders differ in position and interest, it is expected that conflicting requirements will surface even for the same function.
• Requirements analysis organizes and structures the elicited requirements, surfaces duplication and contradictions, and prioritizes them. When conflicting requirements are found, it is the system architect's role not to decide on the spot by majority vote or by whoever speaks loudest, but to judge which is essentially needed in light of business strategy and business goals, and, if needed, to set up a forum for building consensus among the parties involved.

1.2.2Functional/non-functional requirements, traceability, and change management

• Functional requirements define "what" the system does (business functions, screens, reports, and so on). Non-functional requirements define "at what quality level" it is realized—performance, reliability, availability, security, maintainability, and the like. Because non-functional requirements are rarely volunteered by users and tend to be agreed to while still vague, the system architect must proactively draw them out and document them explicitly.
• Requirements traceability is the mechanism that makes it possible to track which design, implementation, and test case each individual requirement corresponds to. It is essential for identifying the full impact scope without omission when a requirement changes. Change management is the process of evaluating the impact scope, cost, and schedule impact of a requirement change arising during development, and deciding to approve or reject it, rather than incorporating changes without discipline.

Suppose you are the system architect for a membership-service renewal project, and midway through requirements definition you notice that the sales department says, "we want the search feature usable right away; there's no particular response-time requirement," while the operations department requests, "please respond within 3 seconds even at peak load." Judging that "sales didn't mention a non-functional requirement, so we'll proceed as if there is none" is dangerous here, because non-functional requirements are rarely volunteered by users, and the likely reason sales said "no requirement" is simply that they weren't thinking about performance at all. The appropriate approach is to ask sales, as part of requirements elicitation, concrete questions such as "how many searches and users do you expect at peak?" and "how would business be affected if a response were slow?", making the implicit expectation explicit. You then cross-check it against operations's "within 3 seconds" requirement as part of requirements analysis to confirm there is no contradiction; if achieving 3 seconds under the peak load sales anticipates is not cost-justified, you need to build consensus among the parties on a response-time target in light of the business goal (member satisfaction, churn rate). Once agreed, the non-functional requirement should be linked, via requirements traceability, to the performance test cases in a downstream phase, so that whether the requirement is met can be verified. Rather than "treating an unstated requirement as nonexistent," the core of the requirements definition process is to proactively draw out unstated requirements (especially non-functional ones) and to build consensus on conflicting requirements in light of business goals.

1.2.3Section summary

• Requirements elicitation should assume conflicting requirements will surface, and requirements analysis prioritizes them in light of business goals
• Non-functional requirements are rarely volunteered, so they must be actively drawn out and agreed to as measurable levels
• Requirements traceability and change management identify the full impact scope of a change without omission and prevent undisciplined incorporation