OO Methodology

Inception Phase

2

Table of Contents

• Case Study: NextGen POS System

• Introduction to Inception Phase

• Understanding Requirements

• Use-Case Model

• Identifying Other Requirements

3

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 anddomain objectlayer

Technicalservices layer

Sale Payment

PersistenceFacade

Log

4

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

5

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

6

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

7

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

8

Use-Case Model

• Use-Case Diagram

Place Order

Customer

Order Processing

9

Writing a Use Case

• Use Case Types – 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 ....

10

Fully-Dressed Format

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:

...

11

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:1. an interaction between actors

2. a validation (usually by the system)

3. a state change by the system

12

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 handling3a. 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

13

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

14

Fully-Dressed Example: Process Sale

Main Success Scenario:

1. Customer arrives at POS checkout with goods and/or services to purchase

2. Cashier starts a new sale

3. Cashier enters item identifier

4. System records sale line item and presents item description, prices, and running total.

Cashier repeats steps 3-4 until indicates done

5. System presents total with taxes calculated

6. Cashier tells Customer the total, and asks for payment

7. Customer pays and System handles payment

8. System logs completed sale and sends sale and payment information to the external Accounting system and Inventory system

9. System presents receipt

10. Customer leaves with receipt and goods

15

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

....

16

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?

17

Finding Actors and Use Cases

• Basic Procedure1. Choose the system boundary

2. Identify the primary actors

3. Identify their user goals (EBP guideline)

4. 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?

18

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?

19

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

System

analyze sales

... ... ... ...

20

Use-Case Model

• Use-Case Diagram

NextGen

Manage Users

. . .

Cashier

SystemAdministrator

actor

use case

communicationsystem boundary

Handle ReturnsPayment

AuthorizationService

«actor»Tax Calculator

«actor»Accounting

System

alternatenotation fora computersystem actor

Process Rental

«actor»HR System

Cash In

Process Sale

«actor»Sales Activity

System

Manage Security

Analyze Activity

21

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

• ....

22

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

23

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