Medical document from higwqyd

2. 2
Team Skill 3 -
Defining the System
Lec 10

3. 3
Outline – Skill 3
 Use Cases
 Organizing Requirements
 Vision Document
 Product Management

4. 4
Use Cases

5. Key Points
 Use cases carry the majority of the
requirements for the system.
 The development team, with user
involvement, writes the use cases.
 Use cases are built on a common, standard
format.
 Use cases later drive test case development
5

6. Benefits of Use Cases
 Easier to write and read
 Force developers to think from the user perspective
 Use cases engage the users in the requirements process
 Use cases provide a sequence of actions
 Help to understand what the system needs to do and how it
might go about doing it
 Use cases carry over directly into the testing process
 Use cases serve as inputs to the user documentation
6
Use cases simply tell a better requirements story
So, Use these

7. 7
What is a Use Case?
 Definition: A use case describes sequences
of actions a system performs that yield an
observable result of value to a particular
actor: -
 Sequences of actions
 System Performs
 Observable result of value to a particular actor
 Particular Actor

8. Actors
 Definition: An actor is someone or something
that interacts with the system
 Type of Actors: -
 Users
 Other systems or applications
 A device
8

9. Flow of events
 The heart of the use case is the event flow, usually a textual
description of the interactions between the actor and the
system.
 The flow of events can consist of both:
 the basic flow, which is the main path through the use case,
and
 alternate flows, which are executed only under certain
circumstances
9

10. 10
Use Case Model - Development Steps
1. Identify the actors
2. Identify the use cases
3. Identify actor/use case relationships
4. Outline use cases
5. Refine use cases

11. Use cases for the Homeowner/Programmer
actor
11

12. 12
3. Identify Actor/Use Case Relationships
 Draw a diagram showing relationships
between actors and use cases
Eat food
Buy food
Parent Child

13. 13
4. Outline Use Cases
 Describe sequence of events in basic flow
(sunny day scenario)
 Describe sequences of events in alternate
flows (rainy day scenarios)

14. 4. Outline Use Cases - Questions
 Basic flow:
 What event starts the use
case?
 How does the use case end?
 How does the use case
repeat some behavior?
 Alternate flow:
 Are there optional situations in
the use case?
 What odd cases might happen?
 What variants might happen?
 What may go wrong?
 What may not happen?
 What kind of resources can be
blocked?
14

15. 15
5. Refine Use Cases
 At some point later in the project lifecycle you will
refine the use cases to the next and last level of
detail.
 At that time, there are a number of additional
factors to be considered, such as: -
 Describe All alternate flows, including exception
conditions
 Describe pre-conditions / post-conditions
 Fill in special requirements

16. Use Case Anatomy
16
See Appendix C for fully elaborated use-case specification template

17. 17
Microwave Example
User
Cook Food

18. 18
Cook Food Use Case – Slide 1 of 4
A. Name: Cook Food
B. Brief description: User places food in microwave
and cooks it for desired period of time at desired
power level.
C. Actors: User

19. 19
Cook Food Use Case – Slide 2 of 4
D. Basic flow:
1. User opens door and places food in unit
2. User enters time for cooking
3. User pushes start button
4. Unit cooks food
5. Unit beeps

20. 20
Cook Food Use Case – Slide 3 of 4
E. Alternate flows
1. User cancels time before starting
2. User cancels cooking before finished
3. User selects reduced power level before pushing start
button

21. 21
Cook Food Use Case – Slide 4 of 4
F. Pre-conditions
 Unit is plugged in
 Unit is in ready state
G. Post-conditions
 Food is cooked or user cancelled operation
H. Special requirements
 Timer should display remaining time to finish while
cooking
 Default power setting should be "high"

22. 22
Cook Food Use Case – Slide 4 of 4
F. Pre-conditions
 Unit is plugged in
 Unit is in ready state
G. Post-conditions
 Food is cooked or user cancelled operation
H. Special requirements
 Timer should display remaining time to finish while
cooking
 Default power setting should be "high"

23. 23
Organizing Requirements

24. Key Points
 For nontrivial applications, requirements must
be captured and recorded in a document,
database, model, or tool.
 Different types of projects require different
requirements organization techniques.
 Complex systems require that requirements
sets be developed for each subsystem.
24

25. 25
Organization Techniques
 Requirements can rarely be defined in a single
monolithic document or in a single use-case model.
 There may be no of reasons: -
 The system may be very complex
 The system being constructed may be a subsystem of a
larger system and may satisfy only a subset of all the
requirements identified
 Marketing and business goals need to be separated
from the detailed product requirements
 Other requirements, perhaps regulatory or legal, may
be required to be documented elsewhere

26. 26
Organization Techniques
 The system design process itself creates new classes
of requirements, when subsystem are defined.

27. 27
Organization Techniques
 Once these requirements are agreed on, system design is
performed again, if necessary, by breaking down each of the
subsystems into its subsystems and developing requirements
for each.

28. 28
Organization Techniques
 Once these requirements are agreed on, system design is
performed again, if necessary, by breaking down each of the
subsystems into its subsystems and developing requirements
for each.

29. 29
Organization Techniques
 As seen, the lowest-level systems, that is, those that are not
further decomposed, usually correspond to software-only or
hardware-only subsystems

30. 30
The Vision Document

31. Key Points
 Every software project will benefit from having a Vision
document.
 The Vision document describes the application in general
terms, including descriptions of the target market, the system
users, and the application features.
 The Vision document defines, at a high level of abstraction,
both the problem and the solution.
 The Delta Vision document focuses on what has changed
31

32. Scope of Vision Document
 The Vision document captures the needs
of the user, the features of the system,
and other common requirements for the
project.
 As such, the scope of the Vision
document extends over the top two
levels of the requirements pyramid,
thereby defining at a high level of
abstraction both the problem and the
solution
32

33. 33
Vision Document Template
1. Introduction
2. User Description
3. Product Overview
4. Feature Attributes
5. Product Features
6. Exemplary Use Cases
7. Other Product Requirements
8. Documentation Requirements
9. Glossary
See the Detailed version of Vision Document from the Text

34. The Delta Vision Document
 Keeping the Vision document understandable and
manageable is an important team skill.
 To assist in this process, it is helpful to keep the Vision
document as short, concise, and "to the point" as possible
 However, in future releases, you may discover that it is
counterproductive to repeat features that have been
incorporated in prior releases
 Delta Vision document, addresses these issues
34

35. The Delta Vision Document
35

36. END
36