SE Roger S. Pressman - Requirement Model.ppt

Software Engineering Requirement Model Comprehensive Presentation

1. DEVELOPING USE CASES
UNIT II
1

2. DEVELOPING USE CASES
•A use case describes how a user interacts with the system by
defining the steps required to accomplish a specific goal
•the system’s behavior under various conditions as the system
responds to a request from one of its stakeholders
•use case tells a stylized storyabout how an end user (playing
one of a number of possible roles) interacts with the system
under a specific set of circumstances.
•The story may be narrative text, an outline of tasks or
interactions, a template-based description, or a diagrammatic
representation.
•use case depicts the software or system from the end user’s
point of view.
2

3. DEVELOPING USE CASES
Jacobson [ Jac92] suggests a number of questions that should be
answered by a use case:
1.Who is the primary actor, the secondary actor(s)?
2.What are the actor’s goals?
3.What preconditionsshould exist before the story begins?
4.What main tasks or functions are performed by the actor?
5.What exceptionsmight be considered as the story is
described?
6.What variations in the actor’s interaction are possible?
3

4. DEVELOPING USE CASES
Jacobson [ Jac92] suggests a number of questions that should be
answered by a use case:
7.What system information will the actor acquire, produce, or
change?
8.Will the actor have to inform the system about changes in the
external environment?
9.What information does the actor desire from the system?
10.Does the actor wish to be informed about unexpected
changes?
4

5. DEVELOPING USE CASES: Example
SafeHomerequirements
•we define four actors:
•Homeowner (a user),
•setup manager (likely the same person as homeowner, but
playing a different role),
•sensors(devices attached to the system), and the monitoring
and
•response subsystem (the central station that monitors the
SafeHomehome security function).
5

6. DEVELOPING USE CASES : Example
SafeHomerequirements
1.Enters a password to allow all other interactions.
2.Inquires about the status of a security zone.
3.inquires about the status of a sensor.
4.Presses the panic button in an emergency.
5.Activates/deactivates the security system.
6
The homeowner actor interacts with the home security
function in a number of different ways using either the alarm
control panel or a PC:

7. DEVELOPING USE CASES : Example
SafeHomerequirements
1.The homeowner observes the SafeHomecontrol panel to determine
if the system is ready for input.
2.If the system is not ready, a not ready message is displayed on the
LCD display, and the homeowner must physically close windows or
doors so that the not ready message disappears. [A not ready
message implies that a sensor is open; i.e., that a door or window is
open.]
3.The homeowner uses the keypad to key in a four-digit password.
4.The password is compared with the valid password stored in the
system.
5.If the password is incorrect, the control panel will beep once and
reset itself for additional input. If the password is correct, the control
panel awaits further action.
7
homeowner uses the control panel, the basic use case for
system activation follows:

8. DEVELOPING USE CASES : Example
SafeHomerequirements
6.The homeowner selects and keys in stay or away (see Figure 5.1) to
activate the system. Stay activates only perimeter sensors (inside motion
detecting sensors are deactivated). Away activates all sensors.
7.When activation occurs, a red alarm light can be observed by the
homeowner.
8
homeowneruses the control panel, the basic use case for
system activation follows:

9. DEVELOPING USE CASES : Example
Template for detailed descriptions of use cases:
9

10. DEVELOPING USE CASES : Example
template for detailed descriptions of use cases:
10

11. DEVELOPING USE CASES : Example
Template for detailed descriptions of use cases:
11
Use cases for other homeowner interactions would be developed in a similar manner.
It is important to review each use case with care. If some element of the interaction
is ambiguous, it is likely that a review of the use case will indicate a problem.

12. UML Diagrams
12
•It is a standard diagrammatic tool for designing.
•It is a graphical language for specifying, visual-izing, constructing
and documenting the artefacts of software systems

13. UML Diagrams
13

14. UML use-case diagram
•A UML use-case diagram is an overview of all the use
cases and how they are related.
•It provides a big picture of the functionality of the
system.
14

15. Components of UML Usecase Diagram
System Boundary
15
•It represents the scope of the system.
•It encapsulates the complete set of functionalities of the
system.
•The users that interact with a system.
•An actor can be a person, an organization or an outside
system that interacts with your application or system.
•An actor in a usecase diagram interacts with a usecase.
•It is up to the developer to consider what actors make an
impact on the functionality that they want to model.
Actors
•A usecase is a visual representation of a distinct business
functionality in a system.
•It ensures that the business process is discrete in nature.
•List the discrete business functions in given problem
statement.
•Identifying usecases is a discovery.
Usecase
s

16. Usecase Relationships
16
Association
Association represents the relationship
between an actor and a usecase.
Directed
Association
Directed Association represents the one-way
relationship where an actor takes the responsibility
of influencing a usecase.

17. Usecase Relationships
17
Include relationship represents the
situation where one usecase
includes the functionality of
one other usecase.
<<
Include>>
A directed relationship between two use cases which is used to show that behavior of
the included use case (the addition) is inserted into the behavior of the including (the
base) use case
The <<include>> relationship could be used:
To simplify large use case by splitting it into several use cases
To extract common parts of the behaviors of two or more use cases

18. Usecase Relationships
18
<< Include>>

19. Usecase Relationships
19
<< Include>>

20. Usecase Relationships
20
<< Include>>

21. Usecase Relationships
21
Extend relationship between any two use cases implies a meaningful relationship
that the extended usecase adds up additional behavior towards the existing
functionality of the base usecase.
<<
Extend>>
Use cases can make use of other
use cases
• Base use case: extended use
case
• Extending use case: provides
optional behaviour

22. Usecase Relationships
22
Generalization is the relationship
between a parent usecase and
one or more child usecases.
Dependency defines the relationship in
which the existence of one usecase is
dependent on the existence of another
usecase.
Dependency
Generalization
The Generalization relationship between two Use Cases has the same
meaning as in the case of Actors
• The behavior of the ancestor is inherited by the descendant
• This is used when there is common behavior between two use cases and also
specialized behavior specific to each use case