Introduction

Systems are rarely all things to all people. Often, attempts to make them so are wasteful, and result in bloated systems.

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 evolves.

Practices

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 want.

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 are.

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.

Manage scope

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.