1

OBJECT ORIENTED ANALYSIS AND DESIGN

Instructor Lecture Date : : 31th August, 2010

Session Contents and Learning Outcomes

2

Inception Understanding Requirements Introduction to Use Cases

OOAD,

INCEPTION
OOAD

What is Inception
4

Inception in one sentence:

Envision

the product scope, vision, and business case.

The main problem solved in one sentence:

Do

the stakeholders have basic agreement on the vision of the project, and is it worth investing in serious investigation?

OOAD,

Inception May Be Very Brief

5

The intent of inception is to establish some initial common vision:

for the objectives of the project, determine if it is feasible, and decide if it is worth some serious investigation in elaboration. first requirements workshop, planning for the first iteration.

It may include the:

OOAD,

What Artifacts May Start in Inception?

Artifact Vision and Business Case Use-Case Model Supplementary Specification Glossary Risk List & Risk Management Plan Prototypes and proof-of-concepts Iteration Plan Phase Plan & Software Development Plan Development Case Comment Describes the high-level goals and constraints, the business case, and provides an executive summary. Describes the functional requirements, and related non-functional requirements. Describes other requirements. Key domain terminology. Describes the business, technical, resource, schedule risks, and ideas for their mitigation or response. To clarify the vision, and validate technical ideas. Describes what to do in the first elaboration iteration. Low-precision guess for elaboration phase duration and effort. Tools, people, education, and other resources. A description of the customized UP steps and artifacts for this project. In the UP, one always customizes it for the project
6

OOAD,

You Know You Didn't Understand Inception When...

7

It is more than "a few" weeks long for most projects. There is an attempt to define most of the requirements. Estimates or plans are expected to be reliable. You define the architecture; rather, this should be done iteratively in elaboration. You believe that the proper sequence of work should be: 1) define the requirements; 2) design the architecture; 3) implement. There is no Business Case or Vision artifact. The names of most of the use cases and actors were not identified. All the use cases were written in detail. None of the use cases were written in detail; rather, 10-20% should be written in detail to obtain some realistic insight into the scope of the problem.
7

OOAD,

Define the Problem

The most critical question: Is this the right system to make?

VISION

FALL 2010

Vision
10

Revision History Version Inception draft Date Jan 10, 2031 Description First daft. To be refined primarily during elaboration Author Craig Larman

10

OOAD,

Vision.. (2)
11

Introduction We envision a next generation fault-tolerant point-of-sale (POS) application, NextGen POS, with the flexibility to support varying customer business rules, multiple terminal and user interface mechanisms, and integration with multiple third-party supporting systems. Business Opportunity Existing POS products are not adaptable to the customer's business, in terms of varying business rules and varying network designs (for example, thin client or not; 2, 3, or 4-tier architectures). In addition, they do not scale well as terminals and business increase. And, none can work in either on-line or off-line mode, dynamically adapting depending on failures. None easily integrate with many third-party systems. None allow for new terminal technologies such as mobile PDAs. There is marketplace dissatisfaction with this inflexible state of affairs, and demand for a POS that rectifies this.

11

OOAD,

Vision.. (3)
12

Problem Statement Traditional POS systems are inflexible, fault intolerant, and difficult to integrate with third-party systems. This leads to problems in timely sales processing, instituting improved processes that don't match the software, and accurate and timely accounting and inventory data to support measurement and planning, among other concerns. This affects cashiers, store managers, system administrators, and corporate management.

12

OOAD,

&

Vision.. (4)
13

High-Level Priority Goal high Fast, robust, integrated sales processing

Problems and Concerns Reduced speed as load increases. Loss of sales processing capability if components fail. Lack of up-todate and accurate information from accounting and other systems due to non-integration with existing accounting, inventory, and HR systems. Leads to difficulties in measuring and planning. Inability to customize business rules to unique business requirements. Difficulty in adding new terminal or user interface types (for example, mobile PDAs).
13

Current Solutions Existing POS products provide basic sales processing, but do not address these problems.

OOAD,

Vision.. (5)
14

User-Level Goals

The users (and external systems) need a system to fulfill these goals: This may be the Actor-Goal List created during use-case modeling, or a more terse summary.

Cashier: process sales, handle returns, cash in, cash out System administrator: manage users, manage security, manage system tables Manager: start up, shut down Sales activity system: analyze sales data And so on
14

OOAD,

&

Summary of Benefits
15

Supporting Feature
Functionally, the system will provide all the common services a sales organization requires, including sales capture, payment authorization, return handling, and so forth. Automatic detection of failures, switching to local offline processing for unavailable services. Pluggable business rules at various scenario points during sales processing. Real-time transactions with third-party systems, using industry standard protocols.

Stakeholder Benefit (Goals)

Automated, fast point-of-sale services.

Continued sales processing when external components fail. Flexible business logic configuration. Timely, accurate sales, accounting, and inventory information, to support measuring and planning.

Similar to the Actor-Goal list, this table relates goals, benefits, and solutions, but at a higher level not solely related to use cases.
15

OOAD,

Vision.. (7)
16

Assumptions and Dependencies... Cost and Pricing... Licensing and Installation... Summary of System Features As discussed below, system features are a terse format to summarize functionality.

sales capture payment authorization (credit, debit, check) system administration for users, security, code and constants tables, and so forth. automatic offline sales processing when external components fail real-time transactions, based on industry standards, with third-party systems, including inventory, accounting, human resources, tax calculators, and payment authorization services definition and execution of customized "pluggable" business rules at fixed, common points in the processing scenarios
16

OOAD,

17

UNDERSTANDING REQUIREMENTS
OOAD

Requirements
18

These are the capabilities and conditions that the system, the project, and the product must provide and meet. Managing requirements is a best practice for project managers. Requirement issues are the leading cause of project failure. Even if you do a perfect job of building the wrong thing, its no good!

18

OOAD,

Not Waterfall Requirements

19

There is an attempt in the waterfall method to describe the requirements fully and accurately and freeze them. Unified process realizes that change is constant, so plans for change instead of setting an impossible goal.

19

OOAD,

10