BA CourseBook (PDF) - Requirements Increquirementsinc.com/library/ba/day1.pdf · 2019. 3. 6. · ATM System ATM Use Cases Inception package OpenUP {1/2} atm:ATM 'Bank Customer' Bank

Table of Contents 1. Object-Oriented Analysis and Design 1

3. UML Use Case Modeling 13

4. UML Activity Modeling 39

5. UML State Modeling 65

6. Writing Text Use Cases 86

7. Requirement Management (DOORS) 107

8. UML Class Modeling 139

9. Entity Relationship Diagrams (ERDs) 150

10. Structured Query Language (SQL) 158

11. Testing 188

12. Version Control / Repository Management 215

13. Software Change Control / Issue Tracking 236

14. UML Sequence Modeling 251

15. UML Physical Modeling 264

16. Assignments 273

17. Assignment Solutions Course Website

Business Analyst Workshop

Module 1.1

Object Oriented

Analysis and Design

Essential skills to become a successful Business Analyst

RequirementsInc.com BusinessAnalystWorkshop.com

©2013 | v13.1

BusinessAnalystWorkshop.com RequirementsInc.com

2

Programming Paradigms

Procedural Object Oriented Programming

Core Function Object with data + functions

Principle • Functions deliver when

they are called

• Data is accessed externally

• Objects deliver responsibilities,

functions are internal to the object

• Data is internal to the object and not

manipulated by another source

Example • Credit()

• Debit()

•Above functions are

exposed to external

functions, increasing risk of

erroneous manipulation

•Message GeneralLedger and

RequestCredit() or RequestDebit()

•GeneralLedger object has complete

control of functions and date within

itself.

• Procedural programming follows a top down (linear) approach, achieved by

‘calling functions’. Example: Run payroll checks, Generate receipt

• OOP relies on collaboration among a system of ‘objects’. Objects can

perform specific functions and message other objects to ‘call their functions’.

Objects can also manipulate ‘data’ – hence each object is a collection of data

+ functions.


3

Why use Objects?

• Not all functions and systems are linear / predictable, hence

need to execute functions on-demand based on a specific

scenario

• Greater Simplicity: no need to review entire code for

maintenance.

• More Flexibility: objects are self contained and can be

reused/modified, decreasing redundancy.

• Easier control: everything is communication based

(messaging)

A group of objects interact with each other to share data, exchange

functions, effectively simulating / implementing a program in a system.


4

What is an Object

• A specific, unique entity or thing comprising of data and

functions.

• Eg., 2007, Black, Automatic, Front Wheel Drive, 4-door

Toyota Camry Car with VIN# JH4NA1152MT001365:

– Has data that defines it

• Make=Toyota, Model=Camry, Year=2007, Color=Black, Transmission

type=Manual, Drive type=Front Wheel Drive, # of doors=4,

VIN#=JH4NA1152MT001365 etc.

– Has functions that it can perform

• drive, race, transport, tow, etc.


5

Objects can be associated with

• Data (also referred as attributes, fields, variables, values, states)

– A characteristic/property of any object

• Functions (also referred as operations, behavior, subroutines, methods)

– An object has operations it can perform built right into it

• Messages (also referred as requests, communications, method triggers)

– Using messages, objects interact and request services from each other

– Three components of a message are:

• The object to whom the message is addressed

• The name of the method to perform

• Any parameters needed by the method

Car: Drive (on 2nd gear) iPod: Play (the 7th song on playlist)


6

What is a Class

• Common description of a set of objects that share the same attributes, operations and relationships

• Represents / is a blue print of: several objects

• NOT uniquely identifiable, not a specific entity

• Eg., A Car, A Toyota Car, A Toyota Camry Car – Has data that defines it

• Make, Model, Year, Color, Transmission type, Drive type, # of doors, etc. (no values, if it had values it would be an object)

– Has functions that it can perform

• drive, race, transport, tow, etc. (note that the functions are the same)


7

Relationship of Classes vs. Objects

• An Object is an instance of a Class

• Many objects are “copied” from a class

Attributes: Origin, Size

Methods: Open(), Close(),

Move(), Display()

Window Window #32

Attributes: Origin = 455,px,239px

Size = 5”x 7”

Methods: Open(), Close(),

Move(), Display()

Instance Class


8

Abstraction

• Abstraction

– Revealing the right level of detail pertaining to context /

audience

• Usage: Each UML model can be drawn at a level of

abstraction needed

• Allows moving from a high level overview to the lower level

detailed requirements

• E.g., Online Banking: • Monthly summary abstracts detailed transactions

• Abstraction allows focusing on the essential elements of the

problem

More abstract, less detail


9

Encapsulation

• Encapsulation

– binds data and functions into one entity

– separates interface and implementation

The interface of the object is the attributes and methods that are visible

(available) from the outside of the object from other elements

The implementation of an object, is the use of attributes and methods

that are reserved for private use of the object itself.

• Protects its data from other outside functions “data hiding”

• Usage:

