Requirements are discovered, not collected. This is because thinking through and writing down all of the details required to develop and deliver a target solution usually exceeds what any one person knows or can keep in their head. To avoid falling into the abstraction trap, in which notional requirements are established that are not actionable, these details must be synthesized from multiple stakeholders and viewpoints. These details require clarity about the problem, an adequate understanding of the customer's operational concepts, and a framing and characterization of acceptable solutions for the downstream implementers.

Most real-world systems require these details to be captured across four different views:

• a design view, which captures the architecturally significant elements, structures, and functions, and can be used to describe the sequence of execution of these elements under key operating scenarios
• a component view, which maps the design elements onto the structure of the configuration items of the solution's implementation
• a deployment view, which describes how these configuration items will be provided through the service delivery platforms of the solution, and the integration and deployment approach that will be employed so that concurrent development, operations, and support can be accomplished
• a time history view, which describes the control and concurrent coordination of the solution's components in operation

To nail down these details, someone usually must kick-start the process by producing a straw man proposal for this information, starting with the highest possible level of a defined requirements hierarchy. This representation should be traced to the top-level business objectives that it is intended to satisfy. This initial proposal, and credible alternatives to it, can then provide a focus and basis for continued exploration and elaboration at lower levels of refinement. This joint learning and decision-making experience requires everyone to think hard about what they really want, and what can realistically be achieved within the constraints and risks that the project team is given, and should reasonably expect to encounter over time.

In the Design of Design, Fred Brooks describes how important written agreements are in providing an adequate basis for development: 

The resulting detailed requirements must be  written agreements between requirements customers (or their proxies) and the product, component, and service providers who will be responsible for implementing and delivering resulting solutions to those customers. These agreements can rarely be achieved through oral communications and face-to-face communications alone. While this can be a good start, sufficient time and freedom must be established for analysis and to explore each other's conceptual frameworks, and so that key concepts are unambiguously described from a foundation of well-established precedents and clear, shared language. Unfortunately, when too many people are involved, when they are separated by organizational boundaries, time, or distance, or if the number of concepts which must be understood exceeds the hrair limit of those involved, story-telling and graphical representations to often become a fall-back product, and yet will only be of limited use when it comes time to actually produce something.

Requirements therefore should be written at different levels of detail, and for solutions of even moderate complexity, should then be assigned to a structure of hierarchical 'tiers'. The architecture of these levels can then be used to establish ownership or responsibilities for further elaboration or implementation of those requirements by individuals or teams. In this way, requirements can be allocated specifically to the stakeholder organizations who will be responsible for them.

To achieve these objectives, someone must lead and be responsible to work with a defined set of stakeholders to elicit, refine, synthesize,  and review this collection of requirements until they adequately connect the problem and solution space and provide a sufficient basis for implementation. Iterative cycles are typically required to accomplish this elaboration and refinement. By collaborating with appropriate stakeholders, these requirements should converge on a collective understanding between solution customers and solution providers.Even identifying the specific set of stakeholders which will be appropriate for eliciting these requirements for a given situation is not always straightforward. Selected stakeholders may believe they can adequately produce these requirements themselves, in isolation from the other stakeholders. Yet an adequate expression of requirements will usually only stabilize and be useful if they are collaboratively elicited in a structured way. This requires that the sources of these requirements are a defined set of knowledgeable subject matter experts, each of whom brings their unique perspective to the table. The interrelationships, consistency, synthesis, and expression of their requirements must then be further developed in a way which effectively communicates specifically what all these stakeholders need, and how these needs are related to each other.

In designing relationships for and across individual requirements, it can be helpful to consider the kinds of attributes which may be useful in managing the collection of requirements over time. For example:

• A single, designated organization or individual needs to be responsible for eliciting, defining and maintaining the written expression of requirement for an area of responsibility. We call this individual the owner of the requirement.
• Many work packages may be affected by any one particular requirement. Because of this, the responsible organizations or individuals for these work packages must each be responsible for tracking and reporting their compliance and verification status individually with respect to their work packages.
• Particular requirements may be assigned an attribute indicating that additional elaboration will be required before the requirement can be considered as adequately defined. 

For example, a top tier might might establish a product vision, responsibility for which may be jointly owned by everyone; intermediate levels might then define derived requirements from this product vision for component or product teams which resulted from top-level architectural development; finally, the lowest tiers might establish requirements for one or more specific modules or features, which would end up being assigned to an individual or a small team. Since such decomposition and allocation is an important part of disciplined development, a unique identifier should be established for each of these requirements elements within each tier, so these allocations and relationships can be easily cross-referenced, configuration controlled, tracked, and maintained over time.

Requirements within this landscape can evolve to have quite complex relationships with each other. For example, lower-level requirements may be hierarchically associated with a higher-level requirement, and thus provide more details about the specifics intended by these higher-level requirements. In other situations, requirements may have many-to-many relationships between other requirements, with these relationships established so that their heritage and consistency can be maintained over time.

Each of these cycles of iterative refinement progressively populate these tiers and stabilize their content in order to provide a context for lower-level elaboration. Collectively, these tiers and levels thus serve to:

• establish a scope for lower levels of elaboration and subsequent refinement cycles
• connect and focus stakeholders on a defined area of responsibility
• provide an economic and technical basis for evaluating and integrating solutions
• stabilize and synchronize the framework for implementation, and
• provide a foundation for reporting status

A disciplined approach must be used to develop and manage these requirements effectively as this iterative refinement and elaboration is performed. This discipline is essential to assure that the expression of the resulting requirements set is of sufficient quality so that those who will be responsible for implementation can understand them and can implement solutions which will satisfy them.

To further complicate matters, one person's requirement can often be viewed by another as a design. In practice, the line between what and how is often quite fuzzy, and so it is helpful if instead both sides agree to position their discussions within what is called a problem space and a solution space. When in the problem space, it is often helpful to ask "Why?" a lot, to explore the motivations underlying a requirement in the problem space, and what capability is really sought. When in the solution space, it is often helpful to ask if other solutions are possible, and how the best possible alternative can be evaluated.

Requirements quality must be deliberately structured up front, or individuals and groups may respond to schedule pressures by 'throwing requirements over the wall', and hoping something good happens from it. It rarely does. To avoid this, requirements should be evaluated against these criteria:

• is each requirement well formed?
• is each requirement appropriate to the situation in which the solution will be deployed?
• is each requirement consistent with all other requirements?
• is the basis of verification of each requirement clearly established?
• is the ownership for buy-off, further elaboration, and implementation of each requirement clearly established?
• Are the requirements feasible for implementation?
• is the collection of requirements sufficiently comprehensive to address all aspects of the concepts of operation of the system, in both normal and abnormal operations?

As the expression of these requirements and attributes are refined, stakeholders also need to acknowledge the uncertainties which are inherent in their communal understanding of needs and potential solutions, as well as the limitations which are inherent in our ability to communicate with each other.