Analysis All

8/14/2019 Analysis All

1/106

September 1, 2003 BITS C461/IS C341 Software Engineering 1

Requirements Analysis-1

Last Update: Monday September 1, 2003


2/106


Contents Requirements Analysis: What and How ?

Unified Process

OO Analysis and Design

Basics

UML Actors, Use cases


3/106


Requirements Analysis [1] What is it?

The process by which customer needs areunderstood and documented.

Example 1:

The system shall allow users to withdraw cash. [What?]

Example 2:

A sale items name and other attributes will be stored in a hash tableand updated each time any attribute changes. [How?]

Expresses what is to be built and NOT how itis to be built.


4/106


Requirements Analysis [2] C- and D-Requirements

C-: Customer wants and needs; expressed in languageunderstood by the customer.

D-: For the developers; may be more formal.


5/106


Requirements Analysis [3]Why document requirements?

Serves as a contract between the customer and thedeveloper.

Serves as a source of test plans.

Serves to specify project goals and plan developmentcycles and increments.


6/106


Requirements Analysis [4] Roadmap:

Identify the customer.

Write C-requirements, review with customer, andupdate when necessary.

Interview customer representatives.

Write D-requirements; check to make sure that there is noinconsistency between the C- and the D-requirements.


7/106


Requirements Analysis [5] C-requirements:

Use cases expressed individually and with a use casediagram. A use case specifies a collection of scenarios.

Sample use case: Process sale.

Data flow diagram: Explains the flow of data items across various functions. Useful for explaining

system functions. [Example on the next slide.]

State transition diagram: Explains the change of system state in response to one or

more operations. [Example two slides later.]

User interface: Generally not a part of requirements analysisthough may be included.


8/106


Data Flow Diagram

Get employee

file

Total pay

Deducttaxes

Net payIssue

paycheck

Regular

hours

Overtime

hours

ID

Worker

Check

Company records

Employee Record

Tax rates

Pay rate

Weekly

pay*Pay Overtime

pay*

Overtime

rate

*


9/106


State Transition Diagram (STD)

EBOFF (e,f) EBON (e,f)

EBP(e,f)

EBP(e,f)

EBOFF (e,f): Elevatore button OFF at floorf.

EBON (e,f): Elevatore button ON at floorf.

EBP(e,f): Elevatore buttonfis pressed.

Elevator example (partial):


10/106


Requirements Analysis [6] D-requirements:

Organize the D-requirements.

Create sequence diagrams for use cases:

Obtain D-requirements from C-requirementsand customer.

Outline test plans

Inspect

Validate with customer.

Release:


11/106


Requirements Analysis [7]Organize the D-requirements:

Functional requirements

The blood pressure monitor will measure the blood pressure

and display it on the in-built screen.

Non-functional requirements

Performance

The blood pressure monitor will complete a

reading within 10 seconds.

Reliability

The blood pressure monitor must have a failureprobability of less than 0.01 during the first 500readings.


12/106


Requirements Analysis [8]Interface requirements: interaction with the users and

other applications

The blood pressure monitor will have a display screen and pushbuttons. The display screen will.

Constraints: timing, accuracy

The blood pressure monitor will take readingswith an error less than 2%.


13/106


Requirements Analysis [9]Properties of D-requirements: Traceability: Functional requirements

D-requirement inspection report design segment

code segment code inspection report testplan test report

Traceability: Non-Functional requirements

(a)

Isolate each non-functional requirement.(b) Document each class/function with the

related non-functional requirement.


14/106


Requirements Analysis [10] Testability

It must be possible to test each requirement. Example ?

Categorization and prioritization..next slide


15/106


Prioritizing (Ranking) Use Cases Strategy :

pick the use cases that significantly influencethe core architecture

pick the use cases that are critical to the successof the business.

a useful rule of thumb - pick the use cases that

are the highest risk!!!


16/106


Requirements Analysis [11] Completeness

Self contained, no omissions.

Error conditionsState what happens in case of an error. Howshould the implementation react in case of anerror condition?


17/106


Consistency of Requirements

Different requirements must be consistent.

R5.4: When the vehicle is cruising at a speedgreater than 300 mph, a

special watchdog safety mechanism will be automaticallyactivated.

Example:

R1.2: The speed of the vehicle will never exceed 250 mph.


18/106


OO Analysis and Design:Objectives

Compare and Contrast analysis and design

Define object-oriented analysis and design

Relate, by analogy, OO analysis and design to businessorganization.


19/106


What is Analysis and Design?

Analysis - investigation of the problem (what);

Design - conceptual solution to fulfill the requirements (how); how willthe system do what it is intended to do.

What does the system do? Investigation of the problem.

What (conceptual) solution will full the requirements


20/106


What is OO analysis and design?

Essence of OO analysis - consider a problem domainfrom the perspective of objects (real world things,concepts)

Essence of OO design - define the solution as a collection of software objects(allocating responsibilities to objects)


21/106


Examples

OO Analysis - in the case of library information systems,one would findconcepts like book, library, patron

OO Design - emphasis on defining the software objects;ultimately these objects are implemented in someprogramming language; Bookmay have a method named

print.


22/106


Example - contd.

Domain concept

Representation in

analysis of

concepts

Book

______title

print()

publicclass Book

{

publicvoidprint();

private stringtitle;

}

Representation in

OO programming

language


23/106


Digression: OO Concepts-Objects

http://java.sun.com/docs/books/tutorial/java/concepts/

Objects: Anything that has a state and exhibits behavior.

Real world objects: Bicycle, student, course, dog, university,.

Software objects: Model real-world or abstract objects(e.g. a list).

Methods: Procedures through which objects communicateamongst themselves. Example: Bicycle: brake, park. Dog:bark, eat. Student: register, study.

Attributes: Variables that hold state information. Bicycle: speed, color, owner.Dog:name, breed. Student: name, ID.


24/106


Digression: OO Concepts-Class

Class:Prototype for all objects of a certain kind.Student, animal, university, shape, etc.

Objects: Created from a class. For example: s1, s2 areobjects from class Student.

Inheritence: A class inherits attributes and methods from its super class. Thisallows hierarchical organization of classes.

Interface: A contract between a class and its users. Aclass implements an interface (methods and attributes).

BITS and Purdue are objects from class University.myCircle and mySquare are objects from class Shape.


25/106


What are business processes?

First step - consider what the business must do; in thecase of a library - lending books, keeping track of duedates, buying new books.

In OO terms - requirements analysis; represent thebusiness processes in textual narration (Use Cases).


26/106


Roles in the organization

Identify the roles of people who will be involved in thebusiness processes.

In OO terms - this is known as domain analysis

Examples - customer, library assistant, programmer,

navigator, sensor, etc.

Examples from class projects?


27/106


Who does what? Collaboration

Business processes and people identified; time todetermine how to fulfill the processes and whoexecutes these processes.

In OO terms - object oriented design; assigningresponsibilities to the various software objects.

Often expressed in class diagrams.


28/106


In Summary...

Business

Analogy

OO Analysis

and Design

Associated

Documents

What are the

business

processes?

Requirements

analysis

Use cases

What are

employee roles?

Domain analysis Conceptual

model

Who isresponsible for

what?

Responsibilityassignment;

Design classdiagrams


29/106


Simple example to see bigpicture

Define use cases

Example: Dice game a player rolls two die. If the

total is 7 they win; otherwise they lose

Define conceptual model

Define collaboration diagrams

Define design class diagrams


30/106


Define use cases

Use cases - narrative descriptions ofdomainprocesses in a structured prose format

Use case: Play a game

Actors: Player

Description: This use case begins when the

player picks up and rolls the die.


31/106


Define domain model

OO Analysis concerns specification of the problem domain identification of concepts (objects)

Decomposition of the problem domain includes identification of objects, attributes, associations

Outcome of analysis expressed as a domainmodel.


32/106


Domain model - game of dice

Player

_____

name

Die

____

facevalue

DiceGame

2

1

Includes

1

1

Plays

1 2Rolls

