| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" epf:version="1.0.0" xmi:id="-I4IbR1GW6IFBCdq9SiMUsw" name="core_principle_balance,_ssG6MMvpEdqukPpotm3DYg" guid="-I4IbR1GW6IFBCdq9SiMUsw" changeDate="2006-09-27T16:34:53.658-0700" changeDescription="Removed metaphoric photo Removed open_up from page name." version="0.02"> |
| <mainDescription><h3 style="MARGIN: 12pt 0in 3pt"> |
| Introduction |
| </h3> |
| <p style="MARGIN: 12pt 0in 3pt"> |
| Systems are rarely all things to all people. Often, attempts to make them so are wasteful and result in bloated |
| systems. |
| </p> |
| <p> |
| Therefore, project participants and stakeholders must collaborate to develop a solution that maximizes stakeholder |
| benefits and complies with constraints placed on the project. Achieving balance is a dynamic process because as both |
| the stakeholders and project participants learn more about the system, their priorities and constraints change. |
| </p> |
| <p> |
| To be successful, stakeholders and the project participants must converge on a clear understanding and agreement of |
| these three factors: |
| </p> |
| <ul> |
| <li> |
| Problem to be solved |
| </li> |
| <li> |
| Constraints places on the development team (cost, schedule, resources, regulations) |
| </li> |
| <li> |
| Constraints placed on the solution |
| </li> |
| </ul> |
| <p> |
| Collectively, these three items represent the requirements for the development of the system. The challenge for all |
| project participants is creating a solution that maximizes 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 a<span>rchitecture of the system.</span> |
| </p> |
| <p> |
| 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. Therefore, stakeholders |
| and developers must be prepared to re-evaluate commitments, reset expectations, and adjust plans accordingly as the |
| system evolves. |
| </p> |
| <h3 style="MARGIN: 12pt 0in 3pt"> |
| Practices |
| </h3> |
| <p style="MARGIN: 12pt 0in 3pt"> |
| The next sections describe the practices associated with this principle. |
| </p> |
| <h4 style="MARGIN: 12pt 0in 3pt"> |
| Know your audience |
| </h4> |
| <p> |
| You cannot know how to make effective trade-offs if you do not know who the stakeholders are and what they really want. |
| </p> |
| <p> |
| Therefore, 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. |
| </p> |
| <h4 style="MARGIN: 12pt 0in 3pt"> |
| Separate the problem from the solution |
| </h4> |
| <p> |
| 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 our understanding of the problem, imposes |
| artificial constraints,&nbsp;and makes it difficult to balance trade-offs, or to even know what the trade-offs are. |
| </p> |
| <p> |
| Therefore, 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. |
| </p> |
| <h4 style="MARGIN: 12pt 0in 3pt"> |
| Create a shared understanding of the domain |
| </h4> |
| <p> |
| 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. |
| </p> |
| <p> |
| Therefore, 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. |
| </p> |
| <h4 style="MARGIN: 12pt 0in 3pt"> |
| Use scenarios and use cases to capture requirements |
| </h4> |
| <p> |
| 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. . |
| </p> |
| <p> |
| Therefore, use 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 in the Supporting Requirements, using traditional techniques. |
| </p> |
| <h4 style="MARGIN: 12pt 0in 3pt"> |
| Establish and maintain agreement on priorities |
| </h4> |
| <p> |
| 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 that result in delays and even project failure. |
| </p> |
| <p> |
| Therefore, 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. |
| </p> |
| <h4 style="MARGIN: 12pt 0in 3pt"> |
| Make the trade-offs to maximize value |
| </h4> |
| <p> |
| 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. |
| </p> |
| <p> |
| Therefore, work with the stakeholders and developers 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 assessment of cost versus benefit. The&nbsp;candidate architecture&nbsp;that provides the most |
| coverage at the lowest cost is selected for further development. |
| </p> |
| <h4 style="MARGIN: 12pt 0in 3pt"> |
| Manage scope |
| </h4> |
| <p> |
| Change is inevitable. Although change presents opportunities to enhance stakeholder value, unconstrained change will |
| result in a bloated, deficient system and unmet stakeholder needs. |
| </p> |
| <p> |
| Therefore, manage change while maintaining the 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. |
| </p> |
| <h4 style="MARGIN: 12pt 0in 3pt"> |
| Know when to stop |
| </h4> |
| <p> |
| Over-engineering a system not only wastes resources but also leads to an overly complex system. |
| </p> |
| <p> |
| Therefore, stop developing the system when the desired quality is achieved. Remember that “Quality is conformance to |
| the requirements” <a href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[CRO79]</a>. 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. |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |