1. Understanding Requirements
Object Oriented
Analysis and Design
Understanding Requirements

2. Object Oriented Analysis and Design
Software
Requirements
Specification
What are the business needs ?
(long text)
Collaboration
Diagrams
How software objects interact to fulfill task ?
(visual)
Use Cases
What are the domain process ?
(text + visual notation)
Conceptual
Model
What are the concepts, terms ?
(visual)
System
Sequence
Diagrams
What are the system events, operations ?
(visual)
Contracts
What do the system operations do ?
(text)
Design
Class
Diagrams
What is the specification for the software classes ?
(visual)

3. Software Requirements Specification (SRS)
Functional
Nonfunctional
Business Requirements
Vision and Scope Document
Business Rules
User Requirements
Quality Attributes
Use Case Document
External Interfaces
Systems Requirements
Constraints
Functional Requirements
Software Requirements
Specification

4. Case Study: Point of Sale
A POS is used to record sales and handle payments
It includes hardware and software
It has to interface to various service applications
A POS system increasingly must support multiple and varied client-side terminals and interfaces
It should be a commercial system adaptive to different clients needs

5. Understanding Requirements System function (Basic)
R1.1 – Record the current sale – the items purchased
R1.2 – Calculate current sale total, including tax and coupon calculations
R1.3 – Capture purches item information from a bar code or a manual entry of a universal product code (UPC)
R1.4 – Reduce inventory quantities when sale is committed
R1.5 – Log completed sale
R1.6 – Cashier must login with an ID and password to use system
R1.7 – Provide a persistent storage mechanism
R1.8 – Provide inter-process and inter-system communication mechanism
R1.9 – Display description and price of item recorded

6. Understanding Requirements System function (Payment)
R2.1 – Handle cash payments, capturing amount tendered and calculating balance
R2.2 – Handle credit card payments, capturing credit information from a card reader or by manual entry, and authorizing payment with store’s (external) credit authorization service via a modem connection
R2.3 - Handle check payments, capturing ID card by manual entry, and by authorizing payment with the store’s (external) check authorization service via a modem connection
R2.4 - Log credit payments to accounts receivable system, since the credit authorization service owes the store payment amount

7. Understanding Requirements System Attributes
Ease of Use, fault tolerance, response time, platforms, …
For each attribute we should think and describe its boundary and constraint (related to the system)
We should describe all the attributes separately of the system function and to correlate them when possible

8. Understanding Requirements System Attributes
For each attribute we should think and describe its boundary and constraint (related to the system) ….
Details and boundary constrains
Attribute
When recording a sold item the description and price will appear within 5 seconds
Response time
Must log authorized credit payment to accounts receivable within 24 hr even if power fails or device failure
Fault tolerance
Knoppix Linux
Operating system

9. Understanding Requirements System Attributes
We should describe all the attributes separately of the system function and to correlate them when possible ….
Details and Constrains
Attribute
Function
Ref#
Record the current sale – the items purchased
R1.1
Calculate current sale total, including tax and coupon calculations
R1.2
5 seconds max.
Response time
Display description and price of item recorded
R1.9
Must log to accounts receivable within 24 hr even if power fails or device failure
Fault tolerance
Log credit payments to accounts receivable system, since the credit authorization service owes the store payment amount
R2.4

10. Understanding Requirements What Requirements Are Not ?
Design or implementation details
Project planning information
Testing strategies or details
Functional requirements should describe functions from the point of view of the system.

11. Understanding Requirements Use cases
Stories or cases of using a system
A document that describes the sequence of events of an actor (an external agent) using a system to complete a process
They are not exactly requirements or functional specifications
A sequence of steps for completing a required task

12. Use cases example: Buy Item
Use Case: Buy Items
Actors: Customer, Cashier
Description: A Customer arrives at a checkout with items to purchase. Cashier records the purchased items and collects payment.

13. Use cases Notice that the emphasis is on users
The objective is to describe all tasks that users need/want to perform
use cases are stories from the point of view of the users of the systems.

14. Use cases What good are they for ?
Generate and validate requirements, make sure nothing is missed
View system from an external viewpoint
Help identify system objects
Basis for test plan
Basis for user manual
Users often describe most important use cases first, so this helps prioritize

15. Use cases defined by UML
Describes the heading and structure
Distinguish between high-level and expanded use cases
Does not specify a rigid format

16. Use cases defined by UML
Use Case: Name of use case
Actors: List of actors (external agents), indicating who initiates use case
Purpose: Intention of the use case
Description: Repetition of high level use case, or some similar summary
Cross Reference: Related use cases and system functions