Conceptual model is not a description of the software components;

it represents concepts in the real world problem domain


33/106


Collaboration diagram

Essential step - allocating responsibility to objectsand illustrating how they interact with other objects.

Collaboration diagrams express the flow of messages between

Objects.

OO Design is concerned with defining logical software specification that fulfills

the requirements

Expressed as Collaboration diagrams


34/106


Example - collaboration diagram

:Player d1:Die1: r1:=roll()

d2:Die2: r2:= roll()


35/106


Defining class diagrams

Key questions to ask How do objects connect to other objects? What are the behaviors (methods) of these

objects?

Collaboration diagrams suggests connections; tosupport these connections methods are needed

Expressed as class diagrams


36/106


Example - Class diagram

Playername

play()

DiceGame

initialize()

DiefaceValue

roll()

1

1

Plays

1

1 2

includes

2

1

21

Rolls

1 2

A line with an arrow at the end may suggest an attribute.

For example,DiceGame has an attribute that points to an

instance of a Player


37/106


Defining Models andArtifacts

Objectives analysis and design models familiarize UML notations and diagrams

Models provide a mechanism for decomposition andexpressing specifications

Real world software systems are inherently complex


38/106


Analysis and Designmodels

Analysis model - models related to an investigation ofthe domain and problem space (Use case modelqualifies as an example)

Design model - models related to the solution (classdiagrams qualifies as an example)


39/106


What UML is not

UML is NOT a methodology

UML is NOT a process

UML is NOT proprietary (Now under the OMG)

UML is strictlyNotations


40/106


Parts of UML

Views - shows different aspects of the system thatare modeled, links the modeling language to themethod/process chosen for development

Diagrams - graphs that describe the contents in aview

Model elements - concepts used in a diagram


41/106


Views in UML

UseCase

View

Use-case view :A view showing the functionality ofthe system as perceived by the external actors


42/106


Views in UML

UseCase

View

Logical

View

Logical view: A view showing how the functionality isdesigned inside the system, in terms of the staticstructure and dynamic behavior.


43/106


Views in UML

UseCase

View

Logical

View

Component

View

Component view:A view showing theorganization of the code components


44/106


Views in UML

Component

View

UseCase

View

Logical

View

Concurrency

View

Concurrency view:A view showing theconcurrency of the system


45/106


Views in UML

Component

View

UseCase

View

Logical

View

Concurrency

View

Deployment

View

Deployment view:A view showing the deployment of thesystem in terms of the physical architecture


46/106


Introduction to UML[4]

Model elements Class Object State Use case Interface Association

Link Package .


47/106


UML diagrams

Use Case diagram: External interaction with actors

Class/Object Diagram : captures static structural

aspects, objects and relationships.

State Diagram: Dynamic state behavior

Sequence diagram: models object interaction over time

Collaboration diagram: models component interaction andstructural dependencies


48/106


More UML diagrams

Activity diagram : models object activities

Deployment diagram : models physical architecture

Component diagram : models software architecture


49/106


Case study - Point of SaleTerminal

POS terminal should support the following record sales handle payments

Several architectural layers presentation

application logic (problem domain, servicesupport)

persistence

Emphasis - problem domain application objects


50/106


Analysis

Objectives

Draw use case diagrams

Ranking Use cases

Identification of Use Cases


51/106


Use Cases

Use case - narration of the sequence ofevents of an actor using a system

UML icon for use case


52/106


Actors [1]

Actor - an entity external to the system that insome way participates in the use case

An actor typically stimulates the system withinput events or receives outputs from thesystem or does both.

Customer

UML notation for actor:


53/106


Actors [2]

Primary Actor- an entity external to the system thatuses system services in a direct manner.

Supporting Actor-an actor that provides services to thesystem being built.

Hardware, software applications, individual processes, can all be actors.


54/106


Identification of Use Cases [1]

Method 1 - Actor based

Identify the actors related to the system

Identify the scenarios these actors initiate or

participate in.

Method 2 - Event based Identify the external events that a system must respond to Relate the events to actors and use cases

