OO Methodology Inception Phase

Table of Contents Case Study: NextGen POS System Introduction to Inception Phase Understanding Requirements Use-Case Model Identifying Other Requirements

Case Study : NextGen POS System NextGen POS(Point-Of-Sale) system is a computerized application used to record sales and handle payments typically used in a retail store includes hardware components such as computers, barcode scanners; and software to run the system Interfaces to various service applications, such as a third-party tax calculator and inventory control must be relatively fault-tolerant Architectural Layers Interface Application login and domain object layer Technical services layer Sale Payment Persistence Facade Log

Introduction to Inception Intent of inception to establish some initial common vision for the objectives of the project to determine if it is feasible to decide if it is worth some serious investigation elaboration Duration one or a few weeks If it has been decided beforehand that the project will definitely be done, and it is clearly feasible, it is especially brief and quickly moves to elaboration phase Artifacts Vision and Business Case Use-Case Model Supplementary Specifications Glossary Risk List and Risk Management Plan Prototypes and Proof-of-concepts Iteration Plan Phase Plan & Software Development Plan Development Case

Understanding Requirements Requirements are capabilities and conditions to which the system must conform Requirement management a systematic approach to finding, documenting, organizing, and tracking the changing requirements of a system Types of Requirements (FURPS+) Functional – features, capabilities Usability – human factors, help, documentation Reliability – frequency of failure, recoverability, predictability Performance – response time, throughput, accuracy, resource usage Supportability – adaptability, maintainability, internationalization, configurability Implementation – resource limitations, languages and tools ... Interface – constraints imposed by interfacing with external systems Operations – system management in its operational setting Packaging Legal – licensing and so forth

Use-Case Modeling Use case modeling is a modeling technique used to describe what a system should do Purposes of use case model to decide and describe the functional requirements of the system (agreement between the customer and software developer) to give a clear and consistent description of what the system should do, so that the model is used as basis for further development phases to provide a basis for performing system tests to provide the ability to trace functional requirement into actual classes (ease in maintenance) Use-case model is described in use-case diagram Components in use-case diagram Actors Use cases System

Use-Case Modeling Actors any entities that reside outside the system interfacing with the system, such as people, software system, hardware, data stores, or network etc. actor is a type, not an instance each actor defines a particular role A use case is a complete functionality as perceived by an actor a use case is a collection of related success and failure scenarios that describe actors using a system to support a goal (need) a set of use-case instances, where each instance is a sequence of actions a system performs that yields an observable result of value to a particular actor a use case is always initiated by an actor a use case is complete a use case describes one aspect of usage of the system use cases don not presume any specific design or implementation use cases are written in text documents, not diagrams and use-case modeling is an act of writing text, not drawing

Use-Case Model Use-Case Diagram Place Order Customer Order Processing

Writing a Use Case Use Case Types Use Case Formats Black-box use cases : they do not describes the internal workings of the system, its components, or design example: “The system records the sale” (O) “The system writes the sale to a database” or “The system generates a SQL statement for the sale...” (X) Use Case Formats brief : terse one paragraph summary(main success scenario) casual: informal multiple paragraphs that cover verious scenarios fully-dressed: all steps and variations are written in detail Example of the casual format Use Case: Handle Returns Main Success Scenario: A customer arrives at a checkout with items to return. The cashier uses the POS system to record each returned item... Alternative Scenarios: If the credit authorization is reject, inform the customer and ask for an alternate payment method If the item identifier is not found in the system, notify the Cashier and suggest manual entry of the identifier code If the system detects failure to communicate with the external tax calculator system ....

Fully-Dressed Format Extensions(Alternative Flows): Primary Actor: ... Stakeholders and Interests: Preconditions Postcondtions: Main Success Scenario: Extensions(Alternative Flows): Special Requirements: Technology and Data variations List: Frequency of Occurrence: Open Issues:

Fully-Dressed Format Stakeholders and Interests The system operates a contract between stakeholders... The use cases captures all and only the behaviors related to satisfying the stakeholders interests Preconditions and Postconditions preconditions state what must always be true before beginning a scenario in the use case postconditions state what must be true on successful completion of the use case Main Success Scenario (Basic Flows) typical success path that satisfies the interests of the stakeholders not include any conditions or branching The steps have one of three kinds: an interaction between actors a validation (usually by the system) a state change by the system

Fully-Dressed Format Extensions (or Alternative Flows) Extension scenarios are all other scenario or branches from the main success scenario An extension has two parts: the condition and the handling 3a. Invalid identifier (condition) 1. System signals error and rejects entry (handling) A condition is something that can be detected by the system or arises by an actor At the end of extension handling, by default the scenario merges back with the main scenario If a particular extension point is quite complex, as in the “paying by credit” extension, the extension can be expressed as a separate use case ( <<extends>> relationship ) Special Requirements If a non-functional requirement relates specifically to a use case, record it with the use case These include qualities such as performance, reliability, and usability, and design constraints These requirements can be captured in the Supplementary Specification Technology and Data Variations List Technical constraints imposed by a stakeholder (e.g. I/O tech) Early design decision (obvious or unavoidable) Variations in data schemes

