Understanding Requirements Object Oriented Analysis and Design Understanding Requirements

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)

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

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

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

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

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

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

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

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.

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

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.

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.

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

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

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

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

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

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, …

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

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:

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

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

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

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

UML use-case notation Use Case Actor boundary

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

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

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.

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”

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

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.