– Implementation can change without affecting users - Makes it easier to change implementation with minimal changes to interface

• Example, Bank of America was able to change their check deposit process (eliminate deposit envelopes) without affecting users


10

Inheritance

• A sub-class inherits the attributes and

operations from its super class and may

add new methods or attributes of its own.

• Generalisation in the UML is inheritance in

OOP.

• Usage

– derive a new type from an existing one

– reuse, don't reinvent.

• Car > Japanese car> Japanese 4 door car> Small

size car> Toyota> Corolla

• Class hierarchy: one class (a super-class)

is a generalisation of one or more other

classes (sub-classes).

Is a Kind Of

Test for inheritance

Employee

Prog rammer

projectprogLanguages

Mana ger

ProjectMana ger

budgetsControlled

dateAppointed

projects

Dept.Mana ger

Strateg icMana ger

dept responsibilities

• Parent (base/superclass)

– Provides common

functionality and data

members

• Child (derived/subclass)

– Inherits public and

protected members

from the superclass

– Can extend behavior


11

E.g., Online Banking: Login> Sitekey Login

Site Key feature is an

inheritance of the regular

login feature (can be turned

off independently if needed)


12

Polymorphism

• Polymorphism

– customize the behavior of an object

• Polymorphism is the ability of an object to respond differently

to the same message based on the requesting object

• Eg., operator overloading in Java

5 + 7 = 12

“high” + ”school” = “highschool”

Business Analyst Workshop

Module 2.1

UML

Use Case Modeling

Essential skills to become a successful Business Analyst

RequirementsInc.com BusinessAnalystWorkshop.com


14

What is a use case?

• A use case is a particular example (a case) of how a system

is used - “case of system use”.

• A use case named as a [Verb + Object]

– Is performed to achieve a goal

– Is triggered by an actor or another use case

– Is a unit of distinct business functionality

– Abstracts system functionality at a bird’s eye level

• Online Banking System

– View Statement, Check Balance, etc.

Formal Definition [OMG]

“The Use Case construct is used to define the behavior of a system or other semantic entity

without revealing the entity’s internal structure. Each Use Case specifies a sequence of

actions, including variants, that the entity can perform, interacting with actors of the entity”.

Formal Definition [Alistair Cockburn]

Use Cases record a contract between system stakeholders about the behaviors of the

system under discussion under various circumstances, organized by goals of selected

actors”.

Maintain schedule

Request course roster

Maintain curriculum


15

Use Case Models and Use Cases

• UML Use case model (diagram)

– pictorially depicts the system functionality and the interacting actors

(people and external systems)

– drawn at the system level representing ‘use case to use case’

relationships, ‘actor to use case’ relationships

– visualizes functionality of the system

• Use case (textual)

– textually describes the sequential interaction between the system

and an actor to deliver value to a user

– explains the path that the user takes to achieve the goal of the use

case, some paths may be longer, some paths may fail

– documents functional requirements

A good Use Case name:

•Starts with a verb

•Makes the purpose clear

•Is recognizable to the Subject Matter Expert, making it easier for discussions


16

What is an actor?

• An actor is someone or something outside of the system that interacts with the system (person, organization, service

or another system)

• Time can be an actor!

• An actor is just a role that a person can assume

• The same person may assume multiple roles

• A role can be performed by multiple actors

Billing System StudentRegistrarProfessor

Primary Actors Secondary Actors

Initiate use cases Provide input

Act as a service on-demand

Receive messages

E.g., Customer Make payment E.g., Gather Credit Score Equifax (for credit

checks)

Send email alert Customer


17

Use Case Model Notation Actor An Actor is a user of the system / someone or

something that interacts with the system.

The role of the user is written beneath the icon.

Use Case

A Use Case is functionality provided by the system

(e.g., Register Car, Delete User).

System

boundary

Marks the bounds of the system. Distinguish

functionalities “in scope” and “out of scope”.

Package Logical folders to group related use cases together.

Typically used then the use case diagram is too

large.

May used to represent different releases.

Directed

Association

Associations are used to show interactions.

Directed associations are depicted by an arrow with

the direction originating from the trigger.

Often misread as information flow..

Actor

Use Case

System

UC

A

Package A

UC1

UC2


18

Use Case Model Notation Association Associations are used to show interactions.

(Undirected) associations are depicted by a plain

line..

Primary actors on the left and secondary actors on

the right if using plain association

(Semantically same as directed association)

Generaliza-

tion

Inheritance relationship (generalization in UML) is

indicated by a block arrow pointing to the parent.

<<Include>>

stereotype

A base use case executes an <<include>> use case

as part of its flow to complete its business

functionality.

E.g., Transfer Balance <<includes>> Check

Balance

<<Extend>>

stereotype

A base use case may be extended by an

<<extend>> use case based on a certain condition.

E.g., Buy extended warranty

<<Extends>> Buy laptop

<<include>>

<<extend>>


19

Course Registration System

System

Professor

Registrar

Billing System

Student Maintain schedule

Maintain curriculum

Request course roster


