1 / 20

Team Skill 5: Refining the Use Cases

Team Skill 5: Refining the Use Cases. Lecture 11. Advantages of Use Cases. They are easy to write Written in users language Provide cohesive, related threads of behavior or scenario that is understood by both sides They link design and implementation activities

vladimir-turner
Download Presentation

Team Skill 5: Refining the Use Cases

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Team Skill 5: Refining the Use Cases Lecture 11

  2. Advantages of Use Cases • They are easy to write • Written in users language • Provide cohesive, related threads of behavior or scenario that is understood by both sides • They link design and implementation activities • Use case are supported by tools thus helps in visualizing complex systems • Scenarios can be used for test script or validation

  3. When to use Use cases • When system is functionality oriented and many types of users • Implementation in UML and OO methods.

  4. When not to use Use Cases • System with few or no users and minimal interfaces • System dominated by NFR and design constraints

  5. Redundancy Problem • Use cases are very similar yet distinct enough to require separate expression • We can use generalization, extends and includes relationship to reduce redundancy. • Adds complexity so keep it to a suitable level.

  6. Refining Use cases • Keeping use cases abstract enough during elicitation process. • To add detail and specificity at this time • Use Case: “ A use case is a description of a set of actions, including variants, that a system performs that yields an observable result of value to a particular actor”

  7. Concepts in Definition • Variant • A set of actions • System performs • An observable result of value • A particular actor

  8. How Use Cases Evolve • At time of vision document only architecturally significant use cases were defined. • Now all use cases are detailed to a level of specificity suitable to derive design and implementation. • It is not hierarchical division rather it is searching for more and more actor interactions within the system

  9. Scope of Use Case • Example: press button, get receipt • Keep it in one use case rather than two as you may want the two actions to be performed together as you would • Test them together • Change them together • Write the together • Manage them as a unit

  10. A Modern SRS

  11. On Ambiguity and Specificity • Depends on Application • Varies from time to time • To find the sweet spot • "sweet spot" is the balance point of the greatest amount of understandability and the least amount of ambiguity

  12. Techniques for Disambiguation • Memorizations heuristic • Keyword technique • Emphasis technique • Other techniques

  13. Memorizations heuristic • Ask several individuals, both from the development group and from the user/stakeholder group, to try recalling, from memory the customer's real requirement. Parts that are not clear and cannot be easily remembered are likely to be the most ambiguous. Focus on them and try to restate them with more clarity so they can be remembered.

  14. Keyword technique • As illustrated with Mary's lamb, it often helps to identify the key operational words in a statement and to list all their definitions, using an authoritative source that the various members of the project environment will accept. Then mix and match the definitions to determine different interpretations, as we did with Mary and her lamb. As a quick test of this technique, you may also note that interpretation 1(a) and 1(a) above, "Mary held in possession a little sheep less than one year old or without permanent teeth," is probably closest to the meaning in the nursery rhyme.

  15. Emphasis technique • Read the requirement aloud and emphasize individual words until as many different interpretations as possible have been discovered. If only one of the interpretations is correct, restate the requirement appropriately; if multiple interpretations are correct, additional requirements may need to be generated accordingly. We'll illustrate this point with another investigation of Mary and her lamb below.

  16. Saying the sentence aloud and emphasizing individual words might help us elicit any one of the following. • Mary had a little lamb; if this is the case, perhaps the user is telling us that it was Mary's lamb, not Richard's or anyone else's. • Mary had a little lamb; perhaps she no longer has it. Perhaps it's the tense of the statement that's significant. • Mary had a little lamb; thus, the key point may be that Mary had only one lamb, not an entire flock. • Mary had a little lamb; indeed, it was one of the littlest lambs you ever saw. • Mary had a little lamb; the emphasis here reminds us that Mary didn't have a pig, a cow, or even a grown-up sheep. Nevertheless, we might still be misled into thinking she had a baby antelope.

  17. Other Techniques • If appropriate, try using pictures, graphics, or formal methods to flush out the ambiguity and eliminate it.

  18. Recommendations • Use natural language where ever possible • Use pictures and diagrams to further illustrate the intent • When in doubt ask! When you’r not in doubt, consider asking any way • Augment your specifications with more formal methods when you cannot afford to misunderstood.

  19. Quality Measures of Software Requirements • Correct • Unambiguous • Consistent • Ranked • Verifiable • Modifiable • Traceable • understandable

  20. THE END ANY QUESTIONS? THANK YOU

More Related