1. 1. Base concepts
1.1. 1. Actors
1.1.1. Anything having behaviour
1.1.2. Role
1.1.3. 4 types
1.1.3.1. System under discussion/design (SuD)
1.1.3.2. Subsystems of SuD as internal actors
1.1.3.2.1. As white box for business-lvl
1.1.3.2.2. Rare as opening black SuD box at tech-lvl
1.1.3.3. Primary actor
1.1.3.3.1. External
1.1.3.3.2. One who initiates the astion is not one with goal
1.1.3.3.3. To whom US bring value
1.1.3.4. Secondary actor
1.1.3.4.1. External actor who provides a service to the SuD
1.1.4. Important/unimportant
1.1.4.1. Imp before requir-ts gathering and before delivery
1.1.4.2. Brainstorm actors = B-rm goals
1.1.4.3. While developing UC - not so imp.
1.1.4.4. Prime. act can include few: PA Clerk inc. Manager (i.e. Man-r can impl-nt Clerk's funcs) => subtypes => PA as a template
1.1.4.5. before delivery again important - partition of system, security lvls, training curriculum
1.2. 2. Stackeholders
1.2.1. Interested in beh-r of US even do not interact directly
1.2.2. PA is a SH
1.2.3. UC as form of contract in which some SH interest can conflict => acceptable for all SH
1.2.4. The behavior of the SuD must protect the interests of the SH who are not present to defend their interests themselves
1.3. 3. Actor list
1.3.1. 2 parts: Name&Characterization
1.4. 4. Design scope
1.4.1. functional scpoe
1.4.1.1. What funcs you choose to deliver or not
1.4.1.2. Way to manage - goal list
1.4.1.3. In/out of scope, m.b. next release
1.4.2. design scope
1.4.2.1. divide into 3 scopes:
1.4.2.1.1. Corporate - entire company under discu-n delivering goal of an external actor
1.4.2.1.2. System - piece of hardware/software you are charged with building
1.4.2.1.3. Subsystem - means that you have opened up the system that is the main one being designed or discussed
1.4.2.2. Try to write al least 1 corporate UC
1.5. 5. Actors&Goals model
1.5.1. basic model of use cases is that of actors having goals against other actors
1.5.2. A use case is a description of the possible sequences of interactions between the system under discussion and its external actors, related to a particular goal
1.5.3. discover PA goal failiure - highlight goal failiure and failure response
1.5.4. Try to describe situations in future => conditions
1.6. 6. Stakeholders & Interests model
1.6.1. use case represents an agreement between the stakeholders in a system about its behavior
1.6.2. use case shows the different ways in which the actors act to either achieve the interests of each stakeholder, or fail in an agreeable fashion, under a specific triggering condition
1.6.3. The key points to remember are simply that: · the primary actor is just one of the stakeholders, · the use case shows how all the interests of the stakeholders are satisfied or protected, · every step in the scenario has to do with a stakeholder's interest.
1.7. 7. Goal levels
1.7.1. User-goal level UC
1.7.1.1. The tests for a user-goal usually are: · Is it done by one person, in one place, at one time (2-20 minutes)? · Can I go to lunch as soon as this goal is completed? · Can I ask for a raise if I do many of these?
1.7.2. Strategic UC
1.7.2.1. They serve three purposes in the describing the SuD: · showing the context in which the system services must function, · showing life-cycle sequencing of related goals, · providing a table of contents for the lower-level use cases (both lower-level white use cases and blue use cases).
1.7.3. High - lvl UC
1.7.3.1. Too many blue UC (UG-lvl), don't forget about white UC (Strat-lvl)
1.7.4. UC levels
1.7.4.1. black = no more expanding
1.8. 8. Actor-goal list
1.8.1. 3 coumns
1.8.1.1. actor
1.8.1.2. task-level goal
1.8.1.3. priority
1.9. 9. Precondition, success end condition, failure protection
1.9.1. Precondition
1.9.1.1. The Precondition is written as simple assertions about the state of the world at the moment the use case opens
1.9.1.2. Ex: The user is logged on
1.9.1.3. Put into the Precondition things that the system can guarantee are true.
1.9.1.4. No pass/fail tests - we consider system guarantees preconditions are true
1.9.2. Success end condition
1.9.2.1. States what interests of the stakeholders have been satisfied at the end of the use case
1.9.2.2. Ex: Success End Condition: The file is saved.
1.9.2.3. Pass/Fail test for the Success End Condition: Each of the stakeholders in the use case would agree, from reading the success end condition, that their interests had been satisfied for this goal of the primary actor
1.9.3. Failure protection condition
1.9.3.1. Ex: Protected Protection Condition: No order has been initiated if no payment was received.
1.10. 10. Main success scenario
1.10.1. May not be the only scenario, but others as extentions
1.10.2. The main success scenario consists of actions, as discussed in the Stakeholders & Interests Model
1.10.3. The main success scenario is the most common, or perhaps easiest to understand, scenario.
1.11. 11. Overall writing style
1.11.1. Core form
1.11.1.1. At the core of the writing is the form: "At time z, actor y does x to actor w with data v"
1.11.1.2. OR Actor1 verbs actor2 with some data
1.11.1.3. Validation: "The system verifies that the something meets some criteria."
1.11.1.4. State change: "The system changes the something to reflect something."
1.11.2. Key characteristics of an action step
1.11.2.1. The sentence shows the process moving distinctly forward.
1.11.2.2. Be clear, "Who's got the ball"
1.11.2.2.1. Who is the last acting person
1.11.2.3. Write from a bird's eye point of view
1.11.2.4. "Verify", don't "check"
1.11.2.5. The sentence shows the intent of the actor, not their particular movements in accomplishing that intent (semantics, not dialog)
1.11.2.6. Mentioning the timing is optional
1.11.2.7. Idiom: "User has System A kick System B"
1.11.2.8. Idiom: "Do steps x-y until condition"
1.11.3. How much fits into one step?
1.11.3.1. Don't use style actor - system - actor
1.11.3.2. it may be actor - system - system - system but system steps have to be separated logicaly (e.g. validation, internal actions and response)
1.11.4. Numbering and writing notes
1.11.4.1. Better to use numbering
1.11.5. Sample steps
1.11.5.1. Cockburn style
1.11.5.1.1. Most of the examples in this book are in my preferred style, which is: · one column of plain prose, · numbered steps, · no "if" statements, · the numbering convention in the extensions sections involving combinations of digits and letters (e.g., 2a, 2a1, 2a2 and so on).
1.11.5.1.2. As picture
1.11.5.2. Other styles sucks
1.11.5.3. UML UC diagram
1.11.5.3.1. packaging and decomposition of the use cases, not their content
1.11.5.3.2. producing a monster diagram that shows the entire decomposition of behavior
1.12. 12. Extention conditions
1.12.1. Brainstorm conceivable failiures and alternative courses
1.12.1.1. Consider all possible ways in which scenario would fail
1.12.1.2. Common fail cases
1.12.1.2.1. PA sending bad data or requests
1.12.1.2.2. Validation fail
1.12.1.2.3. Non or failure response from SA-rs
1.12.1.2.4. Inaction of PA (timeout)
1.12.1.2.5. Bad data
1.12.1.2.6. Critical performance failures of the SuD
1.12.1.3. Consider alternate success paths
1.12.1.4. About fails: Your list should be longer than you will eventually use, cut it later
1.12.1.5. About fails: You list will not be complete, even though you try.
1.12.2. Rationalize and reduce the extentions list
1.12.2.1. Only failures you can detect
1.12.2.2. Exclude failures that are merely incorrect performance of the SuD
1.12.2.2.1. Like jammed recipient slot of ATM
1.12.2.3. Where the internal failure is considered critical, be sure to include an explicit validation for the success of the action
1.12.2.3.1. In the case of "ATM issues cash", the ATM has a specific check to make sure the cash actually came out of the slot.
1.12.2.4. Include internal failures that have an effect that reaches the outside world
1.12.2.4.1. Bad data in the database is a standard example. Power failure is another.
1.12.2.5. Include bad behavior of the external actors, since the system cannot control their actions
1.12.2.6. Consider timeouts, in particular
1.12.2.6.1. What happens if the primary actor walks away, or the secondary actor never replies?
1.12.2.7. Include any condition that requires the system to do something to protect an interest of a stakeholder. Exclude any condition that does not require the system to react
1.12.3. Writing style
1.12.3.1. Write the condition as a phrase saying what is wrong or different here, compared to the main success scenario.
1.13. 13. Failure repair and roll-up
1.13.1. Failures and success alternatives
1.13.1.1. For each extension condition, write how to deal with the alternative success path, or how to patch up the failure, either succeeding with the goal, or abandoning it
1.13.1.2. 3 main scenarios
1.13.1.2.1. The step that failed has been patched up, so that at the end of the extension writing, the story is exactly as though the step had not failed
1.13.1.2.2. The failure condition you indicated was preventing the step from happening, so, after the extension writing, the story starts up again at the beginning of that step
1.13.1.2.3. The use case must abort due to total failure
1.13.2. Failures within failures
1.13.2.1. No problem - 1 more level of cases
1.13.2.2. Create new UC - high cost, so be careful
1.13.3. Failure roll-up
1.13.3.1. low-level failurs roll-up into high level
1.13.3.2. Usually, the calling use case often contains only one failure condition for many lower-level failures. This is "rolling up" the failures
1.13.3.3. Picture
1.13.3.3.1. The right leg corresponds to all ways of failing to achieve the goal. Each stripe corresponds to one scenario. Some scenarios end with success, some end with failure.
1.14. 14. Technology or Deferred Variations
1.14.1. Few ways to success
1.14.2. Example: 1. Customer identifies self, bank and account #. 2. ... ... Technology variations 1a. Customer identification is done with one of - bank card and PIN - eye scan - fingerprint
1.14.2.1. This puts in a marker that at some point, we might write a use case "Identify customer with bank card".
1.15. 15. Linking to other UC
1.15.1. In the purely textual style of use case described in this book, every goal phrase is a potential reference to another use case. In UML terms, every step potentially "includes" another use case. As just described in the previous section, any step can be made into a use case, any use case can be included directly within another. This is one of the attractions of the goal-based use case model.
2. Quotations (c)
2.1. I have never seen a well-written use case with more than 11 steps in the main success scenario
3. 0. Intro
3.1. 1. A Plausible Requirements File Outline (List)
3.1.1. Chapter 1. Purpose and scope 1a. What is the overall scope and goal? 1b. Stakeholders (who cares?) 1c. What is in scope, what is out of scope Chapter 2. The use cases 2a. The primary actors and their general goals 2b. The business use cases 2c. The system use cases Chapter 3. The terms used / Glossary Chapter 4. The technology to be used Q1. What technology requirements are there for this system? Q2. What systems will this system interface with, with what requirements? Chapter 5. Other various requirements 5a. Development process Q1. Who are the project participants? Q2. What values will be reflected in the project (simple, soon, fast, or flexible)? Q3. What feedback or project visibility do the users and sponsors wish? Q4. What can we buy, what must we build, what is our competition to this system? Q5. What other requirements are there on the development process (e.g. testing, installation)? Q6. What dependencies does the project operate under? 5b. Business rules 5c. Operations, security, documentation 5d. Use and usability 5e. Unresolved or deferred 5f. Maintenance and portability Chapter 6. Human backup, legal, political, organizational issues Q1. What is the human backup to system operation? Q2. What legal, what political requirements are there? Q3. What are the human consequences of completing this system? Q4. What are the training requirements? Q5. What assumptions, what dependencies are there on the human environment?
3.2. 2. Use-case as behavioral hub => details as spokes
3.3. 3. Your use case is not MY use case
3.4. 4. 4 stages of UC writing:
3.4.1. 1. Actors&Goals
3.4.2. 2. Main Success Scenarios + stakeholders & trigger
3.4.3. 3. Failure conditions- no handling
3.4.4. 4. Failure handling
3.5. 5 Not all US in the same way
3.5.1. high lvl (strict) Vs low lvl (agile)
3.5.2. 2 templates - "casual" vs "fully dressed"
4. 2. Related concepts
4.1. 1. All UC together
4.1.1. All the use cases together make up an ever-unfolding story about the system
4.1.2. How can you tell when you are done writing all the use cases? The answer is, when you have identified all the primary actors, and all their "blue" goals, and written all the blue use cases, along with the strategic and subfunction use cases needed to support them.
4.1.3. An executive can read the top levels of the story, and stop reading at any point
4.2. 2. Business process modeling with UC
4.2.1. Business process modeling with UC
4.2.1.1. The business process starts with an external actor who views your organization as a system that offers a service
4.2.1.2. The business use case, then describes how the business or organization responds to a triggering event, to satisfy to the goal of an external actor and the interests of the stakeholders. It is written exactly as any use case
4.2.2. Relating business and system UC
4.2.2.1. The ever-unfolding story can start in the business use cases and continue to unfold, naturally, in the system use cases
4.2.2.2. Be careful with crossing business and system levels. If doing this realize that you changing level
4.2.2.3. How can you help reduce the mistaken confusion of business and system use cases? Firstly, and always, mark both the scope and level in the use case template, read them both and train your readers to read them both at the start of every reading.
4.2.2.3.1. Also you can use differently shaped templates for business and system UC
4.2.2.3.2. Or attach graphic logo indicating scope and level
4.2.3. Designing business to system use cases
4.2.3.1. Core business requirements
4.2.3.1.1. Ultimate core of your business
4.2.3.1.2. What's next?
4.2.3.2. Business operations model in use cases
4.2.3.2.1. If you are not reinventing the organization, then you can go straightaway to describing the way the business works using use cases
4.2.3.2.2. Either way, document the business process as use cases, using the same form and rules as any other use case. Treat the outermost containing system (the company or overall organization) as a single, black box, initially.
4.2.3.2.3. After you have the use cases for the organization as a black box, open up the black box, and write "white-box" business use cases (described in the next chapter). These show your business process design, the interactions of the players in the organization.
4.2.3.2.4. Next:
4.3. 3. White-box use cases
4.3.1. The two times most common times when white-box use cases are written are: 1. Writing use cases describing business processes, prior to reengineering the business or as a contextual part of writing system requirements. 2. Using the use case form to document the design of a system.
4.4. 4. The Missing Requirements
4.4.1. UC do not contain information such as performance requirements, business rules, user interface design, data descriptions, finite state machine behavior, priority, and probably some other information
4.4.2. Several ways to extend UC scope:
4.4.2.1. 1. Simply attach required info to UC
4.4.2.2. 2. Spreadshit which connects UC name with priority, complexibility estimation, planned release etc.
4.4.2.3. 3. UC as a hub connecting few representation of business process
4.4.2.3.1. Picture
4.4.3. Data descriptions
4.4.3.1. A lot of notations in UC need to be strictly defined
4.4.3.2. 3 levels of information
4.4.3.2.1. Information nicknames - the first level of precision
4.4.3.2.2. Field lists - the second level of precision
4.4.3.2.3. Field details & checks - the third level of precision
4.4.3.2.4. Mantra
4.5. 5. Parametrized UC
4.5.1. Naming a goal in a step is like a subroutine call
4.5.2. Find user/customer/goods => Find Whatever
4.6. 6. UML & the relations Includes, Extends, Generalizes
4.6.1. Write text-based use cases instead
4.6.1.1. Fancy relations come naturally when simply write an unfolding story
4.6.2. Includes
4.6.2.1. A "base" use case "includes" another if it names it in an action step
4.6.2.2. This is the normal and obvious relationship between a higher-level use case and a lower-level use case
4.6.2.3. An arrow goes from the base use case to the included use case, signifying that the base use case "knows about" the included one.
4.6.3. Extends
4.6.3.1. Extending use case is like as a "patch" on the base use case
4.6.3.2. Like extention UC
4.6.3.3. An arrow goes from the extending use case back to the base use case, signifying that the extending use case "knows about" the base use case
4.6.4. Generalizes
4.6.4.1. A lower level use case may "specialize" a higher-level use case.
4.6.4.2. Good test phrases for any "generalized" concept is "generic", or "some kind of"
4.6.4.3. In UML notation, an arrow goes from the specialized use case back to the general use case
4.6.4.4. Can be done in 2 ways: few incude relation from or 1 include and few generalize
4.7. 7. Mapping to UI, design tasks, design, and test
4.7.1. UC to UI
4.7.1.1. It's beneficial to paste a snapshot of the designed GUI into the use case, at the bottom, so that readers can see what design is being nominated
4.7.2. UC to detailed requirements
4.7.2.1. Break UC to feature (US)
4.7.3. Use cases to test cases
4.7.3.1. The use cases provide a ready-made functional test suite for the system
4.8. 8. CRUD use cases
4.8.1. Create, Replace, Update, Delete
4.8.2. My personal tendency is to write "Manage X", to get the advantage of less clutter, unless it turns out not to work well for some reason, usually related to the complexity of the writing, and only then break it out into "Create X", "Update X", "Delete X".
4.9. 9. A Metamodel for Use Cases
4.9.1. An actor is a stakeholder
4.9.1.1. Model
4.9.2. Behavior
4.9.2.1. Model
4.9.3. Use case as contract
4.9.3.1. Model
4.9.4. Interactions
4.9.4.1. Model
5. 3. Reminders
5.1. 1. Recipe for writing UC
5.1.1. Step 1: Find the boundaries of the system (Context diagram, In/out list). Step 2: Brainstorm and list the primary actors. (Actor List) Step 3. Brainstorm and list the primary actors' goals against the system. (Actor-Goal List) Step 4. Write the outermost strategic level use cases covering all the above. Step 5. Reconsider & revise the strategic use case. Add, subtract, merge goals. Step 6. Pick a goal / use case to expand. Optionally, write a system-in-use story to become acquainted with the story of the use case. Step 7. Fill in the stakeholders and interests, the preconditions, the success end conditions, the failure protection. Double the goals and interests against those conditions. Step 8. Write the main success scenario for the use case. Double check it against the stakeholders' interests. Step 9. Brainstorm and list the possible failure conditions. Step 10. Write how the actors and system should recover from each failure. Step 11. Break out any sub-use case that needs its own space. Step 12. Start from the top and readjust the use cases. Add, subtract, merge. Double check for completeness, readability, failure conditions.
5.2. 2. Quality Matters
5.2.1. Quality within one UC
5.2.1.1. Pass/Fail Tests
5.2.1.1.1. Use case title. Is the name an active-verb goal phrase, the goal of the primary actor? 2. Use case title. Can the system deliver that goal? 3. Scope and Level: Are the scope and level fields filled in? 4. Scope. Does the use case treat the system mentioned in the Scope as a black box? (The answer may be 'No' if the use case is a white-box business use case, but must be 'Yes' if it is a system requirements document). 5. Scope. If the Scope is the actual system being designed, do the designers have to design everything in whatever is mentioned in the Scope, and nothing outside it? 6. Level. Does the writing of the steps match the goal level stated in Level? 7. Level. Is the goal really at the level mentioned? 8. Actor. Does it have behavior? 9. Primary actor. Does it have a goal against the SuD that is a service promise of the system? 10. Preconditions. Writing varies by hardness and tolerance, per project, but the questions is: Are they mandatory, and can they be ensured by the SuD? 11. Preconditions. Is it true that they are never checked in the use case? 12. Stakeholders and interests. (Usage varies by hardness and tolerance) Are they mentioned? 13. Success end condition. Are all stakeholders interests satisfied? 14. Failure protection. (Usage varies by hardness and tolerance) If present, are all the stakeholders' interests protected? 15. Main success scenario. Does it run from trigger to delivery of the success end condition? 16. Main success scenario. Is the sequence of steps right (does it permit the right variation in sequence)? 17. Main success scenario. Does it have 2 - 11 steps? (You may run across a use case that really has more, but I'll bet that if you merge steps and raise goal levels, your shorter version will be easier to read). 18. Each step in any scenario. Is it phrased as an goal that succeeds? 19. Each step in any scenario. Does the process move distinctly forward after successful completion of the step?
5.2.1.1.2. 20. Each step in any scenario. Is it clear which actor is operating the goal (who is "kicking the ball?) 21. Each step in any scenario. Is the intent of the actor clear? 22. Each step in any scenario. Is the goal level of the step lower than the goal level of the overall use case? Is it, preferably, just a bit below the use case goal level? 23. Each step in any scenario. Are you sure the step does not describe the user interface design of the system? (It might, if that is the purpose of the use case). 24. Each step in any scenario. Is it clear what information is being passed? 25. Each step in any scenario. Does the step "validate" a condition, as opposed to "checking" a condition? 26. Extension condition. Can and must the system detect it? 27. Extension condition. Must the system handle it? 28. Technology or Deferred Variation. Are you sure this is not an ordinary behavioral extension to the main success scenario
5.2.1.2. Making the UC easier to read
5.2.1.2.1. 1. Keep matters short and too the point. Long use cases make for long requirements files, which few people enjoy reading. 2. Start from the top and create a story line. The top will be a strategic use case. The task-level, and eventually, subfunction-level use cases branch off from here. 3. Give the use cases names that are short verb phrases, naming the goal to be achieved. 4. Start from the trigger, continue until the goal is delivered or abandoned, and the system has done any bookkeeping it needs to, with respect to the transaction. 5. Write full sentences with active verb phrases that describe the sub-goals getting completed. 6. Make sure the actor is visible in each step. 7. Make the failure conditions stand out, and their recovery actions readable. Let it be clear what happens next, preferably without having to name step numbers. 8. Put alternative behaviors in the extensions, rather than in "if" statements. 9. Use "includes" relationships between use cases whenever possible.
5.2.2. Quality across UC set
5.2.2.1. 1. Does the list of user goals capture all the services all the primary actors want from the system? 2. Do the use cases form a story that unfolds from highest level goal to lowest? 3. Is there a context-setting, highest level use case at the outermost design scope possible for each primary actor?
5.2.3. Know the cost of mistakes
5.3. 3. A bad UC is still a good UC
5.3.1. You can make two mistakes with a use case - writing too little, or writing too much. Please write too little.
5.3.2. They put so little into each use case that they called them "stories" rather than use cases, and wrote them on single cards.
5.4. 4. Just chapter two.
5.4.1. Use cases are only a small part of the total requirements gathering effort, perhaps "chapter 2" of the requirements document or file
5.5. 5. An ever-unfolding story
5.5.1. There is one, top level use case called something like "Use the ZZZ system". This use case is little more than a table of contents that names the different outermost actors and their highest-level goals.
5.5.2. White -> Blue -> Indigo -> Black (optional)
5.6. 6. Breadth first, low precision
5.6.1. Work breadth first, not depth first
5.6.2. Picture
5.6.3. 1. Primary actors. Collecting all the primary actors is the first step in getting your arms around the entire system for a brief while. Brainstorming these actors will help you get the most goals on the first round.
5.6.4. 2. Goals. Listing all the goals of all the primary actors is perhaps the last chance you will have to capture the entire system in one view.
5.6.5. 3. Main success scenario. This tells the story of what the system delivers.
5.6.6. 4. Failure / Extension conditions. The writers can take a break from writing and know, when they come back, where they are and what needs to be done
5.6.7. 5. Recovery steps. These are built last of all the use case steps, but surprisingly, new user goals, new actors, and new failure conditions are often discovered during the writing of the recovery steps
5.6.8. 6. Field lists.
5.6.9. 7. Field details & checks.
5.7. 7. Just one sentence style
5.7.1. a sentence in the present tense,
5.7.2. with an active verb in the active voice, describing
5.7.3. an actor successfully achieving a goal that moves the process forward.
5.7.4. Ex.: "Customer enters card and PIN."
5.8. 8. Clear intentions, goal in sight.
5.8.1. Reread the sentence you just wrote, and make sure the goal really is in sight, and it really is the goal of the actor.
5.9. 9. Who's got the ball?
5.9.1. Remember to write from the point of view of a bird up above, watching and recording the scene.
5.10. 10. Satisfy the stakeholders
5.10.1. Write the Success End Condition. This should be fairly obvious text, but writing it specifically with regard to all the stakeholders sometimes turns up a missing element.
5.11. 11. User goals and level confusion.
5.11.1. Find the blue goal
5.11.1.1. Business process modeling people call it an "elementary business process". I call it the "user's goal".
5.11.1.2. A blue, or user-goal, or elementary business process level
5.11.1.3. Levels
5.11.1.4. How Vs Why
5.11.2. Merge steps, keep asking "why"
5.11.2.1. Most well-written use cases I have seen had between 3 and 8 steps.
5.11.3. Label each use case
5.11.3.1. Once the use case is labeled, then you can check:
5.11.3.1.1. whether the title or goal of the use case is appropriate for that level
5.11.3.1.2. whether the steps in the use case are appropriate steps for that level. They should be just one level below
5.12. 12. Corporate scope, system scope
5.12.1. Business
5.12.1.1. The use case is about an actor outside the organization achieving a goal against the organization
5.12.1.2. The goal level is usually user-goal or strategic
5.12.1.3. typically use case is often written in "white-box" form
5.12.1.4. described the inside of the business
5.12.2. System
5.12.2.1. scope is the (typically) computer system about to be designed
5.12.2.2. level of greatest interest is the user-goal
5.12.2.3. typically use case is almost always written in "black-box" form
5.12.2.4. describes the outside of the computer system
5.12.3. Making scope easier to discern
5.12.3.1. just write scope
5.13. 13. Actors, roles and goals
5.13.1. The first point is to recognize that a person fills many roles, that a person in a job is just a person filling a role, and that a person with a job title acts in many roles even when acting in the role of that job title.
5.13.2. The second point is to recognize that the important part of the use case is not the primary actor's name, but the goal
5.14. 14. Job titles first and last.
5.14.1. Focussing on the job titles or societal roles that will be affected by the system, allows you to brainstorm effectively and make the best first pass at naming the goals.
5.14.2. Back to titles at deployment
5.14.2.1. assign permission levels to specific users, permission to update or perhaps just read each kind of information,
5.14.2.2. prepare training materials on the new system, based on the skill sets of the people with those job titles, and which use cases each group will be using,
5.14.2.3. package the system for deployment, packaging clusters of use case implementations together.
5.14.3. Are important at the beginning and at the end
5.15. 15. Two exits
5.15.1. Every UC has 2 exits: success and failiure
5.16. 16. Preconditions, postconditions
5.16.1. Precondition
5.16.1.1. The precondition names something that you want the SuD to ensure has happened before the use case starts
5.16.2. Postcondition
5.16.2.1. Most often neglected in the use case text are logging and bookkeeping duties
5.17. 17. Use includes
5.17.1. I always use the "includes" relation between use cases
5.17.2. "Includes" simply means that in the calling use case, you name the sub-use case
5.18. 18. Core UC values and variants
5.18.1. Core valuables
5.18.1.1. Readable
5.18.1.2. Not too much energy spent
5.18.1.2.1. The first draft of the use case brings perhaps 2/3 of the value of the use case
5.18.1.3. Goal-based
5.18.1.4. Bird's eye view
5.18.1.5. Usable for several purposes
5.18.1.5.1. to provide requirements to an organization's business process redesign
5.18.1.5.2. to document an organization's business process (white box)
5.18.1.5.3. to encourage and elicit requirements from users or stakeholders
5.18.1.5.4. to specify the test cases that are to be constructed and run
5.18.1.5.5. to document the internals of a system (white box)
5.18.1.5.6. to document the behavior of a design or design framework
5.18.1.6. Black box requirements
5.18.1.7. Alternative paths after main success scenario
5.18.2. Suitable variants
5.18.2.1. Either numbered steps or simple paragraphs
5.18.2.2. Casual or fully dressed template
5.18.2.3. Full sentences or theatre-style
5.18.2.4. Prior business modeling with or without use cases
5.18.2.5. Use case diagrams or actor-goal lists
5.18.2.6. White box documentation or collaboration diagrams
5.18.3. Unsuitable variants
5.18.3.1. "If" statements inside the main success scenario
5.18.3.2. Sequence diagrams as replacement for use case text
5.19. 19.Planning around goals
5.19.1. UC planning table
5.19.1.1. Picture
5.19.2. Delivering partial UC