17. Use cases defined by UML
Typical course of events
Heart of expanded use case
Describes, in detail, the interaction between system and the actors
Critical: Only include most common, or typical, sequence of events – average story of activities and successful completion of a process
Alterative Courses:
Describe important alternatives and exceptions

18. Use cases example: Buy Items with cash
Use Case: Buy Items with Cash
Actors:
Purpose:
Description:
Customer (initiator), Cashier
Capture a sale and its cash payment
A Customer arrives at a checkout with items to purchase. Cashier records the purchased items and collects a cash payment

19. Cross References: Reminder
System Functions R1.1, R1.2, R1.3, R1.4 R1.5 R1.7, R1.9, R2.1
Reminder
R1.1 – Record the current sale..
R1.2 – Calculate current sale total..
R1.3 – Capture purches item information from a bar code…
R1.4 – Reduce inventory quantities when sale is committed
R1.5 – Log completed sale…
R1.6 – Cashier must login with an ID and password to use system
R1.7 – Provide a persistent storage mechanism
R1.8 – Provide inter-process and inter-system communication..
R1.9 – Display description and price of item recorded
R2.1 – Handle cash payments, capturing amount tendered…
R2.2 – Handle credit card payments, …
R2.3 - Handle check payments, …
R2.4 - Log credit payments to accounts receivable system, …

20. Typical Course of Actions:
Actor Actions:
This use case begins when a Customer arrives at a POST checkout system with items to purchase
2. Cashier records the identifier for each item. If there is more than one of the same item, Cashier enters the quantity
4. On completion of item entry, Cashier indicates to POST that item entry is complete
6. Cashier tells Customer the total
System Response:
3. Determines item price and adds item info to the running sales transaction
Description and price of the current item is presented
5. Calculates and presents sale total

21. 7. Customer gives a cash payment
8. Cashier records the cash received
10. Cashier deposits the cash received and extracts balance owing
Cashier gives balance owing and receipt to Customer
12. Customer leaves with items purchased
9. Shows the balance due back to Customer Generates a receipt
11. Logs the completed sale
Line 2: Invalid identifier entered. Indicate error
Line 7: Customer did not have enough cash Cancel sales transaction
Alternative Courses:

22. Actors
An entity external to the system who participates in story of use case
Usually stimulates the system with input events
Typical Actors:
Roles that people play
Computer systems
Electrical or mechanical devices

23. Alternative Courses of Events
Additional paths can be recorded in one or more “Alternate Course” blocks
These describe reasons why the normal course (the “happy path”?) isn’t followed, and what alternate actions are performed

24. Identifying Use Cases Actor-Based Approach: Event-Based Approach:
Identify actors related to a system or organization
Then, for each actor, identify the process they initiate or participate in
Event-Based Approach:
Identify external events that a system must respond to
Relate events to actors and use cases
Yet Another approach:
Express business processes in terms of specific scenarios, then generalize

25. A Common Mistake Representing individual steps,
operations, or transactions as use cases
Question: In POS system,
is there a use case called “printing receipt”?
Use case is relatively large end-to-end process description that typically includes many steps or transactions

26. UML use-case notation
Use Case
Actor
boundary

27. POS System Use Cases POS Customer Cashier Manager Sys Admin Buy Items
Log In
Refund Purchased
Items
Manager
Sys Admin
Start up
Manage users

28. UML: Include Relationship
Buy Items
Cashier
Customer
Pay By Credit
POS
Pay By Cash
Pay By Check
<<include>>

29. use-case diagrams are secondary
Use case diagrams and use case relationships are secondary in use case work.
Use cases are text documents. Doing use case work means to write text.
A common sign of a novice use-case modeler is a preoccupation with use case diagrams and use case relationships, rather than writing text.

30. use-cases how detailed ?
As a first stage write only high level use cases
Categorize them and Rank them:
Primary
Secondary
Optional
Extended only “core” (primary and capture a great deal of the system) use cases
Later in the analyzing process fix and extend more use cases
Sometime you will find there is a need for a “real use case”

31. use-cases traps: Too many use cases Highly complex use cases
GUI-containing use cases
Data definitions or algorithms in use cases
Use cases users don’t understand (!)
New business processes

32. Requirements Analysis tips from martin fowler
Use techniques to ease your work:
Use cases
A class diagram
An activity diagram, A state diagram
Most important thing is communication with your users and customers.
Be prepared to break the rules of the UML at any time if it helps you communicate better.