System Development Techniques Individual Assignment
System Development Techniques
Diploma in Information Technology
Lesson 3
Learning outcomes
After studying this chapter and the recommended reading, you should be able to:
Explain:
Use case description
Use cases and user goals
Use cases and event decomposition
Use cases diagrams
2
User Stories and Use Cases
Identifying user stories and use cases is a key task when defining functional requirements
User stories and use cases form the basis for the list of functions the system needs to carry out.
User Stories
One short sentence in user everyday language that states what a user does as part of their work.
Describes a goal the user has when using the system.
Focus on who, what, and why for each function.
The users and stakeholders are responsible for identifying the user stories.
User Stories
Objective is to get a potential user to articulate what the users wants to do with the new system.
The standard template for a user story looks like this:
“As a <role played>, I want to <goal or desire>
so that <reason or benefit>.”
User Stories
For example, some user stories for a bank teller might be:
“As a teller, I want to make a deposit to quickly serve more customers.”
“As a teller, I want to balance the cash drawer to assure there were no errors.”
As a customer of the bank using an ATM machine, some user stories might be:
“As a bank customer, I want to withdraw cash and feel confident the stack of cash I get is the correct amount.”
“As a bank customer, I want to deposit a check and feel confident the deposit is recorded correctly.”
User Stories – acceptance criteria
Final part of a user story is the acceptance criteria.
Indicate the features that must be present for the user to be satisfied with the resulting implementation.
Focus on functionality,
not on features or user-interface design.
User Stories – acceptance criteria
For example, the following are the acceptance criteria for the user story “bank teller making a deposit”:
Customer lookup must be by name or by account number.
It would be nice to display photo and signature of customer.
Any check hold requirements must be indicated.
Current balance and new balance must be displayed.
Use case
An activity the system performs in response to a request by a user.
User stories help analysts to identify and define use cases,
Two techniques to identify use cases:
user goal technique
event decomposition technique.
User Goal Technique
The user goal technique for identifying use cases includes these steps:
Identify all the potential users for the new system.
Classify the potential users in terms of their functional role (e.g., shipping, marketing, sales).
Further classify potential users by organizational level (e.g., operational, management, executive).
User Goal Technique
Interview each type of user to determine the specific goals they will have when using the new system.
Start with goals they currently have and then get them to imagine innovative functions they think would add value.
Encourage them to state each goal in the imperative verb-noun form, such as Add customer, Update order, and Produce month-end report.
Create a list of preliminary use cases organized by type of user.
Look for duplicates with similar use case names and resolve inconsistencies.
Identify where different types of users need the same use cases.
Review the completed list with each type of user and then with interested stakeholders.
User Goal Technique
Event Decomposition
Most comprehensive technique for identifying use cases
The appropriate level of detail for identifying use cases is one that focuses on elementary business processes (EBPs)
EBP is a task that is performed by one person in one place in response to a business event.
Adds measurable business value, and leaves the system and its data in a stable and consistent state.
Event Decomposition
Examples of EBP
Search for item, Fill shopping cart, View product rating
Fill shopping cart
A response to the business event “Customer wants to shop.”
There is one person filling the cart.
Measurable value for the customer as items are added to the cart.
When customer stops adding items and moves to another task, the system remembers the current cart and is ready to switch to the new task.
Event Decomposition
Each EBP (and thus each use case) occurs in response to a business event.
An event
occurs at a specific time and place,
can be described,
remembered by the system.
drive or trigger all processing that a system does,
Listing and analysing events helps to define system requirements by identifying use cases.
Types of Events
Three types of events to consider:
external events,
temporal events (temporal – related to time)
state events (aka internal events).
External events
An event that occurs outside the system
Usually initiated by an external agent or actor
An external agent (or actor) is a person or organizational unit that supplies or receives data from the system.
To identify the key external events, the analyst first tries to identify all the external agents that might want something from the system
External events
Example of an external agent is a customer.
customer may want to place an order for one or more products.
customer wants to return an ordered product
customer needs to pay the invoice for an order.
External events such as these define what the system needs to be able to do.
They are events that lead to important transactions that the system must process.
External events
Describing external events,
Name the event
clearly define the external agent/actor
description should include the action that the external agent wants to pursue.
Example
Event name: Customer places an order
Actor: a customer
Action: to place an order for some products
External events
External events can also come from the needs of people or organizational units inside the company (e.g., management requests for information).
Example
Event name: Management wants to check order status.
Actor: Management
Action: managers want to follow up on an order for a key customer
External events
External event can occurs when external entities provide new information that the system simply needs to store for later use.
Example,
Event name: Customer needs to update account information
Actor : customer
Action : customer reports a change in address, phone, or employer.
External events checklist
Checklist to help in identifying external events.
External events to look for include:
External agent wants something resulting in a transaction
External agent wants some information
Data changed and needs to be updated
Management wants some information
Temporal events
An event that occurs as a result of reaching a point in time.
Example:
Monthly payroll report
Weekly/monthly sales performance report
Exception reports.
Example, If a customer bill has not been paid within 15 days, the system might send a late notice.
The temporal event “Time to send late notice” might be defined as a point 15 days after the billing date.
Automatically generated
State events (internal events)
Event that occurs when something happens inside the system that triggers the need for processing.
For example,
Sale of a product results in an adjustment to an inventory record, and the inventory in stock drops below a reorder point, it is necessary to reorder.
The Sequence of Events: Tracing a Transaction’s Life Cycle
A useful method for identifying events is to trace the sequence of events that might occur for a specific actor.
First, the customer wants a catalogue or asks for some information about item availability.
Then, the customer might want to place an order.
Perhaps the customer want to change the order—for example, correcting the size of the shirt or buying another shirt.
Next, the customer might want to check the status of an order to find out the shipping date.
Perhaps the customer has moved and wants an address change recorded for future catalogue mailings.
Finally, the customer might want to return an item.
Thinking through this type of sequence can help identify events
System controls
System controls
checks or safety procedures put in place to protect the integrity of the system.
For example,
logging on to a system is required because of system security controls
the integrity of the database, such as backing up the data every day
System controls
System controls are important to the system,
But spending time on system controls during analysis only adds details to the requirements model that users are not typically very concerned about; they trust the system developers to take care of such details.
One way to help decide which events apply to system controls is to assume that technology is perfect.
Perfect technology assumption
Events should be included during analysis only if the system would be required to respond under perfect conditions
Perfect conditions:
equipment never breaking down,
capacity for processing and storage being unlimited,
people operating the system being completely honest and never making mistakes
Perfect technology assumption
Examples of events that can be deferred until the developer is designing in system controls.
User wants to log on to the system
User wants to change the password
User wants to change preference settings
System crash requires database recovery
Time to back up the database
Time to require the user to change the password
Don’t worry much about these until you are considering design issues.
Event Decomposition
The event decomposition technique for identifying use cases includes these steps:
Consider the external events in the system environment that require a response from the system by using the external events checklist
For each external event, identify and name the use case that the system requires.
Event Decomposition
Consider the temporal events that require a response from the system by using the checklist shown in temporal event.
For each temporal event, identify and name the use case that the system requires and then establish the point of time that will trigger the use case.
Event Decomposition
Consider the state events that the system might respond to, particularly if it is a real-time system in which devices or internal state changes trigger use cases.
For each state event, identify and name the use case that the system requires and then define the state change.
Event Decomposition
When events and use cases are defined, check to see if they are required as part of analysis by using the perfect technology assumption.
Do not include events that involve such system controls as login, logout, change password, and backup or restore the database, as these are put in as system controls.
Use Cases example
| Sales Subsystem | |
| Use cases | Users/actors |
| Search for item | Customer, customer service representative, store sales representative |
| View product comments and ratings | Customer, customer service representative, store sales representative |
| View accessory combinations | Customer, customer service representative, store sales representative |
| Fill shopping cart | Customer |
| Empty shopping cart | Customer |
| Check out shopping cart | Customer |
| Fill reserve cart | Customer |
| Empty reserve cart | Customer |
| Convert reserve cart | Customer |
| Create phone sale | Customer service representative |
| Create store sale | Store sales representative |
Use Cases example
| Order Fulfillment Subsystem | |
| Use cases | Users/actors |
| Ship items | Shipping |
| Manage shippers | Shipping |
| Create backorder | Shipping |
| Create item return | Shipping, customer |
| Look up order status | Shipping, customer, management |
| Track shipment | Shipping, customer, marketing |
| Rate and comment on product | Customer |
| Provide suggestion | Customer |
| Review suggestions | Management |
Use Cases example
| Customer Account Subsystem | |
| Use cases | Users/actors |
| Create/update customer account | Customer, customer service representative, store sales representative |
| Process account adjustment | Management |
| Send message | Customer |
| Browse messages | Customer |
| Request friend linkup | Customer |
| Reply to linkup request | Customer |
| Send/receive partner credits | Customer |
| View “mountain bucks” | Customer |
| Transfer “mountain bucks” | Customer |
*mountain bucks are point system used by that company
Use Cases example
| Marketing Subsystem | |
| Use cases | Users/actors |
| Add/update product information | Merchandising, marketing |
| Add/update promotion | Marketing |
| Add/update accessory package | Merchandising |
| Add/update business partner link | Marketing |
Use Cases example
| Reporting Subsystem | |
| Use cases | Users/actors |
| Produce daily transaction summary report | Management |
| Produce sales history report | Management, marketing |
| Produce sales trends report | Marketing |
| Produce customer usage report | Marketing |
| Produce shipment history report | Management, shipping |
| Produce promotion impact report | Marketing |
| Produce promotional partner activity report | Management, marketing |
Use case diagram
Create diagrams that visually depict use cases and how they are organized.
The use case diagram is the Unified Modelling Language (UML) model used to illustrate use cases and their relationship to users.
Actors
In Unified Modelling Language (UML) an actor is a person who uses the system .
An actor is always outside the automation boundary of the system but may be part of the manual portion of the system.
Sometimes, the actor for a use case is not a person; instead, it can be another system or device that receives services from the system.
A simple stick figure represents an actor.
Use case diagram basic
Use case diagram basic
The stick figure is given a name that characterizes the role the actor is playing.
The use case itself is represented by an oval with the name of the use case inside.
Use case diagram basic
The connecting line between the actor and the use case indicates that the actor is involved with that use case.
Use case diagram basic
The automation boundary, which defines the border between the computerized portion of the application and the people operating the application, is shown as a rectangle containing the use case.
Use case diagram examples
Use case diagram examples
Many ways to organize use case diagrams for communicating with users, stakeholders, and project team members.
One way is to show all use cases invoked by a particular actor (i.e., from the user’s viewpoint).
This approach is often used during requirements definition because the systems analyst may be working with a particular user and identifying all the functions that user performs with the system.
The next Use case diagram illustrates this viewpoint, showing all the use cases involving the customer for the Sales subsystem.
Use case diagram examples
Use case diagram examples
The next use case diagram shows use cases involving the customer service representative and the store sales representative for the Sales subsystem.
Analysts can expand this approach to include all the use cases invoked by any department, regardless of the subsystem, or all use cases important to a specific stakeholder.
Use case diagram examples
Use case diagram examples «includes» Relationships
During the development of a use case diagram, it becomes apparent that one use case might use the services of another use case.
For example, in the Sales subsystem use case the customer might search for an item, view product comments and ratings, and view accessory combinations before beginning to fill the shopping cart.
However, while filling the shopping cart, the customer might also search for an item, view product comments, and view accessories. Therefore, one use case uses, or “includes,” another use case.
Use case diagram examples «includes» Relationships
Use case diagram examples «includes» Relationships
Fill shopping cart also includes Search for item, View product comments and ratings, and View accessory combinations.
Thus, the Customer can view comments initially, and also while carrying out the Fill shopping cart use case.
The relationship is read Fill shopping cart includes Search for item.
Use case diagram examples «includes» Relationships
Also know as «uses» relationship.
Note that the word includes is enclosed within guillemets in the diagram; this is the way to refer to a stereotype in UML. It means that the relationship between one use case and another use case is a stereotypical «includes» relationship.
Developing a Use Case Diagram
The steps to develop use case diagrams are:
Identify all the stakeholders and users who would benefit by having a use case diagram.
Determine what each stakeholder or user needs to review in a use case diagram. Typically, a use case diagram might be produced for each subsystem, for each type of user, for use cases with the «includes» relationship, and for use cases that are of interest to specific stakeholders.
Developing a Use Case Diagram
For each potential communication need, select the use cases and actors to show and draw the use case diagram. There are many software packages that can be used to draw use case diagrams.
Carefully name each use case diagram and then note how and when the diagram should be used to review use cases with stakeholders and users.
Summary
Objective of user story is to get a potential user to articulate what the users wants to do with the new system.
The standard template for a user story looks like this:
“As a <role played>, I want to <goal or desire>
so that <reason or benefit>.”
Summary
Two techniques to identify use cases:
user goal technique
event decomposition technique.
Three types of events to consider for event decomposition technique
external events,
temporal events (temporal – related to time)
state events (aka internal events).
Summary
Use case diagrams visually depict use cases and how they are organized.
The use case diagram is the Unified Modelling Language (UML) model used to illustrate use cases and their relationship to users.
Read
Textbook:
Satzinger, Robert & Stephen Chapter 3
59