Method 3 Goal based [Actors have goals.] Find user goals. [Prepare actor-goal list.] Define a use case for each goal.


55/106


Identification of Use Cases[2]

To identify use cases, focus on elementarybusiness processes (EBP).

An EBP is a task performed by one person in oneplace at one time, in response to a business event.This task adds measurable business value and

leaves data in a consistent state.


56/106


Back to POST - Actors

Actors:

Choosing actors:

Identify system boundary

Identify entities, human or otherwise, that will interact with the system, from outside the boundary.

Cashier

Customer

Supervisor

Example: A temperature sensing device is an actorfor a temperature monitoring application.


57/106


POST - Use Cases: First Try

Cashier Log In Cash out

Customer Buy items Return items


58/106


Common mistake

Representing individual steps as use cases.

Example: printing a receipt (Why is thisbeing done ?)


59/106


High level vs. Low Level Use

cases[1]

Consider the following use cases: Log out Handle payment

Negotiate contract with a supplier

These use cases are at different levels. Are theyall valid? To check, use the EBP definition.


60/106


High level vs. Low Level Use cases

[2]

Log out: a secondary goal; it is necessary to dosomething but not useful in itself.

Handle payment: A necessary EBP. Hence a primary goal.

Negotiate contract: Most likely this is too high a

level. It is composed of several EBPs and hencemust be broken down further.


61/106


Use Case Diagram - Example

Use Case Diagram: illustrates a set of use cases for a system.

Process sale

PaymentAuthorization

service

Manage

securitySystem administrator

Cashier Handle returns

Process rental

Tax calculator

Manage users

Accountingsystem


62/106


More on Use Cases

Narrate use cases independent of implementation

State success scenarios (how do you determine the successof a use case).

A use case corresponds to one or more scenarios.

Agree on a format for use case description

Name a use case starting with a verb in order to emphasizethat it is a process (Buy Items, Enter an order, Reduceinventory)


63/106


Exception handling

Document exception handling or branching

What is expected of the system when a Buy Item

fails ?

What is expected of the system when a creditcard approval fails ?


64/106


A sample Use Case

Use case: Buy Items

Actors: Customer, Cashier

Description: A customer arrives at a checkout with

items to purchase. The cashier recordsthe purchase items and collects payment.


65/106


Ranking Use Cases

Use some ordering that is customary to yourenvironment Example: High, Medium, Low Example: Must have, Essential, Nice to have

Useful when deciding what goes into an increment

POST example: Buy Items - High Refund Items - Medium (Why?) Shut Down POST terminal - Low


66/106


Requirements Analysis-2

Last Update Thursday August 26, 2003


67/106


Use Case - Buy Item Version 1

Use Case Buy Items - version 1

Actors Customer, Cashier

Purpose Capture a sale and its cash payment

OverviewA customer arrives at a checkout with items to

purchase. The cashier records the purchase items and collects

a cash payment. On completion the customer leaves with the items.

Type Primary

Typical course of Events (please refer to Larman)


68/106


System Behavior

Objective identify system events and system operations

create system sequence diagrams for use cases


69/106


System sequence diagram-Example

:Cashier

:System

makeNewsale()

endSale()

Description, total

[* more items]

enterItem(itemID, quantity)

total with taxes

makePayment(amount)

change due, receipt

Box to enclose

an iteration area.


70/106


System sequence diagrams [1]

SSD drawing occurs during the analysis phase of adevelopment cycle; dependent on the creation of the

use cases and identification of concepts.

A system sequence diagram illustrates events from actorstosystemsand the external response of the system

UML notation - Sequence Diagram notSystem Sequence

Diagram.


71/106


System sequence diagrams [2]

One diagram depicts one scenario. This is the mainsuccess scenario.

Frequent or complex alternate scenarios could also beillustrated.

A system is treated as a black box.

SSD is often accompanied by a textual description of thescenario to the left of the diagram.


72/106


System sequence diagram [3]

Identify the system boundarywhat is inside and whatis outside.

System event: An external event that directly stimulates the

(software) system. Events are initiated by actors.

