Systems are rarely all things to all people. Often, attempts to make them so are wasteful, and result in bloated
To be successful, stakeholders and the project participants must converge on a clear understanding and agreement of
these three factors:
Problem to be solved
Constraints placed on the development team (cost, schedule, resources, regulations, and so on)
Constraints placed on the solution
The challenge for all project participants is creating a solution that maximizes the value delivered to the
stakeholders, subject to the constraints. Balance is about making the critical, cost-benefit trade-offs between desired
features and the subsequent design decisions that define the architecture of the system.
Discovering the balance point is challenging, elusive, and ongoing, because the balance point is dynamic. As the system
evolves, stakeholder needs change, new opportunities appear, risks are resolved, new risks appear, and the development
team discovers new realities about the system. Change happens throughout the development cycle. stakeholders and team
members must be prepared to re-evaluate commitments, reset expectations, and adjust plans accordingly as the system
Know your audience
You cannot know how to make effective trade-offs if you do not know who the stakeholders are and what they really
Get to know your stakeholders. Better yet, work closely with them to ensure that you know their needs. Start by
identifying all stakeholders, and then maintain open and frequent communication and collaboration between them and
the development team.
Separate the problem from the solution
Too often, we run headlong into a solution without understanding the problem. After all, we are taught how to solve
problems, not how to define problems, so that's easier. However, this limits your understanding of the problem,
imposes artificial constraints, and makes it difficult to balance trade-offs, or to even know what the trade-offs
Make sure that you understand the problem before you define the solution. By clearly separating the problem (what
the customer needs) from the solution (what the system must do), it is easier to maintain the proper focus, and
easier to accommodate alternate ways of solving the problem.
Create a shared understanding of the domain
Domain experts often have limited technical expertise; developers, architects, and testers often have limited
domain expertise; and reviewers and other stakeholders often have limited time to commit to the project and learn
the problem domain. As a result, people often have an inconsistent or poor understanding of the problem domain,
which causes communication problems and increases the likelihood of delivering poor value to the stakeholders.
Enhance and share all parties' understandings of the domain. A concise and shared understanding of the problem
domain enhances communication and project effectiveness. Start by defining the problem in the Vision document. As
your understanding increases, capture key domain concepts and terminology in the Glossary to ensure a consistent,
shared use of the language of the domain.
Use scenarios and use cases to capture requirements
Many companies still document requirements as a list of declarative statements, which are sometimes called the
"shall statements." These lists are often difficult for stakeholders to understand, because they require the end
user to read through and mentally translate the list into a visualization of how the requirements will interact
with the system.
Make use of scenarios and use cases to capture functional requirements in a form that is easy for stakeholders to
understand. Nonfunctional requirements, such as performance, stability, or usability requirements, are important
and can be documented as system-wide requirements, using traditional techniques.
Establish and maintain agreement on priorities
Making poor decisions in deciding what to develop next can result in wasted effort, delivering capabilities that
are never used, or identifying problems late in the project (resulting in delays and even project failure).
Prioritize requirements for implementation by regularly working with the stakeholders during product evolution.
Make choices that deliver value and reduce risks, while building a system that can evolve.
Make trade-offs to maximize value
Cost-benefit trade-offs cannot be made independent of the architecture. Requirements establish the benefits of the
system to the stakeholder, while architecture establishes the cost. The cost of a benefit may influence the
stakeholder's perceived value of the benefit.
Work with the stakeholders and team members to prioritize requirements and develop candidate architectures to
implement those solutions. Use the candidate architectures to evaluate the cost of the benefits. Candidate
solutions are considered at a high level when determining architectural feasibility. Different architectural
perspectives can result in different assessments of cost versus benefit. The candidate architecture that provides
the most coverage at the lowest cost is selected for further development.
Change is inevitable. Although change presents opportunities to enhance stakeholder value, unconstrained change
will result in a bloated, deficient system and unmet stakeholder needs.
Manage change while maintaining agreements with the stakeholders. Modern processes always manage change,
continually adapting to changes in the environment and stakeholder needs, assessing the impact of changes, making
trade-offs, and re-prioritizing work. stakeholder and developer expectations must be realistic and aligned
throughout the development lifecycle.
Know when to stop
Over-engineering a system not only wastes resources, but also leads to an overly complex system.
Stop developing the system when the desired quality is achieved. Remember that "Quality is conformance to the
requirements" [CRO79]. This is what gives a sense of closure to the practice. Separate the
problem from the solution, ensuring that the solution does, indeed, solve the problem. After the critical
requirements are implemented and validated, the system is ready for stakeholder acceptance.