Throughout my career, I have observed that different people are attentive to and focused on  different levels of detail, according to their personality, role, and experience. I mentally tend to put these people into one of two groups: "Roughly right" personality types, and "Precisely right" personality types (with apologies to Malcom Gladwell).

If you try to make a presentation about details to Roughly Right people, you will lose them. Yet if you don't provide such details to Precisely Right people, any commitment you seek, or plans you may offer may have little credibility with them.

Successful projects must thus provide a reliable means of engaging with both of these types of people, achieving their buy-in, and demonstrating the ability to translate from high-level concepts to corresponding details consistently. Linking this information requires enough time, resources, and attention to elaborate these details, and close the inevitable gaps of interpretation, as they arise.

Roughly Right people acknowledge there are such gaps, but rarely are the ones that have the persistence or attention to close them. They are starters, not finishers. Precisely Right people, in contrast, often want to have all the details before they can be made available (or have stabilized). You can't expect Roughly Right people to be able to provide all of the details needed by Precisely Right people. But until those that need these details have them, you also can't expect that you have sufficient control of the critical factors which could impact what it will take to deliver on a requested, but not yet well understood, requirement.

Requirements are discovered, not collected. This is because no one generally will have thought through all the details. Problems usually can't be adequately defined until they are at least partially solved, and the investigation itself will tend to be a joint learning and decision-making experience which will motivate stakeholders to think harder about what they really want.

In practice, different stakeholders will ultimately need to take action based upon different levels of requirements, as they are elaborated, and need to factor in the uncertainties which may be inherent in their level of those requirements. Leaders must commit to projects before all of the details of the associated products will all be defined, and so must ensure that contingent resources will be available to achieve project commitments. Architects need access to enough detail to determine performance drivers for how a capability will be used in practice, in order to drive out a sufficiently robust platform for operational use, and provide for an adequate design margin for anticipated growth. Yet in the end, those that must deliver solutions need to know exactly what they need to do, in order to build and deliver the right functionality at the right time, so stakeholders that can make use of that functionality. Additionally, there tends to simultaneously be 'bottom-up' and 'top-down' efforts to elicit, explore, evolve, and communicate this information, and these parallel efforts have to be reconciled on an ongoing basis.

The key to resolving this ambiguity is to work with the right stakeholders to define the specific information needed which will satisfy their needs and enable their jobs to be done efficiently. These requirements will be most effective when they are collaboratively developed by knowledgeable subject matter experts, so the requirements will document in a meaningful way what is needed by those stakeholders. Requirements thus become contracts between customers (or their proxys) and those who are responsible for for delivering solutions. The requirements will therefore typically be written at different levels of detail (or 'tiers') for different audiences. These levels may also be used to establish ownership or responsibilities acting on those requirements for individuals or teams. For example, the top tier might establish product visions, which may be owned by everyone; intermediate levels might define derived requirements for component or product teams; finally, the lowest tiers might establish requirements for one or more specific individuals. Since such decomposition and allocation is an important part of disciplined development, a unique identifier should be established for each requirements element within each tier, so these allocations and relationships can be easily cross-referenced, tracked, and maintained over time.

Requirements should be expressed in a standardized format, typically as an active sentence which describes a single intended result. It is helpful when a specific pattern is employed in documenting such requirements, such as:

When <triggering event> occurs, <actor> shall perform <action> if <condition> exists.

While such a pattern can be used to describe functional requirements, a set of relevant quality attributes for  functions should also be captured. Such attributes typically are best identified by establishing a performance scale for each quality attribute, to designate the target, stretch, and failure measures for the corresponding function. Such attributes provide a context for subsequent trade-offs as candidate solutions are evaluated, and may be useful in tracking system development progress over time.