20

ATM System

ATM Use Cases Inception package OpenUP {1/2}

atm:ATM

'Bank Customer'

Bank

'Maintenance Person'

'Withdraw Cash'

'Deposit Funds'

'Transfer Funds'

'Refill Machine'

Primary Actors

are typically to

the left and

Secondary Actors

are typically to

the right


21

Library System


22

Actor Generalization

In this diagram,

Actor

Generalization

is represented.

Premium Member

and General Member

can perform the use

cases attached

to the parent

‘Member’.


23

Use Case Generalization

• Generalization allows for the replacement / enhancement of

general class (parent) by the creation of specific class (child)

BUT adheres to rules that applies to the general class

(parent)

• So rules that are common to all entities are held centrally

Parent use case

Child use case

Perform search

Search by author

Search by ISBN

Search by title


24

Actor and Use Case Generalization

Fulfill phone order

Fulfill online order

Fulfill catalog order

Charge credit card

<<include>>

<<include>>

Phone salesman

In-store salespman

Fulfill instore order

<<include>>

Fulfill Order

Salesperson

Parent actor

Parent use case


25

Preconditions

• Preconditions are statements / use cases that must be

true before the use case in hand is executed

• Don’t have to account for precondition-related scenarios

in the main flow

• E.g.,

– “Register for an account” is a precondition to “Login”

– “Login” is a precondition to “Pay fees”

Customer

Login

Register for courses

Pay fees

Register for an account


26

<<Include>> Construct

• Signifies that the base use case calls the included use case (also <<uses>> or <<includes>>)

• Eg., A includes B – A is the base (calling) use case, B is the included (called) use case

– During A’s execution, B will be called one or more times and then control comes back to A

– A cannot produce success outcome without running B

– Nothing precludes B from being executed directly by the user/another use case without <<include>> relationship

• Example: Transfer Funds <<includes>> Check Balance; Check Balance may be executed by itself as well

• Programmatically, similar to subroutines (function call) to reuse a frequently accessed functionality

A Base use case

B Included use case

<<include>>


27

• Benefits

– Reusability:

Pull out use cases that may be called (included) by multiple

use cases

– Modularity:

Keep different business goals separate

<<Include>> Construct

Customer

Login

Register for courses

Pay fees

<<include>>

<<include>>


28

Customer

Login

Register for an account

<<include>>

Is this correct?


29

<<Extend>> Construct

• Signifies that the extending use case extends the functionality of the base use case

• Eg., B extends A – A is the base use case, B extends the functionality of A

– B may or may not be executed (based on a certain condition during A’s execution)

– A can run (produce success outcome) without running B

– Nothing precludes B from being executed directly by the user/another use case without <<extend>> relationship

– Example: Buy warranty <<extends>> Buy laptop. Buy warranty may be purchased by itself.

• Usually used to keep special / specific business cases separate from a basic flow

A Base use case

B Extending use case

<<extend>>


30

<<Extend>> Construct

• Benefits

– Separates flows that detract in focus/goal from the base use

case

– Makes the base use case less complex by making

conditional flows into a separate use case

Apply discount code

Purchase item

Add maintenance

<<extend>>

<<extend>>


31

<<Extend>> Example

Customer Order Management

System

Ecommerce System

Add to Cart

View catalog

Add 1 day shipping

Purchase Book

<<extend>>


32

Is this correct?

Pay for dinner

Pay by credit card

Pay by check

<<extend>>

Pay by cash

<<extend>>

<<extend>>


33

<<Include>> and <<Extend>>

Buy theme park ticket

Buy lunch

Theme park tourist

Buy speedpass ticket

Make payment

<<include>>

<<include>>

<<extend>>

Is anything missing in this

diagram?


34

Patient Management System


35

Inventory System

Same as <<include>>


36

Payroll System


37

Use cases across releases

javascript:PopImage('IMG_19','http://images.books24x7.com/bookimages/id_16163/fig48_01_0.jpg','1000','557')


38

Steps for creating a use case model

• Identify and name the actors (think about assignable user roles)

• Are any of these actors a specialized type of another more general

actor? If so, identify generalized actor and specialized actors.

• Identify the Use Cases

• Are any Use Cases always used by (an)other Use Case(s)? Are there

common flows across multiple use cases? (Identify includes)

• Are any of the Use Cases “sometimes” used by (an)other Use Case?

Are any flows of a use case optional? (Identify entends)

• Draw the Use Case diagram, including and labeling all actors, Use

Cases, and relationships

• Ensure that

– Each use case has a goal (combine use cases as needed)

– No use case is too complex/has too many scenarios (split use cases as

needed)

– Each use case has a trigger

– Each actor has at least one use case

– Use cases can be completed in one sitting. If time delay applies, split use

case

Documents

BA CourseBook (PDF) - Requirements Increquirementsinc.com/library/ba/day1.pdf · 2019. 3. 6. · ATM System ATM Use Cases Inception package OpenUP {1/2} atm:ATM 'Bank Customer' Bank