Fully-Dressed Example: Process Sale Primary Actor: Cashier Stakeholders and Interests: Cashier : Wants accurate, fast entry and no payment errors, as cash drawer shortages are deducted from his/her salary Salesperson: Wants sales commissions updated Customer: Wants purchase and fast service with minimal effort. Wants proof for purchase to support returns Company: Wants to accurately record transactions and satisfy customer interests. Wants to ensure that payment Authorization Service payment receivables are recorded. Wants automatic and fast update of accounting and inventory Government Tax Agencies: Want to collect tax from every sale. May be multiple agencies, such as national, state and county. Payment Authorization Service: Wants to receive digital authorization requests in the correct format and protocol. Wants to accurately account for their payables to the store. Preconditions: Cashier is identified and authenticated Postcondtions: Sale is saved. Tax is correctly calculated. Accounting and Inventory are updated. Commissions recorded. Receipt is generated

Fully-Dressed Example: Process Sale Main Success Scenario: Customer arrives at POS checkout with goods and/or services to purchase Cashier starts a new sale Cashier enters item identifier System records sale line item and presents item description, prices, and running total. Cashier repeats steps 3-4 until indicates done System presents total with taxes calculated Cashier tells Customer the total, and asks for payment Customer pays and System handles payment System logs completed sale and sends sale and payment information to the external Accounting system and Inventory system System presents receipt Customer leaves with receipt and goods

Fully-Dressed Example: Process Sale Extensions(Alternative Flows): 3a. Invalid identifier: 1. System signals error and rejects entry 3b. Cashier can enter item category and the quantity 3-6a. Customer asks Cashier to remove an item from the purchase 3-6b. Customer asks Cashier to cancel sale 5a. System detects failure to communicate with external tax calculation system service: 1. System restarts the service on the POS node and continues 1a. System detects that the service does not restart 1. System signals error 2. Cashier may manually calculate and enter the tax or cancel the sale ....

Fully-Dressed Example: Process Sale Special Requirements: Touch screen UI on a large flat panel monitor. Text must be visible from 1 meter. Credit authorization response with 30 seconds 90% of the time Somehow, we want robust recovery when access to remote services such as the inventory system is failing Language internationalization on the text displayed Technology and Data variations List: 3a. Item identifier entered by bar code laser scanner or keyboard 3b. Item identifier may be any UPC, EAN, JAN, or SKU coding scheme 7a. Credit account information entered by card reader or keyboard 7b. Credit payment signature captured on paper receipt. But within tow years, we predict many customers will want digital signature capture Frequency of Occurrence: Could be nearly continuous Open Issues: What are the tax law variations? Explore the remote service recovery issue. What customization is needed for differnent businesses?

Finding Actors and Use Cases Basic Procedure Choose the system boundary Identify the primary actors Identify their user goals (EBP guideline) Define use cases that satisfy user goals (one-to-one mapping) Identifying actors Who uses the system? Who installs the system? Who starts up and shuts down the system? Who maintains the system? What other systems use this system? Who gets information from this system? Who provides information to the system? Does anything happen automatically at a preset time?

Identifying Actors and Use cases Identify actors goals and use cases Find the user goals Define a use case for each EBP Use Case Guideline Focus on use cases at the level of elementary business processes(EBP) Elementary Business Processes A task performed by one person in one place at one time in response to a business event, which adds measurable business value and leaves the data in a consistent state e.g. Place Order Which of these is a valid use case? Negotiate a Supplier Contract Handle Returns Log In Common use case mistake is defining many uses cases at too low a level, that is, subfunction, or subtask within an EBP. e.g. Log In, Paying by Credit What do you do? or What are your goals?

Identifying Actors and Use cases Actor-Goal List Define one EBP-level use case for each user goal exception : GRUD goals ( e.g. Manage<X> ) Actor Goal Cashier process sales process rentals handle returns cash in cash out ... System Administrator add users modify users delete users manage security Manager start up shut down Sales Activity analyze sales

Use-Case Model Use-Case Diagram

Use Case vs Feature List Feature List (low-level detailed) what system shall do long lists do not relate the requirements in a cohesive context But, sometimes use cases do not really fit e.g. application servers, middleware, or back-end systems High-level system feature lists are acceptable to summarize system functionality with a terse, high-level feature list (system feature in UP Vision Document) sale capture payment authorization(credit, debit, check) automatic offline sales processing when external components fail real-time transactions, based on industry standards with third-party systems including inventory, accounting, tax calculators, and payment authorization services ....

Use Cases within the UP Use case driven development requirement are primarily recorded in use cases use cases are an important part of iterative planning use case realizations drive the design use case often influence the organization of user manuals use cases drive test models etc. Use Cases and Iteration Plans Table 6.1 In Inception Phase, most use cases identified by name, and only 10% to 20% written in detail e.g. Process Sale Handle Returns Most use cases(about 80-90%) completed in detail in Elaboration Phase

Identifying Other Requirements Supplementary Specification captures other requirements, information and constraints not easily captured in the use cases FURPS+ requirements reports hardware and software constraints development constraints other design and implementation constraints internationalization concerns documentation licensing and other legal concerns packaging standards physical environment operational concerns domain or business rules information in domains of interest