Management Information

System

Lecture 7
Systems Development Life Cycle
1. System Planning
2. Systems Analysis
3. Systems Design
4. Systems Development
5. Systems Testing
6. Systems Implementation
7. Systems Operation, Support and Security
SYSTEMS ANALYSIS
Analysis Modeling answers the questions of
• WHO will use the system;
• WHAT the system will do;
• WHERE and WHEN it will be used
SYSTEMS ANALYSIS
Requirements Modelling
• Functional Requirements
• Non-functional Requirements

Data Modelling
• Data Flow Diagram

Process Modelling
• SIPOC
• Business Process Modelling Notation
SYSTEMS ANALYSIS
Object Modelling
(Unified Modeling Language)

• a standardized modeling language

consisting of an integrated set of
diagrams, developed to help system
and software developers for
specifying, visualizing, constructing,
and documenting the artifacts of
software systems, as well as for
business modeling and other non-
software systems.
SYSTEMS ANALYSIS

OO Analysis
• Defining all of the types of objects that do the work in a system and
showing what the user interactions are required to complete the
tasks

• The procedure of identifying system requirements and developing

specifications in terms of a system’s object model, which comprises
of interacting objects

• The primary tasks in object-oriented analysis (OOA) :

§ Identifying objects
§ Organizing the objects by creating object model diagram
§ Defining the internals of the objects, or object attributes
§ Defining the behavior of the objects, i.e., object actions
§ Describing how the objects interact
§ The common models used in OOA are use cases and object models
SYSTEMS ANALYSIS

OO Design
• Defining all of the types of objects necessary to communicate
with people and devices in the system, showing how the
objects interact to complete tasks, and refining the definition
of each type of object so it can be implemented with a specific
language or environment

• Implementation of the conceptual model produced during

object-oriented analysis

• The implementation details generally include:

§ Restructuring the class data (if necessary),
§ Implementation of methods, i.e., internal data structures
and algorithms
§ Implementation of control
§ Implementation of associations
OBJECT ORIENTED ANALYSIS and DESIGN

An OBJECT is a real-world element in an object–oriented environment

that may have a physical or a conceptual existence

An object may have a physical existence, like a customer, a car, etc.; or

an intangible conceptual existence, like a project, a process, etc.

Each object has:

• Identity that distinguishes it from other objects in the system.
• State that determines the characteristic properties of an object as
well as the values of the properties that the object holds.
• Behavior that represents externally visible activities performed by
an object in terms of changes in its state.
OBJECT ORIENTED ANALYSIS and DESIGN
OBJECT ORIENTED ANALYSIS and DESIGN

A class represents a collection of objects having same characteristic

properties that exhibit common behavior. It gives the blueprint or
description of the objects that can be created from it. Creation of an
object as a member of a class is called instantiation. Thus, object is
an instance of a class.

The constituents of a class are:

• A set of attributes for the objects that are to be instantiated from
the class. Generally, different objects of a class have some
difference in the values of the attributes. Attributes are often
referred as class data.
• A set of operations that portray the behavior of the objects of the
class. Operations are also referred as functions or methods.
OBJECT ORIENTED ANALYSIS and DESIGN
OBJECT ORIENTED ANALYSIS and DESIGN
SYSTEMS ANALYSIS
Object Modelling
(Unified Modeling Language)
• Widely used method of visualizing and
documenting software systems
analysis and design

• Functional Models
• Use Case Diagrams (narratives)
• Activity Diagrams

• Structural Models
• Class Diagrams
• Object Diagrams

• Behavioral Models
• Sequence diagrams
FUNCTIONAL MODEL
USE CASE DIAGRAM
• A use case illustrates the
activities that are performed by
users of a system.

• Describe basic functions of the

system
• What the user can do
• How the system responds

• Use cases are building blocks for

continued design activities.
FUNCTIONAL MODEL
USE CASE DIAGRAM
• A use case describes how a user uses a
system to accomplish a particular goal.
A use case diagram consists of the
system, the related use cases and
actors and relates these to each other
to visualize:
• what is being described? (system),
• who is using the system? (actors)
and
• what do the actors want to
achieve? (use cases),

• Thus, use cases help ensure that the

correct system is developed by
capturing the requirements from the
user's point of view.
 Types of Use Cases
Amount of information

Overview Detail

High-level overview of issues Detailed description of issues

essential to understanding essential to understanding
Essential

required functionality required functionality

Purpose

High-level overview of a Detailed description of a specific

specific set of steps set of steps performed on the real
performed on the real system system once implemented
Real

