System Development Techniques Individual Assignment
Tubekbay001
Lesson3.pdf
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
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:
1. Identify all the potential users for the new system.
2. Classify the potential users in terms of their functional role (e.g., shipping, marketing, sales).
3. Further classify potential users by organizational level (e.g., operational, management, executive).
User Goal Technique
4. 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.
5. Create a list of preliminary use cases organized by type of user.
6. Look for duplicates with similar use case names and resolve inconsistencies.
7. Identify where different types of users need the same use cases.
8. 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:
1. Consider the external events in the system environment that require a response from the system by using the external events checklist
2. For each external event, identify and name the use case that the system requires.
Event Decomposition
3. Consider the temporal events that require a response from the system by using the checklist shown in temporal event.
4. 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
5. 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.
6. 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: 1. Identify all the stakeholders and users who would benefit
by having a use case diagram.
2. 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
3. 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.
4. 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
