Negotiating and documenting commitments
This is the third in a series on elaboration
When we talk about commitments in system development, it's tempting to treat requirements as static checklists. But requirements are more than specifications; they’re negotiation points, communication artifacts, and foundational tools for aligning disparate actors around shared outcomes. To build anything with integrity, the commitment must be understood not only as deliverable, but as dialogue.
In the Software Engineering Body of Knowledge, a software requirement is described as a ‘property that must be exhibited by something to solve a problem in the real world’. The Project Management Body of Knowledge has a different take on the definition, describing it as 'A condition or capability that must be met or possessed by a system, product, service, result, or component to satisfy a contract, standard, specification, or other formally imposed documents'.
Both SEBoK and PMBOK frame requirements as necessities but from different viewpoints. SEBoK emphasizes the outcome-oriented nature of problem-solving, while PMBOK anchors its definition in compliance and contract fulfillment. Together, they reveal how commitments are shaped by context: solving real-world problems versus meeting imposed conditions.
In both definitions, requirements provide a basis for communicating expectations and negotiating agreements about one or more aspects of a product or service.
Requirements span multiple categories - functional, performance, regulatory, user-experience, and more - and each demands distinct elicitation techniques. Navigating these differences is crucial, as the method of discovering a need often determines how successfully it will be addressed.
It is commonplace that a problem stated is well on its way to solution, for statement of the nature of a problem signifies that the underlying quality is being transformed into determinate distinctions of terms and relationships, or has become an object of articulate thought. - John Dewey, The Symposium (1930)
This insight echoes in our domain: framing a requirement precisely transforms ambiguity into actionable design space. The quote isn't just philosophical, it’s a call to express commitments so clearly that they invite resolution.
The role for requirements
A requirement is more than a request—it is a precise articulation of a capability or condition that delivers value within a specific context. Formally, a requirement is a singular expression of an attribute or functional need that a solution is expected to provide or perform. This expression should describe the necessary attribute, capability, characteristic, or quality that will have value and utility within a defined context. To fulfill these needs, requirements should be expressed in a way that enhances the communications between real customers with needs, and the providers of solutions, and guides and captures the results of negotiating exactly what will be delivered, and how acceptability will be evaluated. They provide the backbone for organizing and communicating what needs to be done among responsible parties, including through the supply chain, so implementation activities can proceed independently.
These expressions should be crafted to bridge the understanding between those with needs and those providing solutions. They should document the terms of acceptance, outline how delivery will be validated, and enable independent execution across teams and domains—all while adapting to change without sacrificing coherence.
Updates must be managed to support the pace of development without introducing delays, and while providing full transparency consistent with Figure 1.
Such commitments are particularly important when solution producers and customers with needs are distributed across disciplines and product domains; in this situation, specifying the details of a solution prematurely, or being unnecessarily prescriptive, can restrict essential analysis and design activities that could solve a customer's problem more efficiently or effectively. Requirements enable progress to be evaluated and demonstrated as a product is being designed and implemented. If the quality of these requirements is low, the likelihood of rework increases, with adverse impacts on testing, integration, acceptance, and continuing issues once in service.
Requirements also should provide a basis for verifying that the product or service has been correctly implemented, and so that satisfactory work performance has been confirmed. The requirements should also incorporate the business's expectations for how work should be performed, as well as target characteristics for the solution itself. Finally, requirements should establish an acceptable basis for measuring outcomes and evaluating candidate designs and establish criteria for evaluating options and making decisions throughout the developmental effort.
Agreements not prescriptions
In the Design of Design, Fred Brooks describes the importance of capturing these requirements as written agreements to frame the necessary and sufficient basis for development:
We need written agreements for clarity of communication; we need enforceable contracts for protection from misdeeds by others and temptations for ourselves. We need detailed enforceable contracts even more when the players are multi-person organizations, not just individuals. Organizations often behave worse than any member would. Clearly, it is the necessity for contracts, whether within an organization or between organizations, that forces the too-early binding of goals, requirements, constraints. Everyone recognizes the fact that these must later be changed.
These agreements must be progressively negotiated and elaborated between stakeholders (or their proxies) and the product, component, and service providers who will be responsible for implementing and delivering solutions to those customers. Frequently, stakeholders attempt to position their desires and interests as requirements, by suggesting that the absence of a capability is a problem; yet in such situations, no considerations may have been made about alternate uses of resources.
It is easy to elicit the needs of many stakeholders; only a few of these needs will be sufficiently worthwhile and achievable within the constraints imposed by available investments and teams. Deeper interactions with customers are always needed to gain insight into the relative merit of a spectrum of attributes so that the right balance is achieved.
Agreements between producers and consumers can rarely be reached through oral communications and face-to-face communications alone. While preliminary discussions may be a good start, sufficient time and freedom must be established for analysis exploration of each other's conceptual frameworks, and so that key concepts can unambiguously be described from a foundation of well-established precedents and clear, shared language. Unfortunately, when too many people are involved in attempting to craft this language when they are separated by fuzzy organizational boundaries, time, or distance, or when the number of concepts which must be understood exceeds the hrair limit of those involved, story-telling and graphical representations often become the fallback abstractions that people rely on. These will be of limited use when it comes time to produce something.
Problem and solution spaces
Since one person's requirement is often viewed by another as a design or constraint, the line separating the description of 'what' and the description of 'how' is often quite fuzzy and may become the focus of fruitless debates. Unfortunately, such debates may delay elaboration of the details necessary for proper trades to be performed. It may be helpful for all sides participating in these debates to position their discussions within what is called a problem space and a solution space. When exploring requirements within the problem space, it is often helpful to ask "Why?" a lot, to explore the motivations, intentions, and rationale underlying each requirement, so the needed capability can be characterized. When exploring and documenting requirements within the solution space, it is more appropriate to have conversations about solution-neutral concepts may be possible, before trying to select the best practical alternative and map requirements into a particular solution.
Requirements constructs
Effective requirements must describe:
Inputs
Triggers
Agents/actors
States and modes
Functional specifications
Performance specifications
Responses to errors
Outputs and effects
A pattern of best practices has emerged which captures this information for a functional requirement within the systems and software engineering communities. Each requirement should be written as an active sentence that describes a single intended result. It should have a tag to allow cross-referencing to occur and should be provided within a hierarchy of related requirements to emphasize the scope, completion criteria, and connections with these other requirements. Since working systems often provide an effective context for many of these attributes, regular demonstrations are often useful to capture feedback on solutions before too much has been invested. As a result, the construct used to express requirements in such settings is terse but effective:
As an [actor], I {want,need} to [take action] in order to accomplish [outcome]
The detailed elaboration of these requirements often takes shape as a user story, with proxies assigned to serve the role of each actor, and who collectively work together to actively shape the story's development. These user stories are expressions of the collective outcomes intended, as seen from each actor's point of view. These stories provide focusing points for all stakeholders to discuss what exactly needs to be done within a given period.
The vision expressed by these stories should capture a set of outcome-directed transactions that will collectively deliver a coherent set of stakeholder capabilities. In such informal requirements definition, the verb 'want' or 'need' is used to delineate firm requirements from juicy desires, though neither may be more important than the other depending upon context. Agile's work-in-process prioritization rationalizes these pursuits into reasonably sized bites for the development team to chew on and digest. This collection of yet-prioritized needs offers little towards justifying future behavior or predicting delivery of adequate capability.
When more complex development situations present themselves, a more rigorous construct is called for. Below is a construct that weaves all the above requirements elements together. It is more relevant to situations where there is a risk in communicating the wrong requirements because of the size of the team, their separation organizationally (such as when outsourcing work) and when harmonization of multiple disciplines is required, such as when building an embedded system. Modernization projects for complex systems are another area where more discipline is required since many views of the elephant must be consumed before an appropriate voice is struck for the system of interest. In such cases, the overall structure of the requirements can change how the overall requirements collection may be interpreted. This structure and the associated requirements definition should capture the results of negotiation, rather than just providing signals to stakeholders about the need for negotiation to begin. The structure of individual requirements is necessarily more robust for these situations:
While in [state], upon an occurrence of a [triggering event], [actor] shall transform [inputs] into [outputs] as dictated by [performance specifications] and verified by [measures of effectiveness].
Non-functional requirements and responses to failure modes are typically not captured in these primary use case formats but instead should utilize formats such as fault trees, state machines, and responses to single and multiple failure scenarios. For example, “Component A fails → system switches to backup component B → communicate condition (advisory, warning, caution, etc) → log incident.”
How many functional requirements of this form will be necessary to describe a product operating within a particular environment? The answer is 'just enough'; too many, and you reduce design options unnecessarily; too few, and a critical aspect of the solution may be overlooked. Striking this balance requires experience, insight, courage, and accountability; until it has been achieved, the risks associated with the gaps in knowledge must be made visible and accounted for in costs and schedules. There is usually a reason behind such gaps and until these constraints are addressed, the risks they represent are likely to fester.
Non-functional requirements
Functional requirements will rarely be sufficient by themselves to establish acceptance criteria or communicate all that a development team needs to know. Performance requirements are often the most important requirements for a system, as they often delineate the design envelope of viable solutions. To demonstrate why this is so, let's consider an outline for a set of functions for a vehicle that will be used for transportation; for brevity, all elements in the above template will not be used. The functions of our example vehicle might include:
Transport passengers and cargo to their destinations
Transport passengers and cargo
Provide means for loading and unloading passengers and cargo
Provide crew and passenger accommodations
Generate and distribute power
Control internal environment
Provide amenities for passengers
Operate vehicle
Prepare for departure
Departure
Cruise
Control speed
Control altitude
Control direction
Prepare for arrival
Arrival
Provide safe and efficient operations
While such functional requirements can answer the 'what' questions that a particular solution should satisfy for a problem statement, in most environments, this is the easy part. While these functions collectively describe characteristics that a solution should satisfy, as written, they could describe a plane, train, bus, bicycle, or even a cruise ship. The method, or algorithm for performing these actions within an operational context still needs to be defined. To adequately define these actions, a language for describing problems and gaps needs to be established among the producers and consumers of the solution, the actors and agents involved, and the outcomes that they intend to occur.
At higher levels, the requirements and functional structure is a mechanism that scopes and chunks the solution space, but may not be sufficiently detailed for implementation, or provide a basis for verification by an independent party. To move beyond the use of just a set of classifiers, we must define essential quality attributes necessary to satisfy the customer's mission, and describe the operational context of the system, so that different configurations of solutions can be considered.
It is much harder to establish non-functional requirements, which define how well these functional requirements must perform. These performance requirements - often called product quality attributes - will drive choices and tradeoffs on crucial architectural decisions necessary for a solution that can affordably support each mission scenario. These attributes are best described by placing them within a performance scale that calibrates the nominal, minimally acceptable, and target thresholds for each of these attributes, and defines how such attributes will be evaluated over time. This depiction will prove useful in shaping the path for the development team in pursuing these outcomes and communicating progress towards these attributes as development progresses.
At the top-most level, these kinds of performance requirements answer questions like these:
over what range must it travel?
how much payload must it carry?
how many passengers must be provided for?
what operator accommodations must be provided?
over which routes must it operate over?
how quickly must it be reconfigured between one operating scenario and another?
how reliably must it perform in service?
how many hours per day must it be capable of being utilized?
how much energy shall it consume?
how big a crew will be necessary to operate and maintain it?
what will it cost to develop and manufacture?
what demand is anticipated?
what will it cost to operate?
what will it cost to maintain?
Such requirements and the decisions they capture form the basis of planning, architectural designs, tradeoffs, and decision-making. The quality of these requirements must be deliberately engineered upfront, or individuals and groups will be tempted to respond to schedule pressures by 'throwing requirements over the wall' and hoping something good happens from it. It rarely does.
A requirements checklist
To avoid this, a set of requirements should be evaluated against these criteria:
is each requirement well-formed?
is each requirement actionable and technically feasible for implementation?
is the ownership and responsibility for further elaboration, implementation, and buy-off clearly established?
is each requirement appropriate to the situation in which it will be deployed?
is each requirement consistent with all other requirements?
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?
The collection of these requirements for each work package should be captured and published as a controlled baseline. A Software Requirements Specification provides a medium and structure for defining these requirements and communicating them to each organization involved in the Statement of Work that the business has committed to performing. These baselines provide the context for verification activities that will allow the determination that these requirements have been satisfied as the development effort proceeds.
Call to action
If commitments are to serve progress rather than constrain it, we must embrace their evolving nature. Expressing, negotiating, and documenting requirements isn’t just paperwork, it’s the scaffolding of collaboration. As you shape the next solution, ask not only “What must be done?” but also “How will we make it acceptable to all?” Because clarity in commitments is clarity in outcomes.