once implemented
USE CASE DIAGRAM - NOTATIONS
USE CASE DIAGRAM
• Actor - individuals involved with the
system defined according to their roles.
The actor can be a human or other
external system.
• Use Case - describes how actors uses a
system to accomplish a particular goal.
Use cases are typically initiated by a user
to fulfill goals describing the activities
and variants involved in attaining the
goal.
• Relationship - The relationships
between and among the actors and the
use cases.
• System Boundary - The system
boundary defines the system of interest
in relation to the world around it.
USE CASE DIAGRAM - NOTATIONS
USE CASE DIAGRAM
• Actor - individuals involved with the • Use Case - describes how actors
system defined according to their uses a system to accomplish a
roles. The actor can be a human or particular goal. Use cases are
other external system. typically initiated by a user to fulfill
goals describing the activities and
variants involved in attaining the
goal.
USE CASE DIAGRAM - NOTATIONS
USE CASE DIAGRAM
• Relationship - The relationships • System Boundary - The system
between and among the actors boundary defines the system of
and the use cases. interest in relation to the world
around it.
Use Case Elements: Relationships
} Association
documents the communication between the use case and the actors that use
the use case
} Extend
represents the extension of the functionality of the use case to incorporate
optional behavior
} Include
shows the mandatory inclusion of another use case
} Generalization
allows use cases to support inheritance
USE CASE DESCRIPTION - FLOWS
USE CASE DESCRIPTION
• A text-based narrative of a functionality comprised of detailed.
step-by-step interaction between the actor and the systems. It
describes the outcomes of an action taken to accomplish a specific
goal.
ACTOR ACTION ORDER SYSTEM RESPONSE INVENTORY RESPONSE

1. Enter item number in Order 2. Perform check digit verification

System
3. Send item number to Inventory 4. Sends item item
System description to Order
System
5. Display item description

6. Enter quantity and reserve 7. Send reservation request to the 8. Sends Item Reserved
item Inventory System message to Order System
9. Display Item Reserved Message
USE CASE DESCRIPTION - FLOWS
} Triggers
• An event that initiates the flow of events in a use case. Triggers
can either be an actor action or a temporal event

• Actor Action – the most common trigger when an action taken

by the primary actor (input) initiates the use case

• Temporal Event – time-related events that trigger a use case.

Commonly used when actions need to be executed during a
specific time of day or on a specific date.

} Pre-Conditions
• Conditions that are assumed to be in place before the use case
can begin
USE CASE DESCRIPTION - FLOWS
} Post-Conditions
• Conditions in the form of guarantees that must be in place when
the use case is complete

} Normal Flows
• include only those steps that normally are executed in a use case
• the inputs from the actors and system responses that represent
the most common successful path to accomplish the actor’s goal

} Sub-Flows
• the normal flow of events decomposed to keep the normal flow
of events as simple as possible

} Alternate or Exceptional Flows

• flows that do happen but are not considered to be the norm
 Overview/ Relationship

Pre-condition
Post condition
Flows
Exceptional Flows
Use Case Name: Add a new vehicle to an existing policy
Scenario: Telephone instance with customer and clerk
Triggering Event: New vehicle
Brief Description: Customer provides car information, requests coverages with amounts, identifies drivers of the new car. System updates
the policy.
Actors: Customer service clerk
Stakeholders: Customer, customer service department
Preconditions: Customer policy must exist and be up to date.
StandardVehicle control tables for this vehicle type and year must exist.
StandardCoverage tables exist.
Postconditions: New vehicle object created and connected to policy.
Also connected to StandardVehicle.
New coverage objects created and connected to vehicle.
Also connected to StandardCoverage.
New driver (InsuredPerson) (if necessary) created and added to policy.
Existing drivers and percentages updated.
Policy updated with new premiums.
Flow of Events: Actor System
1. Clerk enters customer information 1.1 System finds policy and displays details
2. Clerk verifies policy is current. 3.1 System validates that car has known
3. Clerk enters car identification information standard.
4. Clerk enters each type of coverage customer requests, including 4.1 System validates coverage requests.
deductibles and coverage amount 5.1 System does combination validation on
5. Clerk indicates all coverages have been entered policy
6. Clerk invokes Add new person use case if necessary. 7.1 System updates driver information.
7. Clerk changes driver percentages on this car and other cars. 8.1 System updates policy, calculates new
8. Clerk indicates everything complete premium, prints new statement.
Exception Conditions: 2.1 If policy is not current, then clerk requests payment or collects necessary information.
3.1 If car type is not in system, clerk refers customer to underwriting to handle this situation.
4.1 If coverage requests are out of range, then clerk asks customer for changed amount.
5.1 If some combination is invalid, then return to step 4.
USE CASE DESCRIPTION - FLOWS

WHEN TO USE A USE CASE DESCRIPTION

1. To further refine use case diagram
2. To supplement or decompose a user story
3. To verify with subject matter experts that all possible
scenarios are accounted for
4. To communicate what the system will be used for to the
development and testing teams
5. To elicit suggestion from the development on technical
constraints
USE CASE DESCRIPTION - FLOWS

WHEN TO USE A USE CASE DESCRIPTION

6. To clearly narrate expected system responses and
outcomes
7. To show a sequential flow of events for a proposed
solution
8. To provide a simple representation of goals and
outcomes
9. To give stakeholders an opportunity to see if the narrative
aligns with their expectations
10. To provide a framework for testing.
Management Information
System

Lecture 7