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