Comp435 Object-Oriented Design. Requirements and Use Cases. Requirements Analysis. Outline. Requirements Analysis. Requirements change

Transcription

1 Comp435 Object-Oriented Design Requirements and Use Cases Week 2 Computer Science PSU HBG 1 3 Outline Requirements Analysis Types of Requirements Requirements in Iterative Development Requirements Artifacts in the UP Vision Use Case Model (SS) Definition Capability and conditions to which the project must conform Major causes of project failures Poor User Input Incomplete requirements Changing requirements 4 5 Requirements Change Requirements Analysis Requirements change Difficulties Complex problems, etc Essential tools Classification of requirements Use cases Project Size in Function Points 6 7 1

2 Classification of Requirements Classification of Requirements FURPS+ model FURPS Functionality requirements Usability requirements Reliability requirements Performance requirements Supportability requirements FURPS+ model The + Implementation requirements Interface requirements Operations requirements Packaging requirements Legal requirements 8 9 Classification Classification Functional requirements Behavior, features, capabilities, security Usability requirements Human factors, help documentation Example The font on the display should be readable from 5 feet Reliability requirements Frequency of failure, recoverability, predictability Performance requirements Response times, throughput, accuracy, availability, resource usage, etc Classification Supportability requirements Adaptability, internationalization, maintainability, configurability Example The system should allow frequent and easy changes in the network configuration Implementation requirements Resource limitation, language, tools, hardware Example Must use Linux, C++, and GTK 12 Requirements in the UP Major artifacts Vision Are we solving the same problem? Use-case Model for functional requirements A set of use cases System sequence diagrams (SSD) Includes requirement lists and attributes 13 2

3 Possible Timeline in UP Inception 1 week Identify use cases Describe briefly About 10% in detail iteration inc. elaboration construction transition milestone development cycle phase release final production release 14 Possible Timeline Elaboration, iteration #1 4 weeks Design small set of architectural and high-risk requirements and implement them At the end of the iteration, have a 2 day workshop to revisit the use cases As a result, 30% of the use cases are described in detail 15 Possible Timeline Possible Timeline Elaboration, iteration #2 4 weeks More design and implementation of high-risk and architectural requirements At the end, complete the detailed description of 50% of the use cases Elaboration, iteration #3 3 weeks More design and implementation 10% of the final system is built At the end, review the use cases and have 70% fully described Possible Timeline Elaboration, iteration #4 3 weeks Design and implementation 80-90% of the use cases are clarified and written in detail Construction Very little work on the use cases Design/coding for the rest of the system Use Cases The most widely used approach Central role in the UP Requirements are primarily discovered and recorded through use cases All other activities and artifacts are influenced by the use cases

4 Use Cases Written text documents, not diagrams The Use-case model Written text use cases, plus System sequence diagrams Example of a Use Case Point-of-sale (POS) system Process Sale: A customer arrives at checkout with items to buy. The cashier uses the POS system to record each purchased item. The system presents a running total and line-item details. The customer enters payment information, which the system validates and records. The system updates inventory. The customer receives a receipt Use cases vs Feature Lists Low-level feature lists Common in the past Example ID FEAT1.9 FEAT2.4 Feature System should accept entry of item identifiers. System should log credit payments to the accounts receivable system. Use Cases vs Feature Lists Why Use Cases? Organizes a set of requirements in the context of the typical scenarios of using the system Improves cohesion and comprehension to consider Group requirements by the common thread of user-oriented scenarios Some Definitions Actor Something that uses the system Something that is used by the system Scenario A sequence of interactions between actors and the system under discussion. Success scenario vs. failure scenario Use case Collection of related success and failure scenarios that describe actors using the system to achieve a goal Scenarios Handle Returns use case Main success scenario A customer arrives with items to return. The cashier uses the POS system to record Alternative Scenarios If they paid by credit card, but reimbursement transactions to their credit card are rejected, pay by cash If the system detects a failure in the external accounting system,

5 Use Cases as Black Boxes Black-box use cases Good The system records the sale Bad: The system writes the sale to a database The system generates SQL INSERT statement for the sale Do not describe the internal workings of the system Levels of Formality Brief One-paragraph summary Usually for the main success scenario Casual Multiple paragraphs that cover various scenarios Fully Dressed All steps and variations are written down Developed iteratively during elaboration Brief Use Case Point-of-sale (POS) system Process Sale: A customer arrives at checkout with items to buy. The cashier uses the POS system to record each purchased item. The system presents a running total and line-item details. The customer enters payment information, which the system validates and records. The system updates inventory. The customer receives a receipt. Casual Use Case Point-of-sale (POS) system Handle Return: Main success scenario: A customer arrives at checkout with items to buy. The cashier uses the POS system to record returned item... Alternate Scenarios: If a customer has the receipt,... If the item is open, Fully Dressed Use Case Use Case Name Scope Level Primary actor Stakeholders and their interests Preconditions and postconditions Main success scenario Extensions (Alternative scenarios) Other information Primary Actor Principal actor Has user goals Interacts with the system to fulfill the goals Example: the cashier in ProcessSale