Name an event at the level ofintentand notusing theirphysical input medium or interface widgets.

enterItem() is better than scan().

Keep the system response at an abstract level. description, total is preferred over display description and

total on the POS screen.


73/106


Domain model: What is it?

Usually expressed in the form ofstatic diagrams (inRational Rose this implies a high-level class diagram).

Illustrates meaningful concepts in theproblem domain.

Is a representation ofreal-worldthings; not software components(of the system under development).

No operations are defined or specified in the domain model.

The model shows concepts, associations between concepts,and attributes of concepts.

Serves as a source of software objects.


74/106


Domain model: How toconstruct?

Objectives identify concepts related to current development

cycle requirements

create initial conceptual model

Identify attributes

add specification concepts


75/106


Partial domain model of POST

Concept

Sale

datetime

1..*

Contained-in

11

Attributes

10..1

Records-sale-ofSales LineItem

quantityItem

Store

addressname

1

Stocked-in

Register(POST)

Houses1

1..*

Captured-on

1

1


76/106


Finding concepts: Use nounphrases

Finding concepts using Noun Phrase identification in thetextual description of the domain.

Finding concepts using the concept category list (refer to page

p134 in Larman):

Physical objects: register, airplane, blood pressure monitor

Places: airport, hospital

Catalogs: Product Catalog

i di f


77/106


Finding concepts: refer to usecases

Examine use case descriptions.

Example: Process Sale use case:

Main success scenario:

Customerarrives at a POS checkout counter. Cashierstarts a new sale. Cashierenters anitem ID. System records sale line item. It then presents a

description of the item, its price, and a running total. . .

Possible source of confusion: Is it an attribute or a concept? If X is not a number or a text then it probably is a conceptual class.

Finding concepts:


78/106


Finding concepts:Examples

Concepts from Unreal world ?

Message Connection Port

Use terms familiar to those in the problem domain.

POST or register?

Are these concepts or attributes? Store Flight

Price


79/106


Concepts in POST domain

POST Item Sale Store Payment SalesLineItem ProductCatalog


80/106


Specification Concepts

When are they needed?

Add a specification concept when:

deleting instances of things they describe (forexample, Item) results in a loss of informationthat needs to be maintained.

it reduces redundant or duplicated information


81/106


Specification Example

Assume that

an item instance represents a physical item in the store; ithas a serial number

an item has a description, price and UPC which are not

recorded anywhere else. every time a real physical item is sold, a corresponding

software instance ofitem is deleted from the database

With these assumptions, what happens when the storesells out of a specific item like burgers? How does onefind out how much does the burger cost ?

Notice that the price is stored with the inventoried instances


82/106


Specification Example Contd.

Also notice the data is duplicated many times with eachinstance of the item.

This example illustrates the need for a concept of

objects that are specifications or descriptions of otherthings (often called a Proxy or Surrogate)

Description or specification objects are strongly relatedto the things they describe.


83/106


Specification - ExampleProductDesciption

descriptionpriceUPC

Item

Serial Number

*1

describes

*1

Item

Serial NumberdescriptionPrice

itemID

Which of these two

is a better choice of concepts? XSpecification describes X


84/106


Conceptual Models - Association

Objective Identify associations within a conceptual model distinguish between need-to-know associations from

comprehension-only associations


85/106


Associations

Association - a relationship between concepts that indicatessome meaningful and interesting connection

POST Sale

11

Records-current

11

Association


86/106


Finding Associations

High priority associations A is a physical or logical part ofB A is physically or logically contained in/on B A is recorded in B

Other associations A uses or manages or controls B (Pilot -airplane) A owns B (Airline -airplane)


87/106


Association Guidelines

Focus on those associations for which knowledge of the relationship needs to be preserved forsome duration (need-to-know associations)

More important to identify concepts than associations

Too many associations tend to confuse the conceptual model

Avoid showing redundant or derivable associations


88/106


Roles in Associations

Each of the two ends of an association is called a role.Roles have

name multiplicity expression navigability


89/106


Multiplicity

