OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/core_principle_balance.html - epf/org.eclipse.epf.nl-libraries - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
 <!-- VERSION rmc:7.1.0 -->
 <html xmlns="http://www.w3.org/1999/xhtml">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
 <!-- START NON-TRANSLATABLE -->
 <title>\openup_basic\guidances\concepts\core_principle_balance.xmi</title>
 </head>
 <!-- WARNING: do not modify the generated comments in this file below this line.  They are used as markers for the import process. -->
 <body>
 Element Name: core_principle_balance.xmi<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: presentationName<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:presentationName,_ssG6MMvpEdqukPpotm3DYg CRC: 2685607669 -->Balance competing priorities to maximize stakeholder value<!-- END:presentationName,_ssG6MMvpEdqukPpotm3DYg -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: briefDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:briefDescription,_ssG6MMvpEdqukPpotm3DYg CRC: 1519387575 -->Develop a solution that maximizes stakeholder benefits and complies with constraints  placed on the project.<!-- END:briefDescription,_ssG6MMvpEdqukPpotm3DYg -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: mainDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:mainDescription,-I4IbR1GW6IFBCdq9SiMUsw CRC: 1335940606 --><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><!-- END:mainDescription,-I4IbR1GW6IFBCdq9SiMUsw -->
 </body>
 </html>
	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
	<!-- VERSION rmc:7.1.0 -->
	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
	<!-- START NON-TRANSLATABLE -->
	<title>\openup_basic\guidances\concepts\core_principle_balance.xmi</title>
	</head>
	<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
	<body>
	Element Name: core_principle_balance.xmi<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: presentationName<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:presentationName,_ssG6MMvpEdqukPpotm3DYg CRC: 2685607669 -->Balance competing priorities to maximize stakeholder value<!-- END:presentationName,_ssG6MMvpEdqukPpotm3DYg -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: briefDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:briefDescription,_ssG6MMvpEdqukPpotm3DYg CRC: 1519387575 -->Develop a solution that maximizes stakeholder benefits and complies with constraints placed on the project.<!-- END:briefDescription,_ssG6MMvpEdqukPpotm3DYg -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: mainDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:mainDescription,-I4IbR1GW6IFBCdq9SiMUsw CRC: 1335940606 --><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, 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 candidate architecture 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><!-- END:mainDescription,-I4IbR1GW6IFBCdq9SiMUsw -->
	</body>
	</html>