- The use case describes the system’s behavior under various conditions as it responds to a request from one of the stakeholders, called the primary actor.
- The primary actor initiates an interaction with the system to accomplish some goal.
- Different sequences of behavior, or scenarios, can unfold, depending on the particular requests made and conditions surrounding the requests
- Primary actor is the one with the goal that the use case addresses
- Scope identifies the system that we are addressing
- Preconditions and guarantees are the things that must be done for the success of the use case.
- Main Success is the case in which nothing goes wrong
- Extensions suggest what can happen if something goes wrong in the main success steps
We can put the logging and some of the simple settings as the preconditions since the stress should be to capture the important scenarios
I think that the extensions are the if conditions., At every step we need to ask a question what are the possible alternatives.
Importnt: (page 22): Anyone writing the usecases for a new system to be designed will write blackbox use case and so not discuss the internals
One should not get caught in too much rigor while designing a use case it is costly.
Use cases provide scaffolding that connects information in different parts of the requirements
Usecases add value since they announce a list of goals that help to figure out what the system is going to provide.
Steps to be done in order to write the use cases
The usecase should be written in a single grammatical form
suD : System under Discussion
Some of the actors are hidden, they are very much required but they are not the ones who are starting the use case. For eg logging system. It is required but it runs in the background and do not initiate a use case. Such actors are called offstage actors.
Scope
Functional scope:It refers to the services provided by the system. It will eventually be captured by the system.
One should prepare a list of actor-goal . This will make clear what are the goals achieved by a particular actor.
Brief is the 2-6 line description of the use case. The main stress is to mention the significane of the use case.
Design Scope:
It means identifying the software and the hardware that will be the part of the system. Depending on the hardware used the behaviour may change. for e.g. printing using a home laser printer is different than printing in a printing press.
The various scopes are : Enterprise, system, subsystem
Depending on the level of the usecase the details will change. The Enterprise will be a top level while the subsystem level will be dealing about how the internal works.
Stakeholders
A stakeholder is someone with a vested interest in the behavior of the use case, even if they
never interact directly with the system offstage actors.
The inclusion of these actors help in improving the quality of the use cases. They may appear in the logs,checks, validations.
The usecase need to protect the interswets of these satkeholders
Primary actor is often but not always the one to trigger the usecase. ( for e.g in case of the time based trigger the primary actor does not triggers the usecase)
Primary actors are important only at the begining and the end of the usecase. In bvetween they dont play a role, so even if we dont identify the primary actor properly not much damage will happen to the system
use some generic names for the primary user so that any alternative user with correct rights can execute the usecase
Supporting actor is an external actor that provides some kind of service to the system under design. e.g. printing service ( we can also call it as secondary actor);
An actor can be a primary axctor in one use case while a supporting actor in another
when we look into the system and name the componenet and their behavior we treat the system as white box.
There are more than just two actors in a white-box use case, since the components of the system are being
shown as well as the external actors
It is extremely rare and usually a mistake, to write white-box use cases as behavioral requirements
for a computer system to be designed
Three Named Goal Levels ( the level of the usecase)
1. summary goals
2. User Goals
3. Sub functions
User Goal
The user goal is the goal of greatest interest. It is the goal the primary actor has in trying to get
work done, or the user has in using the system at all.
A user goal addresses the question, "Can the primary actor go away happy after having done
this?" It should normally be executed in one sitting and should not take more than 30 min
Summary level
Summary level goals involves multiple user goals they solve three purposes:
1. They show the context in which the user goals operate
2. they show life-cycle sequencing of the related goals
3. They show the table of contents for the lower level use cases
Summary level use case run for more time they may take days to complete. this happens becase a summary level use case consist of number of user level use cases
They can be found by asking a question "why is the actor doing this?"
Subfunction use case:
These are the use cases that are required to caryy any small step in case of a use case e.g find a customer, save as a file
Preconditions, Triggers, guarantees
Precondition is what the system will ensure before letting the usecase to start. Having a precondition means that somebody has already run a usecase to set up the system for this particular usecase
Minimal guarantees are the least promises that can be made to the stakeholders when the primary actor goals cannot be delivered. They are of interest when the goal is abondoned. common guantees " System logged on how far it goes"
Success Guarantee: it states what interests of the stakeholders are satisfied ion the sucesful completion of a usecase either at the end of the main success path or the alternate path
I think that the extensions are the if conditions., At every step we need to ask a question what are the possible alternatives.
Importnt: (page 22): Anyone writing the usecases for a new system to be designed will write blackbox use case and so not discuss the internals
One should not get caught in too much rigor while designing a use case it is costly.
Use cases provide scaffolding that connects information in different parts of the requirements
Usecases add value since they announce a list of goals that help to figure out what the system is going to provide.
Steps to be done in order to write the use cases
- Find out the actors and goals
- Write the main success scenario
- figure out the failure conditions
- figure out the failure handling measures for the failure conditions found in step 3
The usecase should be written in a single grammatical form
suD : System under Discussion
Some of the actors are hidden, they are very much required but they are not the ones who are starting the use case. For eg logging system. It is required but it runs in the background and do not initiate a use case. Such actors are called offstage actors.
Scope
Functional scope:It refers to the services provided by the system. It will eventually be captured by the system.
One should prepare a list of actor-goal . This will make clear what are the goals achieved by a particular actor.
Brief is the 2-6 line description of the use case. The main stress is to mention the significane of the use case.
Design Scope:
It means identifying the software and the hardware that will be the part of the system. Depending on the hardware used the behaviour may change. for e.g. printing using a home laser printer is different than printing in a printing press.
The various scopes are : Enterprise, system, subsystem
Depending on the level of the usecase the details will change. The Enterprise will be a top level while the subsystem level will be dealing about how the internal works.
Stakeholders
A stakeholder is someone with a vested interest in the behavior of the use case, even if they
never interact directly with the system offstage actors.
The inclusion of these actors help in improving the quality of the use cases. They may appear in the logs,checks, validations.
The usecase need to protect the interswets of these satkeholders
Primary actor is often but not always the one to trigger the usecase. ( for e.g in case of the time based trigger the primary actor does not triggers the usecase)
Primary actors are important only at the begining and the end of the usecase. In bvetween they dont play a role, so even if we dont identify the primary actor properly not much damage will happen to the system
use some generic names for the primary user so that any alternative user with correct rights can execute the usecase
Supporting actor is an external actor that provides some kind of service to the system under design. e.g. printing service ( we can also call it as secondary actor);
An actor can be a primary axctor in one use case while a supporting actor in another
when we look into the system and name the componenet and their behavior we treat the system as white box.
There are more than just two actors in a white-box use case, since the components of the system are being
shown as well as the external actors
It is extremely rare and usually a mistake, to write white-box use cases as behavioral requirements
for a computer system to be designed
Three Named Goal Levels ( the level of the usecase)
1. summary goals
2. User Goals
3. Sub functions
User Goal
The user goal is the goal of greatest interest. It is the goal the primary actor has in trying to get
work done, or the user has in using the system at all.
A user goal addresses the question, "Can the primary actor go away happy after having done
this?" It should normally be executed in one sitting and should not take more than 30 min
- complete an purchase order or log on the system are not the user goals
- buy a book, register a new customer are user goals
Summary level
Summary level goals involves multiple user goals they solve three purposes:
1. They show the context in which the user goals operate
2. they show life-cycle sequencing of the related goals
3. They show the table of contents for the lower level use cases
Summary level use case run for more time they may take days to complete. this happens becase a summary level use case consist of number of user level use cases
They can be found by asking a question "why is the actor doing this?"
Subfunction use case:
These are the use cases that are required to caryy any small step in case of a use case e.g find a customer, save as a file
- Put a lot of energy into detecting the sea-level use cases. These are the important ones
- Write a few outermost use cases, to provide context for the others
- When you ask a question "Why ?" you get into one higher level.
- When you ask a question "How?" you get into one lower level.
Preconditions, Triggers, guarantees
Precondition is what the system will ensure before letting the usecase to start. Having a precondition means that somebody has already run a usecase to set up the system for this particular usecase
Minimal guarantees are the least promises that can be made to the stakeholders when the primary actor goals cannot be delivered. They are of interest when the goal is abondoned. common guantees " System logged on how far it goes"
Success Guarantee: it states what interests of the stakeholders are satisfied ion the sucesful completion of a usecase either at the end of the main success path or the alternate path
No comments:
Post a Comment