<?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>