6 Types of Actors Primary Actor Has user goals to fulfill by using the system Supporting Actor Provides a service to the system Offstage Actor Has stake in the outcome Stakeholders and Goals Many Stakeholders Customer, cashier, salesperson, company, tax agencies, credit card company Each stakeholder has goals Use Case Story of the system uses to fulfill the goals Emphasis: how does the system help to achieve the goal Preconditions / Postconditions Preconditions Conditions that are guaranteed to be true before the use case Postconditions Conditions that must be true after a successful completion of the use case Scenarios Main success scenario (Basic flow) The happy path No conditions or branching Capitalize actors names for easy identification Alternative scenarios (Extensions) Both success and failure The extension part is typically much longer than the Main Success Scenario Fully Dressed Use Case Use Case Name Scope Level Primary actor Stakeholders and their interests Preconditions and postconditions Main success scenario Extensions (Alternative scenarios) Other information Other Information Non-functional requirements Usability, Performance, Technology Example: The text on the screen should be visible from 5 feet Eventually gathered in the

7 Issues hard to capture by use case models System-wide attributes Performance Reliability Supportability Testability... Central role during early stages of design and implementation Examples Common functional requirements across many use cases Logging and error handling Security Other requirements, constraints, information Examples of other requirements Performance requirements External payment authorization should be completed within 30 seconds, 90% of the time Supportability requirements Adaptability At several defined points in the scenarios, pluggable business rules should be enabled to accommodate different customer companies Configurability Different customers wil have different network configurations Examples of other requirements Usability requirements Reliability requirements Implementation Constraints Requirements for purchased components And many more Timeline Inception is only lightly developed Focus on risky system-wide requirements Elaboration Continuous refinement In parallel with early design/implementation Stabilized at the end of elaboration A Fully Dressed Use Case (1) Use Case UC1: Process Sale Scope: NextGen POS application Level: user goal Primary actor: Cashier

8 A Fully Dressed Use Case (2) Stakeholders and their interests: Cashier: Wants accurate fast entry, and no payment errors Customer: Wants purchase, and fast service with minimal effort. Wants proof of purchase to support receipts Company: Wants to accurately record transactions Government tax agency: Wants to collect tax from every sale A Fully Dressed Use Case (3) Preconditions: Cashier is identified and authenticated Postconditions: Sales is saved. Tax is correctly calculated. Accounting and Inventory are updated A Fully dressed Use Case (4) Main success scenario: 1. Customer arrives at a POS checkout with goods to buy 2. Cashier starts new sale 3. Cashier enters item identifier 4. System records sale line item and presents item description and running total Cashier repeats steps 3-4 until done. 5. System presents total with taxes. To determine taxes the system uses an external Tax Calculator A Fully Dressed Use Case (5) Main Success Scenario (cont.) 6. Cashier tells Customer the total and asks for payment 7. Cashier enters cash amount paid by Customer, and System returns change 8. System logs completed transaction to external Accounting and Inventory Systems 9. System presents receipt 10. Customer leaves with receipt and goods A Fully dressed Use Case(6) A Fully dressed Use Case(7) Scenario Variations: 3a. Invalid Identifier: 1. System signals error and rejects entry 3b. There are multiple of same item and tracking each not important (e.g., 5 yogurts) 1. Cashier enters item category and the quantity 3-6a. Customer asks cashier to remove an item from the sale 1. Cashier enters item identifier for removal 2. System displays the running total 5a. Customer is eligible for discount: 1. Cashier signals discount 2. Cashier enters customer_id 3. System uses external CustomerInfo system to get discount percentage 4. System presents updated total

9 A Fully dressed Use Case(8) 7a. Paying by check: b. Paying by credit card: c. Paying by debit card: Summary Several actors Can you identify the actors? Would you consider the customer an actor? Black-box point of view System logs sale vs. System writes sale to a file Simplified interactions no conditions, branching, etc. Understandable by non-technical people Hunt for Use Cases Actor-Goal Perspective Use cases Defined to satisfy the goals of the primary actors Procedure Choose the system boundary Identify primary actors Identify the goals for each primary actor Define use cases for each of the goals Hunt for Use Cases Helpful Tests Boss test Does it make the boss happy? EBP (Elementary Business Process) test Does it add observable/measurable business value Can it be done at one time in one place by one person Size test Does it have reasonable number of steps Hunt for Use Cases Examples Which of the following is a valid use case Negotiate a supplier contract Handle returns Log in Move piece on game board 58 9