Multiplicity defines how many instances of type A canbe associated with one instance of type B at a particularmoment in time

POST Sale

11

Records-current

11

Multiplicity of the role


90/106


Association - Multiplicity

Multiplicity: indicates the number of objects of one class themay be related to a single object of an associated class

Can be one of the following types 1 to 1, 1 to 0..*, 1 to 1..*, 1 to n, 1 to 1..n


91/106


Associations - Contd.

Sale payment

11

Paid-by

11

Store

POST

11 11

Records-current1..*

1

Contains

1..*

1

Associations are generally read left to right, top to bottom


92/106


Associations - Contd.

Flight Airport

0..1*

0..1*flies-to

0..1*

flies-from0..1

*

Multiple associations between two types

During analysis phase, an association is nota statementabout data flows, instance variables, or object connections

in the software solution.


93/106


Conceptual Model - Attributes

Objectives identify attributes in a conceptual model distinguish between correct and incorrect attributes


94/106


Attributes [1]

Attribute - is a logical data value of an object.

Include the following attributes in a domain model those for which the requirements suggest or imply a

need to remember information

For example, a sale receipt normally includes a date andtime attribute

It is a named property of a class describingvalues held by each object of the class

Attribute Type: A specification of the externalbehavior and/or the implementation of theattribute

Attribute Name:attribute Type


95/106


Attributes [2]

Attributes in a conceptual model should preferably besimple attributes or pure data values

Common simple attribute types include boolean, date, number, string, time


96/106


Attributes: Examples

Relate two items with associations, not attributes, in

conceptual model.

worse Cashier

namecurrentPost

not a"simple attribute

better Cashier

name

POST

number11

uses

1


97/106


Complex Attributes

Pure data values - expressed as attributes; they do notillustrate specific behaviors; Example - Phone number A Person can have many Phone numbers

Non-primitive attribute types represent attributes as non-primitive types (concepts or objects) if

it is composed of separate sections (name of a person) there are operations associated with it such as validation it is a quantity with a unit (payment has a unit of currency)


98/106


Complex Attributes

It is desirable to show non-primitive attributes asconcepts in a conceptual model

Flight Airport

11

Flies-to

Flight

destination

Destination a

Complex concept


99/106


Recording terms in Glossary

Define all terms that need clarification in a glossary ormodel dictionary.


100/106


System Sequence diagram [1]

Use cases suggest how actors interact with the software system

An actor generates events to a system, requestingsome operation in response

Example - when a cashier enters an items UPC, the cashier requeststhe POST system to record that item purchase. That request eventinitiates an operation upon the system

Desirable to isolate and illustrate the operations that anactor requests of a system


101/106


System Sequence Diagram [2]

Shows for a particular scenario of a use case, the events thatexternal actors generate, their order and inter-system events

A scenario of a use case is a particular instance or realized path

Should be done for a typical course of events of the use case(usually for the most interesting ones)


102/106


System Events, Operations

System event - external input event generated by an actor

System operation - operation of the system that executes inresponse


103/106


Recording System operations

Set of all required systems operations is determined byidentifying the system events.

Operation(arg:ArgType=defaultvalue,,,):ReturnType(s)

Examples: enterItem(UPC,quantity); endSale();makePayment(amount)

UML notation -


104/106


Contracts

A contractdescribes detailed system behavior in termsof state changes to objects in the domainmodel.

A contract is a system operation. It is offered in thesystems public interface.

One use case may require one or more system

operations (events) to complete a scenario.


105/106


Contract: Example

Operation: enterItem(itemID: ItemID, quantity: integer)

Cross References: Use case: Process sale

Preconditions: There is a sale underway.

Postconditions:AsalesLineItem instance, sli, was created.

sli was associated with the current Sale.sli.qty becomes quantity (attribute modification).

sli was associatedwithProductSpecification based on

itemID match.


106/106

Artifacts of AnalysisAnalysis Artifact Questions Answered

Use Cases What are the domainprocesses?

Conceptualmodel

What are the concepts and

terms?

Interactiondiagrams

What are system events andoperations?

Contracts What arethe semantics of