OpenUP/OpenUP_SP/library/openup_basic/guidances/guidelines/use_case_formats.xmi - epf/org.eclipse.epf.nl-libraries - Git at Google

 <?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-pQrBSyxJHLLodLbS4R_Zdw" name="new_guideline,_qq0GMAXkEduj_7BEUj1JfQ" guid="-pQrBSyxJHLLodLbS4R_Zdw" changeDate="2006-08-16T07:20:15.017-0700">
   <mainDescription>&lt;h3&gt; Use Case Formats &lt;/h3&gt;
 &lt;p&gt; Use cases differ from project to project and person to person. A use case
   that works in one situation may be totally unsuited for another. Different projects
   have different needs. (See &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html&quot; guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;&gt;[ADO04]&lt;/a&gt;
   for more information on use case formats.) &lt;/p&gt;
 &lt;p&gt;Some need rigorous documentation, including &lt;strong&gt;high-ceremony use cases&lt;/strong&gt;,
   which are formal, highly structured use cases. If the writers used a template,
   then they filled out all or almost all of its fields for each use case. High-ceremony
   use cases are best suited for large, extremely complex, safety-critical systems,
   such as flight control systems, telephone switches, and so forth. They are also
   used in development cultures that have high documentation standards. &lt;/p&gt;
 &lt;p&gt;Other projects may be more agile and less formal, benefiting from &lt;strong&gt;low-ceremony
   use cases&lt;/strong&gt;, which are informal, less rigidly structured use cases. If
   the writers used a template, then they may have left many of the fields blank.
   Low-ceremony use cases are best suited for smaller, less complex, less safety-critical
   systems where most of the stakeholders have a strong background in the problem
   domain. Sometimes, simple descriptions suffice, such as use case &lt;strong&gt;briefs&lt;/strong&gt;.
 &lt;/p&gt;
 &lt;p&gt; As &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup_basic/guidances/guidelines/detail_ucs_and_scenarios,_4BJ_YCxSEdqjsdw1QLH_6Q.html&quot; guid=&quot;_4BJ_YCxSEdqjsdw1QLH_6Q&quot;&gt;Guideline:
   Detail Use Cases and Scenarios&lt;/a&gt; explains, it makes sense to write use cases
   iteratively. Starting with the basic details, you can then identify the various
   alternative and error paths that the use case might follow so that you can evaluate,
   rearrange, or eliminate them, and then elaborate or fill in the details of the
   courses that you intended to use. You can then write the
   use cases in&lt;strong&gt; &lt;/strong&gt; one or more of
   the following formats, progressively, until you
   reach the one with the level of detail required for a specific project: &lt;/p&gt;
 &lt;ul&gt;
   &lt;li&gt;&lt;a id=&quot;Actor-Goal-List&quot; name=&quot;Actor-Goal_List&quot;&gt;&lt;strong&gt;Actor-Goal list&lt;/strong&gt;&lt;/a&gt;:
     A format for the overview&lt;/li&gt;
   &lt;li&gt; &lt;a id=&quot;Briefs&quot; name=&quot;Briefs&quot;&gt;&lt;strong&gt;Briefs: &lt;/strong&gt;&lt;/a&gt;A format for
     writing summary use cases&lt;/li&gt;
   &lt;li&gt; &lt;a id=&quot;Improvisational Score&quot; name=&quot;Improvisational Score&quot;&gt;&lt;strong&gt;Improvisational
     score: &lt;/strong&gt;&lt;/a&gt;A format for writing less formal, low-ceremony use cases&lt;/li&gt;
   &lt;li&gt; &lt;a id=&quot;Symphonic Score&quot; name=&quot;Symphonic Score&quot;&gt;&lt;strong&gt;Symphonic score:
     &lt;/strong&gt;&lt;/a&gt;A format for writing more formal, high-ceremony use cases&lt;/li&gt;
 &lt;/ul&gt;
 &lt;h4&gt;Actor-Goal list &lt;/h4&gt;
 &lt;p&gt; &lt;strong&gt;Context: &lt;/strong&gt;You have identified your actors and are trying to
   identify use cases. &lt;/p&gt;
 &lt;p&gt; &lt;strong&gt;Problem:&lt;/strong&gt; Developing a set of use cases in an ad hoc manner
   can lead to unnecessary work, missing features, and feature creep. Weight
   is one of the most important factors in space flight &amp;#8212; so important that
   the United States space agency, NASA, will not
   allow anything on a spacecraft that isn’t absolutely critical to the flight.
   If something literally isn’t worth its weight, then it doesn’t go. Likewise,
   each use case adds cost to a system; therefore, you need to be sure to include
   only those use cases that add some kind of value to your collection. &lt;/p&gt;
 &lt;p&gt; &lt;strong&gt;Forces:&lt;em&gt; &lt;/em&gt;&lt;/strong&gt;&lt;/p&gt;
 &lt;ul&gt;
   &lt;li&gt;
     &lt;p&gt;&lt;strong&gt;Simply listing actors or listing goals is not informative enough,
       but actors and goals together are informative.&lt;/strong&gt; The classical approach
       to writing use cases is to define a list of actors, then find use cases
       for each. A variation on this theme is to itemize what the system must accomplish.
       Yet, neither approach is adequate by itself. You need to know both who is
       using the system and why they are using it. Otherwise, you introduce the
       potential of either feature creep or missed features. At the least, a set
       of use cases should describe this association. &lt;/p&gt;
   &lt;/li&gt;
   &lt;li&gt;
     &lt;p&gt;&lt;strong&gt; A quick overview of the entire project structure is sufficient
       and necessary early in the use case development cycle.&lt;/strong&gt; Ideally,
       this overview should be as short as reasonably possible. It must contain
       key information as to who requires each service and why they need it. Most
       other information is not very useful at this stage of the project, because
       it runs the risk of quickly becoming obsolete, as well as discouraging
       out-of-the-box (innovative) thinking. An overview
       helps the writers work through the entire set from a high-level view, expanding
       some use cases, eliminating others, and combining still others into a more
       logical grouping. &lt;/p&gt;
   &lt;/li&gt;
   &lt;li&gt;
     &lt;p&gt;&lt;strong&gt;You need to be able to expand each to a full use case on demand.
       &lt;/strong&gt;A &lt;em&gt;seedling&lt;/em&gt;&lt;strong&gt; &lt;/strong&gt;use case forms the basis for
       a full use case later in the iterative development cycle. Each seedling
       use case needs to convey enough information so that someone, possibly other
       than the outline writer, can easily go back and expand it into a more informative
       use case. &lt;/p&gt;
   &lt;/li&gt;
 &lt;/ul&gt;
 &lt;p&gt; &lt;strong&gt;Solution: &lt;/strong&gt;Build an Actor-Goal list,
   which is a list of actors and their goals that
   gives you an overview of entire project needs.&lt;strong&gt;&lt;/strong&gt;&lt;/p&gt;
 &lt;ul&gt;
   &lt;li&gt;
     &lt;p&gt;Start by identifying the list of actors who will use the system, and then
       identify at least one goal for each. Actors without goals indicate that
       you haven’t adequately defined the system. The actor is beyond the system’s
       scope, doesn’t belong in the system, or is part of another actor. &lt;/p&gt;
   &lt;/li&gt;
   &lt;li&gt;
     &lt;p&gt;Likewise, leftover goals can indicate that the system is too complex and
       you're trying to accomplish too much, or that you haven’t adequately defined
       all of the necessary actors. Carefully evaluate the leftovers to see if
       you are just overlooking some detail, or whether they don’t belong in the
       system. &lt;/p&gt;
   &lt;/li&gt;
   &lt;li&gt;
     &lt;p&gt;Remove unassociated actors and goals from the list. &lt;/p&gt;
   &lt;/li&gt;
 &lt;/ul&gt;
 &lt;p&gt; Sometimes, this list may provide enough information to serve as use cases
   for very small, high-communicating, low-ceremony project teams. Usually, the
   actor goal list is the first step of identifying use cases. &lt;/p&gt;
 &lt;h4&gt;
     Briefs
 &lt;/h4&gt;
 &lt;p&gt; &lt;strong&gt;Context: &lt;/strong&gt;You have written an Actor-Goal list that outlines
   your use cases. &lt;/p&gt;
 &lt;p&gt; &lt;strong&gt;Problem: &lt;/strong&gt;Relying solely on an overview to capture the important
   parts of a system’s behavior is dangerous, because it provides only high-level
   information and can easily introduce ambiguity into a system. &lt;/p&gt;
 &lt;p&gt; &lt;strong&gt;Forces: &lt;/strong&gt;&lt;/p&gt;
 &lt;ul&gt;
   &lt;li&gt;
     &lt;p&gt;&lt;strong&gt;Although valuable, an Actor-Goal list does not clearly describe
       a system.&lt;/strong&gt; Usually, an outline doesn’t provide enough precision
       to avoid ambiguity, which can wreak havoc on a project by leading to unnecessary
       or erroneous development. Yet, an outline is helpful, because you still
       want an overview that you can easily scan. Unfortunately, with the passing
       of time or sheer volume of work, it’s too easy to forget details
       that were obvious to you earlier.&lt;/p&gt;
   &lt;/li&gt;
   &lt;li&gt;
     &lt;p&gt;&lt;strong&gt;Iterative use case development requires creating placeholders for
       expansion.&lt;/strong&gt; To develop use cases iteratively, you start with sparse
       use cases, reorganize them, and flesh them out as the system takes shape.
       Ideally, these placeholders should be clear enough to: 1) unambiguously
       describe their role in the system, and 2) allow someone to expand the use
       case, even if they were not involved in writing them originally. &lt;/p&gt;
   &lt;/li&gt;
   &lt;li&gt;
     &lt;p&gt;&lt;strong&gt;Because outlines are general by nature, do not spend a lot of time,
       energy, or money writing them. &lt;/strong&gt;Outlines provide an inexpensive
       method of documenting complex ideas in a manner that is easy to follow,
       and they provide a mechanism for people outside of a project to understand
       the high-level concepts. While it may take
       some effort to think things through, you don’t want to waste resources describing
       your ideas. The system is still in a state of flux at this point, and it
       is too early to spend much time documenting its shifting details. &lt;/p&gt;
   &lt;/li&gt;
 &lt;/ul&gt;
 &lt;p&gt; &lt;strong&gt;Solution: &lt;/strong&gt;Write two to four sentences per use case, capturing
   key activities and key-extension handling. &lt;/p&gt;
 &lt;ul&gt;
   &lt;li&gt;
     &lt;p&gt; Expand the Actor-Goal list into&lt;strong&gt; briefs&lt;/strong&gt; by writing a two-
       to four-sentence use cases for each entry in the list. &lt;/p&gt;
   &lt;/li&gt;
   &lt;li&gt;
     &lt;p&gt;Briefly describe each use case’s main&amp;nbsp;scenario and most important
       extensions. &lt;/p&gt;
   &lt;/li&gt;
   &lt;li&gt;
     &lt;p&gt; Include enough information to eliminate ambiguity for at least the main&amp;nbsp;scenario
       of the system. &lt;/p&gt;
   &lt;/li&gt;
 &lt;/ul&gt;
 &lt;h4&gt; Improvisational score&lt;/h4&gt;
 &lt;p&gt; &lt;strong&gt;Context: &lt;/strong&gt;You are operating in well-known domains or in situations
   where writing high-ceremony use cases would require all of your allotted development
   time. &lt;/p&gt;
 &lt;p&gt; &lt;strong&gt;Problem:&lt;/strong&gt; Writing formal, high-ceremony use cases when lesser
   detail would suffice wastes time and resources. &lt;/p&gt;
 &lt;p&gt; Jazz is considered to be “musician’s music,” and jazz players are usually
   highly skilled. Many jazz musicians prefer to improvise in small, highly skilled
   teams, such as jazz quartets. To improvise effectively, the musicians must have
   a thorough understanding of the conventions that form the given musical style,
   including chord sequences, rhythmic patterns, and melodies. These conventions
   provide a basic framework for the musicians to interact as a team, while still
   allowing room for spontaneous creativity. &lt;/p&gt;
 &lt;p&gt; Likewise, use cases do not always need to be specified in excruciating detail.
   A far-preferable strategy is simply to define the basic structure of what the
   developers need to implement. The use cases act as placeholders that may be
   elaborated later or simply improvised by the developer who implements the use
   case. &lt;/p&gt;
 &lt;p&gt; &lt;strong&gt;Forces:&lt;/strong&gt;&lt;/p&gt;
 &lt;ul&gt;
   &lt;li&gt;
     &lt;p&gt;&lt;strong&gt;Briefs do not provide enough information. &lt;/strong&gt;While useful,
       use-case briefs describe only the more significant parts of behavior. Often,
       developers need more information, especially when working in unfamiliar
       domains or in the heart of the system, where the actor has many choices
       to make and many paths to follow. Briefs do not describe all of the important
       events that can happen, nor do they describe the details that go into making
       choices along the way. &lt;/p&gt;
   &lt;/li&gt;
   &lt;li&gt;
     &lt;p&gt;&lt;strong&gt;Fully elaborated use cases can be too expensive, time consuming,
       long to write, and boring to read. &lt;/strong&gt;It
       takes a lot of time and effort to write a formal, fully descriptive set
       of use cases. Maintaining this set takes even longer. Often, a collection
       of use cases reaches the point of diminishing returns long before it is
       completely written, much less formalized. Readers often prefer shorter,
       simpler use cases over long, complicated ones, because overly detailed use
       cases can be overwhelming and, frankly speaking, quite boring. &lt;/p&gt;
   &lt;/li&gt;
   &lt;li&gt;
     &lt;p&gt;&lt;strong&gt;Many groups communicate well enough to
       resolve ambiguities on the fly. &lt;/strong&gt;While briefs may be insufficient,
       stakeholders don’t always need everything to be spelled out for them. Developers
       are usually capable of asking questions and filling out the necessary detail
       from their own domain knowledge. Many people can work with a fair level
       of ambiguity, and most organizations possess what is often referred to as
       their “core competencies.” Mature organizations with strong domain knowledge
       can survive, and even thrive, using more informal, less precise use cases.
     &lt;/p&gt;
   &lt;/li&gt;
 &lt;/ul&gt;
 &lt;p&gt; &lt;strong&gt;Solution: &lt;/strong&gt;Specify the use cases at
   a low level of precision, allowing the developers to fill in the missing details
   as necessary. The level of precision required depends on the background experiences
   of the development team. Skip the less meaningful fields on the template, and
   write the Main Scenario section as a simple paragraph.
   Describe key-extension handling in the next paragraph
   or two. Be prepared to resolve ambiguities and expand detail on the fly throughout
   the project. &lt;/p&gt;
 &lt;p&gt; When you can rely upon open and frequent communication among the developers
   and customer, write the use case with less detail and precision. The developers
   can fill in the gaps by asking users or by using knowledge of the domain. However,
   the developers need a thorough understanding of the business context to be able
   to fill out the details themselves. Even the most knowledgeable developer will
   still need access to the customers and users to get answers to questions and
   clarify requirements. &lt;/p&gt;
 &lt;p&gt; Ideally, the project will be structured to enable effective communication
   between the customer and the developers. Typically, this will involve having
   a small, co-located team, with the developers having easy access to the users
   throughout the project. The risk of misunderstanding can be resolved by frequent
   incremental delivery if the development organization
   has a relatively low-ceremony culture. &lt;/p&gt;
 &lt;p&gt; Jazz improvisation does not always work. It can become tedious and unpleasant
   to listen to, even for the committed connoisseur.
   For this reason, you also need feedback from the audience to determine the success
   of the improvisations. Multi-level or two-tier reviews are critical to success
   (see &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup_basic/guidances/guidelines/effective_req_reviews,_E-dPIL-GEdqb7N6KIeDL8Q.html&quot; guid=&quot;_E-dPIL-GEdqb7N6KIeDL8Q&quot;&gt;Guideline:
   Effective Requirement Reviews&lt;/a&gt;). &lt;/p&gt;
 &lt;p&gt; Improvisation may not always be suitable for the organizational culture, a
   full &lt;strong&gt;symphonic score&lt;/strong&gt; may be preferable in large, high-ceremony
   teams (see section that follows). For instance,
   I once watched a conductor toss his baton away in disgust when a pianist improvised
   to such an extent that the orchestra could not follow the score. If the organization
   deems the risk of improvising to be unacceptably high, then you can specify
   the use cases with a higher level of detail and precision. You could start with
   a strategy of specifying low levels of detail and precision, and then adapt
   as necessary. &lt;/p&gt;
 &lt;h4&gt; Symphonic score &lt;/h4&gt;
 &lt;p&gt; &lt;strong&gt;Context: &lt;/strong&gt;Writing structure for high-ceremony situations,
   such as when there are many developers or when development teams are geographically
   dispersed. &lt;/p&gt;
 &lt;p&gt; &lt;strong&gt;Problem: &lt;/strong&gt;Writing low-ceremony use cases for high-ceremony
   situations raises the risk of miscommunication to unacceptable levels. &lt;/p&gt;
 &lt;p&gt; A conductor’s version of a symphonic score contains the music for the entire
   orchestra, as well as any accompanying vocals. The parts to be performed by
   different voices or instruments are written on a separate staff, with all of
   the staves aligned, one above another. This score specifies each note and its
   associated timing in precise detail, so that the orchestra can perform a symphony
   as the composer intended. &lt;/p&gt;
 &lt;p&gt; As with use cases, a score tells the musician what to play, not how to play
   it. For most symphonies, the orchestra will not be able to meet the composer,
   so instead, they must rely upon the director to interpret the
   score and the composer's intentions. &lt;/p&gt;
 &lt;p&gt; &lt;strong&gt;Forces: &lt;/strong&gt;&lt;/p&gt;
 &lt;ul&gt;
   &lt;li&gt;
     &lt;p&gt;&lt;strong&gt;Certain development situations and cultures require high degrees
       of formality. &lt;/strong&gt;Some organizations operate in a highly formal manner,
       thus require a highly formal process. While this formality may not
       be desirable, it is the company's way of doing business, so things need
       to be done that way. Other organizations are highly formal because they
       do highly complex, life-critical work, where even small failures could have
       disastrous consequences. For instance, no one would feel comfortable flying
       on an airliner with an off-the-shelf, one-size-fits-all flight management
       system. &lt;/p&gt;
   &lt;/li&gt;
   &lt;li&gt;
     &lt;p&gt;&lt;strong&gt;The cost of repairing miscommunication
       is high. &lt;/strong&gt;It is easy to write vague, inadequate use cases full of
       ambiguity. Use cases can be too brief and ambiguous, or contain domain-specific
       details that may be beyond the understanding of many stakeholders. Either
       way, they provide an opportunity for a misunderstanding that leads to an
       incorrect implementation. The cost of correcting these mistakes depends
       on when they are discovered. &lt;em&gt;Earlier&lt;/em&gt; is cheaper than&lt;em&gt; later&lt;/em&gt;,
       especially when later means customers finding the problem in the delivered
       product. To avoid miscommunication, aim to write use cases that are general
       enough for all of the stakeholders to follow, yet precise enough for the
       developers to use when building the system. &lt;/p&gt;
   &lt;/li&gt;
   &lt;li&gt;
     &lt;p&gt;&lt;strong&gt;Developers need detail for implementing steps, business rules,
       data fields, and, especially, for handling extensions. &lt;/strong&gt;No one has
       developed a program that can take a set of use cases as input, and churn
       out a completed system. Even the best-case tools seem to require human intervention
       to flesh out details and resolve ambiguities. Similarly, developers who
       do not understand the business context or lack domain expertise may not
       be able to fully comprehend a product. In an ideal project, software developers
       would have access to the domain experts to ask questions, so they could
       fill in any areas that may have been missed (see&lt;em&gt; Improvisational score&lt;/em&gt;,
       previously). But often, they do not ask. Therefore, they misunderstand the
       more complex or ambiguous use cases in the set. To develop a system correctly,
       a team needs either access to domain experts or additional information that
       describe the steps, business rules, data fields, and extension handling
       that they are implementing. &lt;/p&gt;
   &lt;/li&gt;
 &lt;/ul&gt;
 &lt;p&gt; &lt;strong&gt;Solution: &lt;/strong&gt;Specify your use cases with a high level of precision,
   explicitly filling in all of the details in the use case template, while staying
   technology-neutral. The level of precision required depends on the background
   experiences of the development team. &lt;/p&gt;
 &lt;p&gt; Intuition may tell you that if some detail is good, then more must be better.
   However, be careful about falling into the trap of over-specifying details.
   It’s naive to believe that everyone who reads your use cases will be able to
   understand them. Different people may interpret the use cases differently. Prepare
   for this eventuality in your process, and avoid the tendency to over-specify
   your use cases. If you try to specify a use case in too much detail, you may
   fall into the classic analysis paralysis trap. &lt;/p&gt;
 &lt;p&gt; People are often tempted to address the communication problem by trying to
   explain the business domain within the use cases. In a similar manner, they
   include too much technical detail. Succumbing to these temptations by explaining
   the business domain or including technical details is always a mistake, because
   it complicates the process and obfuscates the requirements. The reader of the
   use cases cannot distinguish the real requirements from the boring background
   information, so will soon get distracted and lose interest. Instead, include
   this information in an extra section. &lt;/p&gt;
 &lt;p&gt; If you are handing over the requirements to a development team whose members
   are unfamiliar with the domain, then you will need an alternative strategy for
   teaching them the domain knowledge. &lt;/p&gt;</mainDescription>
 </org.eclipse.epf.uma:ContentDescription>
	<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-pQrBSyxJHLLodLbS4R_Zdw" name="new_guideline,_qq0GMAXkEduj_7BEUj1JfQ" guid="-pQrBSyxJHLLodLbS4R_Zdw" changeDate="2006-08-16T07:20:15.017-0700">
	<mainDescription><h3> Use Case Formats </h3>
	<p> Use cases differ from project to project and person to person. A use case
	that works in one situation may be totally unsuited for another. Different projects
	have different needs. (See <a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[ADO04]</a>
	for more information on use case formats.) </p>
	<p>Some need rigorous documentation, including <strong>high-ceremony use cases</strong>,
	which are formal, highly structured use cases. If the writers used a template,
	then they filled out all or almost all of its fields for each use case. High-ceremony
	use cases are best suited for large, extremely complex, safety-critical systems,
	such as flight control systems, telephone switches, and so forth. They are also
	used in development cultures that have high documentation standards. </p>
	<p>Other projects may be more agile and less formal, benefiting from <strong>low-ceremony
	use cases</strong>, which are informal, less rigidly structured use cases. If
	the writers used a template, then they may have left many of the fields blank.
	Low-ceremony use cases are best suited for smaller, less complex, less safety-critical
	systems where most of the stakeholders have a strong background in the problem
	domain. Sometimes, simple descriptions suffice, such as use case <strong>briefs</strong>.
	</p>
	<p> As <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/detail_ucs_and_scenarios,_4BJ_YCxSEdqjsdw1QLH_6Q.html" guid="_4BJ_YCxSEdqjsdw1QLH_6Q">Guideline:
	Detail Use Cases and Scenarios</a> explains, it makes sense to write use cases
	iteratively. Starting with the basic details, you can then identify the various
	alternative and error paths that the use case might follow so that you can evaluate,
	rearrange, or eliminate them, and then elaborate or fill in the details of the
	courses that you intended to use. You can then write the
	use cases in<strong> </strong> one or more of
	the following formats, progressively, until you
	reach the one with the level of detail required for a specific project: </p>
	<ul>
	<li><a id="Actor-Goal-List" name="Actor-Goal_List"><strong>Actor-Goal list</strong></a>:
	A format for the overview</li>
	<li> <a id="Briefs" name="Briefs"><strong>Briefs: </strong></a>A format for
	writing summary use cases</li>
	<li> <a id="Improvisational Score" name="Improvisational Score"><strong>Improvisational
	score: </strong></a>A format for writing less formal, low-ceremony use cases</li>
	<li> <a id="Symphonic Score" name="Symphonic Score"><strong>Symphonic score:
	</strong></a>A format for writing more formal, high-ceremony use cases</li>
	</ul>
	<h4>Actor-Goal list </h4>
	<p> <strong>Context: </strong>You have identified your actors and are trying to
	identify use cases. </p>
	<p> <strong>Problem:</strong> Developing a set of use cases in an ad hoc manner
	can lead to unnecessary work, missing features, and feature creep. Weight
	is one of the most important factors in space flight &#8212; so important that
	the United States space agency, NASA, will not
	allow anything on a spacecraft that isn’t absolutely critical to the flight.
	If something literally isn’t worth its weight, then it doesn’t go. Likewise,
	each use case adds cost to a system; therefore, you need to be sure to include
	only those use cases that add some kind of value to your collection. </p>
	<p> <strong>Forces:<em> </em></strong></p>
	<ul>
	<li>
	<p><strong>Simply listing actors or listing goals is not informative enough,
	but actors and goals together are informative.</strong> The classical approach
	to writing use cases is to define a list of actors, then find use cases
	for each. A variation on this theme is to itemize what the system must accomplish.
	Yet, neither approach is adequate by itself. You need to know both who is
	using the system and why they are using it. Otherwise, you introduce the
	potential of either feature creep or missed features. At the least, a set
	of use cases should describe this association. </p>
	</li>
	<li>
	<p><strong> A quick overview of the entire project structure is sufficient
	and necessary early in the use case development cycle.</strong> Ideally,
	this overview should be as short as reasonably possible. It must contain
	key information as to who requires each service and why they need it. Most
	other information is not very useful at this stage of the project, because
	it runs the risk of quickly becoming obsolete, as well as discouraging
	out-of-the-box (innovative) thinking. An overview
	helps the writers work through the entire set from a high-level view, expanding
	some use cases, eliminating others, and combining still others into a more
	logical grouping. </p>
	</li>
	<li>
	<p><strong>You need to be able to expand each to a full use case on demand.
	</strong>A <em>seedling</em><strong> </strong>use case forms the basis for
	a full use case later in the iterative development cycle. Each seedling
	use case needs to convey enough information so that someone, possibly other
	than the outline writer, can easily go back and expand it into a more informative
	use case. </p>
	</li>
	</ul>
	<p> <strong>Solution: </strong>Build an Actor-Goal list,
	which is a list of actors and their goals that
	gives you an overview of entire project needs.<strong></strong></p>
	<ul>
	<li>
	<p>Start by identifying the list of actors who will use the system, and then
	identify at least one goal for each. Actors without goals indicate that
	you haven’t adequately defined the system. The actor is beyond the system’s
	scope, doesn’t belong in the system, or is part of another actor. </p>
	</li>
	<li>
	<p>Likewise, leftover goals can indicate that the system is too complex and
	you're trying to accomplish too much, or that you haven’t adequately defined
	all of the necessary actors. Carefully evaluate the leftovers to see if
	you are just overlooking some detail, or whether they don’t belong in the
	system. </p>
	</li>
	<li>
	<p>Remove unassociated actors and goals from the list. </p>
	</li>
	</ul>
	<p> Sometimes, this list may provide enough information to serve as use cases
	for very small, high-communicating, low-ceremony project teams. Usually, the
	actor goal list is the first step of identifying use cases. </p>
	<h4>
	Briefs
	</h4>
	<p> <strong>Context: </strong>You have written an Actor-Goal list that outlines
	your use cases. </p>
	<p> <strong>Problem: </strong>Relying solely on an overview to capture the important
	parts of a system’s behavior is dangerous, because it provides only high-level
	information and can easily introduce ambiguity into a system. </p>
	<p> <strong>Forces: </strong></p>
	<ul>
	<li>
	<p><strong>Although valuable, an Actor-Goal list does not clearly describe
	a system.</strong> Usually, an outline doesn’t provide enough precision
	to avoid ambiguity, which can wreak havoc on a project by leading to unnecessary
	or erroneous development. Yet, an outline is helpful, because you still
	want an overview that you can easily scan. Unfortunately, with the passing
	of time or sheer volume of work, it’s too easy to forget details
	that were obvious to you earlier.</p>
	</li>
	<li>
	<p><strong>Iterative use case development requires creating placeholders for
	expansion.</strong> To develop use cases iteratively, you start with sparse
	use cases, reorganize them, and flesh them out as the system takes shape.
	Ideally, these placeholders should be clear enough to: 1) unambiguously
	describe their role in the system, and 2) allow someone to expand the use
	case, even if they were not involved in writing them originally. </p>
	</li>
	<li>
	<p><strong>Because outlines are general by nature, do not spend a lot of time,
	energy, or money writing them. </strong>Outlines provide an inexpensive
	method of documenting complex ideas in a manner that is easy to follow,
	and they provide a mechanism for people outside of a project to understand
	the high-level concepts. While it may take
	some effort to think things through, you don’t want to waste resources describing
	your ideas. The system is still in a state of flux at this point, and it
	is too early to spend much time documenting its shifting details. </p>
	</li>
	</ul>
	<p> <strong>Solution: </strong>Write two to four sentences per use case, capturing
	key activities and key-extension handling. </p>
	<ul>
	<li>
	<p> Expand the Actor-Goal list into<strong> briefs</strong> by writing a two-
	to four-sentence use cases for each entry in the list. </p>
	</li>
	<li>
	<p>Briefly describe each use case’s main&nbsp;scenario and most important
	extensions. </p>
	</li>
	<li>
	<p> Include enough information to eliminate ambiguity for at least the main&nbsp;scenario
	of the system. </p>
	</li>
	</ul>
	<h4> Improvisational score</h4>
	<p> <strong>Context: </strong>You are operating in well-known domains or in situations
	where writing high-ceremony use cases would require all of your allotted development
	time. </p>
	<p> <strong>Problem:</strong> Writing formal, high-ceremony use cases when lesser
	detail would suffice wastes time and resources. </p>
	<p> Jazz is considered to be “musician’s music,” and jazz players are usually
	highly skilled. Many jazz musicians prefer to improvise in small, highly skilled
	teams, such as jazz quartets. To improvise effectively, the musicians must have
	a thorough understanding of the conventions that form the given musical style,
	including chord sequences, rhythmic patterns, and melodies. These conventions
	provide a basic framework for the musicians to interact as a team, while still
	allowing room for spontaneous creativity. </p>
	<p> Likewise, use cases do not always need to be specified in excruciating detail.
	A far-preferable strategy is simply to define the basic structure of what the
	developers need to implement. The use cases act as placeholders that may be
	elaborated later or simply improvised by the developer who implements the use
	case. </p>
	<p> <strong>Forces:</strong></p>
	<ul>
	<li>
	<p><strong>Briefs do not provide enough information. </strong>While useful,
	use-case briefs describe only the more significant parts of behavior. Often,
	developers need more information, especially when working in unfamiliar
	domains or in the heart of the system, where the actor has many choices
	to make and many paths to follow. Briefs do not describe all of the important
	events that can happen, nor do they describe the details that go into making
	choices along the way. </p>
	</li>
	<li>
	<p><strong>Fully elaborated use cases can be too expensive, time consuming,
	long to write, and boring to read. </strong>It
	takes a lot of time and effort to write a formal, fully descriptive set
	of use cases. Maintaining this set takes even longer. Often, a collection
	of use cases reaches the point of diminishing returns long before it is
	completely written, much less formalized. Readers often prefer shorter,
	simpler use cases over long, complicated ones, because overly detailed use
	cases can be overwhelming and, frankly speaking, quite boring. </p>
	</li>
	<li>
	<p><strong>Many groups communicate well enough to
	resolve ambiguities on the fly. </strong>While briefs may be insufficient,
	stakeholders don’t always need everything to be spelled out for them. Developers
	are usually capable of asking questions and filling out the necessary detail
	from their own domain knowledge. Many people can work with a fair level
	of ambiguity, and most organizations possess what is often referred to as
	their “core competencies.” Mature organizations with strong domain knowledge
	can survive, and even thrive, using more informal, less precise use cases.
	</p>
	</li>
	</ul>
	<p> <strong>Solution: </strong>Specify the use cases at
	a low level of precision, allowing the developers to fill in the missing details
	as necessary. The level of precision required depends on the background experiences
	of the development team. Skip the less meaningful fields on the template, and
	write the Main Scenario section as a simple paragraph.
	Describe key-extension handling in the next paragraph
	or two. Be prepared to resolve ambiguities and expand detail on the fly throughout
	the project. </p>
	<p> When you can rely upon open and frequent communication among the developers
	and customer, write the use case with less detail and precision. The developers
	can fill in the gaps by asking users or by using knowledge of the domain. However,
	the developers need a thorough understanding of the business context to be able
	to fill out the details themselves. Even the most knowledgeable developer will
	still need access to the customers and users to get answers to questions and
	clarify requirements. </p>
	<p> Ideally, the project will be structured to enable effective communication
	between the customer and the developers. Typically, this will involve having
	a small, co-located team, with the developers having easy access to the users
	throughout the project. The risk of misunderstanding can be resolved by frequent
	incremental delivery if the development organization
	has a relatively low-ceremony culture. </p>
	<p> Jazz improvisation does not always work. It can become tedious and unpleasant
	to listen to, even for the committed connoisseur.
	For this reason, you also need feedback from the audience to determine the success
	of the improvisations. Multi-level or two-tier reviews are critical to success
	(see <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/effective_req_reviews,_E-dPIL-GEdqb7N6KIeDL8Q.html" guid="_E-dPIL-GEdqb7N6KIeDL8Q">Guideline:
	Effective Requirement Reviews</a>). </p>
	<p> Improvisation may not always be suitable for the organizational culture, a
	full <strong>symphonic score</strong> may be preferable in large, high-ceremony
	teams (see section that follows). For instance,
	I once watched a conductor toss his baton away in disgust when a pianist improvised
	to such an extent that the orchestra could not follow the score. If the organization
	deems the risk of improvising to be unacceptably high, then you can specify
	the use cases with a higher level of detail and precision. You could start with
	a strategy of specifying low levels of detail and precision, and then adapt
	as necessary. </p>
	<h4> Symphonic score </h4>
	<p> <strong>Context: </strong>Writing structure for high-ceremony situations,
	such as when there are many developers or when development teams are geographically
	dispersed. </p>
	<p> <strong>Problem: </strong>Writing low-ceremony use cases for high-ceremony
	situations raises the risk of miscommunication to unacceptable levels. </p>
	<p> A conductor’s version of a symphonic score contains the music for the entire
	orchestra, as well as any accompanying vocals. The parts to be performed by
	different voices or instruments are written on a separate staff, with all of
	the staves aligned, one above another. This score specifies each note and its
	associated timing in precise detail, so that the orchestra can perform a symphony
	as the composer intended. </p>
	<p> As with use cases, a score tells the musician what to play, not how to play
	it. For most symphonies, the orchestra will not be able to meet the composer,
	so instead, they must rely upon the director to interpret the
	score and the composer's intentions. </p>
	<p> <strong>Forces: </strong></p>
	<ul>
	<li>
	<p><strong>Certain development situations and cultures require high degrees
	of formality. </strong>Some organizations operate in a highly formal manner,
	thus require a highly formal process. While this formality may not
	be desirable, it is the company's way of doing business, so things need
	to be done that way. Other organizations are highly formal because they
	do highly complex, life-critical work, where even small failures could have
	disastrous consequences. For instance, no one would feel comfortable flying
	on an airliner with an off-the-shelf, one-size-fits-all flight management
	system. </p>
	</li>
	<li>
	<p><strong>The cost of repairing miscommunication
	is high. </strong>It is easy to write vague, inadequate use cases full of
	ambiguity. Use cases can be too brief and ambiguous, or contain domain-specific
	details that may be beyond the understanding of many stakeholders. Either
	way, they provide an opportunity for a misunderstanding that leads to an
	incorrect implementation. The cost of correcting these mistakes depends
	on when they are discovered. <em>Earlier</em> is cheaper than<em> later</em>,
	especially when later means customers finding the problem in the delivered
	product. To avoid miscommunication, aim to write use cases that are general
	enough for all of the stakeholders to follow, yet precise enough for the
	developers to use when building the system. </p>
	</li>
	<li>
	<p><strong>Developers need detail for implementing steps, business rules,
	data fields, and, especially, for handling extensions. </strong>No one has
	developed a program that can take a set of use cases as input, and churn
	out a completed system. Even the best-case tools seem to require human intervention
	to flesh out details and resolve ambiguities. Similarly, developers who
	do not understand the business context or lack domain expertise may not
	be able to fully comprehend a product. In an ideal project, software developers
	would have access to the domain experts to ask questions, so they could
	fill in any areas that may have been missed (see<em> Improvisational score</em>,
	previously). But often, they do not ask. Therefore, they misunderstand the
	more complex or ambiguous use cases in the set. To develop a system correctly,
	a team needs either access to domain experts or additional information that
	describe the steps, business rules, data fields, and extension handling
	that they are implementing. </p>
	</li>
	</ul>
	<p> <strong>Solution: </strong>Specify your use cases with a high level of precision,
	explicitly filling in all of the details in the use case template, while staying
	technology-neutral. The level of precision required depends on the background
	experiences of the development team. </p>
	<p> Intuition may tell you that if some detail is good, then more must be better.
	However, be careful about falling into the trap of over-specifying details.
	It’s naive to believe that everyone who reads your use cases will be able to
	understand them. Different people may interpret the use cases differently. Prepare
	for this eventuality in your process, and avoid the tendency to over-specify
	your use cases. If you try to specify a use case in too much detail, you may
	fall into the classic analysis paralysis trap. </p>
	<p> People are often tempted to address the communication problem by trying to
	explain the business domain within the use cases. In a similar manner, they
	include too much technical detail. Succumbing to these temptations by explaining
	the business domain or including technical details is always a mistake, because
	it complicates the process and obfuscates the requirements. The reader of the
	use cases cannot distinguish the real requirements from the boring background
	information, so will soon get distracted and lose interest. Instead, include
	this information in an extra section. </p>
	<p> If you are handing over the requirements to a development team whose members
	are unfamiliar with the domain, then you will need an alternative strategy for
	teaching them the domain knowledge. </p></mainDescription>
	</org.eclipse.epf.uma:ContentDescription>