IS 501

Systems Analysis & Design

Philip Ayoo, PhD

payoo@utamu.ac.ug
+256 772 666507

Feb 27 2021, 11am – 2pm

 Systems Development Life
Cycle (SDLC)

References
1. Hoffer, J., George, J., and Valacich, J., (2000) Modern Systems Analysis and Design,
Second Edition. Pearson Education.
2. Ayoo, P. O. (2009) A Requirements Analysis Framework for Human Activity Systems
(HAS): the Case of Online Learning. International Journal of Computing and ICT
Research, 3(1), 12-25.
 Systems Development Life Cycle (SDLC)
• Traditional methodology for developing, maintaining,
and replacing information systems
• Phases in SDLC:
– Planning
– Analysis
– Design
– Implementation
– Maintenance
Standard View of SDLC
 SDLC Planning Phase

Identify, analyze,
prioritize, and
arrange IS needs
 SDLC Analysis Phase

Study and
structure system
requirements
 SDLC Design Phase

Logical design:
Convert functional features
recommended described
solution to system independently of
computer platform
specifications

Physical design:
logical
specifications
transformed to
technology-
specific details
 SDLC Implementation Phase

Code, test, install,

and support the
information system
 SDLC Maintenance Phase

Systematically
repair and
improve the
information
system
Products of SDLC Phases
The Heart of the Systems Development Process
Current practice
combines
analysis, design,
and
implementation
into a single
iterative and
parallel process
of activities
Traditional Waterfall SDLC
One phase
begins when
another
completes,
little
backtracking
and looping
 Problems with Waterfall Approach

• System requirements “locked in” after being

determined (can't change)
• Limited user involvement (only in requirements
phase)
• Too much focus on milestone deadlines of SDLC
phases to the detriment of sound development
practices
 Alternatives to Traditional Waterfall SDLC
• Prototyping
• CASE tools
• Joint Application Design (JAD)
• Rapid Application Development (RAD)
• Agile Methodologies
• eXtreme Programming
Prototyping
Iterative
development
process:
Requirements
quickly converted
to a working
system
System is
continually revised
Close
collaboration
between users and
analysts
 CASE Tools
• Computer-Aided Software Engineering
• Software tools providing automated support
for systems development
• Project dictionary/workbook: system
description and specifications
• Diagramming tools
• Example products: Oracle Designer, Rational
Rose
 Joint Application Design (JAD)

• Structured process involving users, analysts,

and managers
• Several-day intensive workgroup sessions
• Purpose: to specify or review system
requirements
 Rapid Application Development (RAD)
• Methodology to decrease design and implementation time
• Involves: prototyping, JAD, CASE tools, and code generators
 Agile Methodologies
• Motivated by recognition of software development
as fluid, unpredictable, and dynamic
• Three key principles
– Adaptive rather than predictive
– Emphasize people rather than roles
– Self-adaptive processes
 eXtreme Programming
• Short, incremental development cycles
• Automated tests
• Two-person programming teams
• Coding and testing operate together
• Advantages:
– Communication between developers
– High level of productivity
– High-quality code
 Object-Oriented Analysis and Design
• Based on objects rather than data or processes
• Object: a structure encapsulating attributes and
behaviors of a real-world entity
• Object class: a logical grouping of objects sharing
the same attributes and behaviors
• Inheritance: hierarchical arrangement of classes
enable subclasses to inherit properties of super-
classes
Planning
Planning – Project Identification and Selection
 Project Identification Tasks

• Identifying potential development projects

– Identification from a stakeholder group
• Classifying and ranking potential IS projects
– Using value chain analysis or other evaluation
criteria
• Selecting projects
– Based on various factors
Each stakeholder group brings their own perspective and
motivation to the IS decision
 Information Systems Planning (ISP)

• An orderly means of assessing the information

needs of an organization and defining systems,
databases, and technologies that will best meet
those needs
• ISP must be done in accordance with the
organization's mission, objectives, and
competitive strategy.
 Approaches to IS Planning
• Top-down planning
– Attempts to gain a broad understanding of
information system needs of the entire organization
• Bottom-up planning
– Identifies IS development projects based on solving
specific operational business problems or taking
advantage of specific opportunities
Project Initiation and Planning
 Deliverables and Outcomes
• Business Case
– Justification for an information system, expressed as tangible and intangible costs and
benefits, and technical/organizational feasibility
• Baseline Project Plan (BPP)
– a document intended primarily to guide the development team
– Sections: introduction, system description, feasibility assessment, management issues
• Statement of Work (SOW)
– a “contract” between the IS staff and the customer regarding deliverables and time
estimates for a system development project
• System Service Request (SSR)
– a form requesting development or maintenance of an information system
– includes the contact person, a problem statement, a service request statement, and
liaison contact information
 Assessing Project Feasibility
• Economic feasibility
– Cost-benefit analysis: identify all the financial benefits and costs associated with a project
• Technical feasibility
– Assessing the organization’s ability to construct the proposed system
• Operational feasibility
– Does the proposed system solve problems or take advantage of opportunities?
• Schedule feasibility
– Can the project time frame and completion dates meet organizational deadlines?
• Legal and contractual feasibility
– What are legal and contractual ramifications of the proposed system development project?
• Political feasibility
– How do key stakeholders view the proposed system?
 Types of Costs and Benefits
• Tangible: can be measured in dollars/UGX and
with certainty
• Intangible: cannot easily be measured in
dollars or with certainty
• One-time: a cost associated with project
start-up and development or systems start-up
• Recurring: a cost associated with ongoing
evolution and use of a system
 Possible IS Project Costs
• Procurement
– Consulting, equipment, site preparation, capital, management
time
• Start-up
– Operating systems, communications installation, personnel
hiring, organizational disruption
• Project-related
– Application software, software modification, personnel
overhead, training, data analysis, documentation
• Operating
– System maintenance, rental, asset depreciation, operation and
planning
Analysis
System Requirements Determination
 Deliverables of Requirements Determination
• From interviews and observations
– Interview transcripts, observation notes, meeting minutes
• From existing written documents
– Mission and strategy statements, business forms,
procedure manuals, job descriptions, training manuals,
system documentation, flowcharts
• From computerized sources
– JAD session results, CASE repositories, system prototype
displays and reports
 Traditional Requirements Determination Methods
• Interviewing individuals
– Dialogue with user or manager to obtain their requirements
– Two forms:
• Open-ended: conversational, questions with no specific answers in mind
• Closed-ended: structured, questions with limited range of possible answers

• Interviewing groups
– Interview several key people together
– Nominal Group Technique (NGT) – facilitated process that supports idea generation by
groups
• Direct Observation
– Watching users do their jobs
– Can provide more accurate information than self-reporting (like questionnaires and interviews)
• Document Analysis
– Review of existing business documents
– Can give a historical and “formal” view of system requirements
 Contemporary Methods for Determining Requirements
• Joint Application Design (JAD)
– Brings together key users, managers, and systems analysts
– Purpose: collect system requirements simultaneously from key people
– Conducted off-site
• Group Support Systems
– Facilitate sharing of ideas and voicing of opinions about system requirements
• CASE tools
– Used to analyze existing systems
– Help discover requirements to meet changing business conditions
• System prototypes
– Iterative development process
– Rudimentary working version of system is built
– Refine understanding of system requirements in concrete terms
 Business Process Reengineering (BPR)
• Search for and implementation of radical change in business processes
to achieve breakthrough improvements in products and services
• Disruptive technologies
– Technologies that enable the breaking of long-held business rules that inhibit
organizations from making radical business changes
• Goals
– Reorganize complete flow of data in major sections of an organization
– Eliminate unnecessary steps
– Combine steps
– Become more responsive to future change
• Identify specific activities that can be improved through BPR
Long-held organizational rules that are being eliminated through disruptive technologies
 Agile Methodologies for Requirements Determination

• Continual user involvement

– Replace traditional SDLC waterfall with iterative
analyze–design–code–test cycle
• Agile usage-centered design
– Focuses on user goals, roles, and tasks
• Based on eXtreme programming
– Exploration, steering, commitment
 Agile Usage-Centered Design Steps
• Gather group of programmers, analysts, users, testers,
facilitator
• Document complaints of current system
• Determine important user roles
• Determine, prioritize, and describe tasks for each user
role
• Group similar tasks into interaction contexts
• Associate each interaction context with a user
interface for the system, and prototype the interaction
context
• Step through and modify the prototype
Requirements Structuring
 Process Modeling
• Graphically represent the processes that capture, manipulate, store, and
distribute data between a system and its environment and among system
components
– Utilize information gathered during requirements determination
– Processes and data structures are modeled
• Data Flow Diagram (DFD)
– A picture of the movement of data between external entities and the
processes and data stores within a system
– Difference from system flowcharts:
• DFDs depict logical data flow independent of technology
• Flowcharts depict details of physical systems
 Process Modeling: Deliverables and Outcomes
• Context data flow diagram (DFD)
– Scope of system
• DFDs of current physical and logical system
– Enables analysts to understand current system
• DFDs of new logical system
– Technology independent
– Show data flows, structure, and functional requirements
of new system
• Thorough description of each DFD component
DFD Symbols
 DFD Symbols
• Process: work or actions performed on data (inside
the system)
• Data store: data at rest (inside the system)
• Source/sink: external entity that is origin or
destination of data (outside the system)
• Data flow: arrows depicting movement of data
DFD Diagramming Rules: Process

No process can
have only outputs
or only inputs…
processes must
have both outputs
and inputs.

Process labels should be verb phrases.

DFD Diagramming Rules: Data Store

All flows to or from a data store must

move through a process.

Data store labels should be noun phrases.

 DFD Diagramming Rules: Source/Sink

No data moves directly between external entities without going through a

process.

Interactions between external entities without intervening processes are outside

the system and therefore not represented in the DFD.

Source and sink labels should be noun phrases.

DFD Diagramming Rules: Data Flow

Bidirectional flow
between process
and data store is
represented by two
separate arrows.

Forked data flow

must refer to exact
same data item (not
different data items)
from a common
location to multiple
destinations.
DFD Diagramming Rules: Data Flow (cont.)

Joined data flow

must refer to exact
same data item (not
different data items)
from multiple
sources to a
common location.

Data flow cannot

go directly from a
process to itself,
must go through
intervening
processes.
 DFD Diagramming Rules: Data Flow (cont.)

• Data flow from a process to a data store means

update (insert, delete or change).
• Data flow from a data store to a process means
retrieve or use.
• Data flow labels should be noun phrases.
 Functional Decomposition

• An iterative process of breaking a system

description down into finer and finer detail
• High-level processes described in terms of lower-
level sub-processes
• DFD charts created for each level of detail
 DFD Levels
• Context DFD
– Overview of the organizational system
• Level-0 DFD
– Representation of system’s major processes at high
level of abstraction
• Level-1 DFD
– Results from decomposition of Level 0 diagram
• Level-n DFD
– Results from decomposition of Level n-1 diagram
 Context Diagram: Food Ordering System

Context diagram
shows the system
boundaries,
external entities
that interact with
the system, and
major information
flows between
entities and the
system.

NOTE: only one process symbol, and no data stores

shown.
 Level-0 DFD: Food Ordering System

Level-0 DFD
shows the
system’s
major
processes,
data flows,
and data
stores at a
high level of
abstraction.

Processes are labeled 1.0, 2.0, etc. These will be decomposed

into more primitive (lower-level) DFDs.
 Level-1 DFD: Decomposition of Process 4.0
Level-1 DFD shows
the sub-processes
of one of the
processes in the
Level-0 DFD.

This is a Level-1
DFD for Process
4.0.

Processes are labeled 4.1, 4.2, etc. These can be further

decomposed in more primitive (lower-level) DFDs if necessary.
 Level-n DFD: Decomposition of Process 4.3
Level-n DFD
shows the
sub-processes
of one of the
processes in
the Level n-1
DFD.

This is a
Level-2 DFD
for Process
4.3.
Processes are labeled 4.3.1, 4.3.2, etc. If this is the lowest
level of the hierarchy, it is called a primitive DFD.
 Use Cases
• Depiction of a system’s behavior or
functionality under various conditions as the
system responds to requests from users

• Full functioning for a specific business purpose

UML Use Case Diagram Symbols

Use Case
Actor
Boundary
Connection
<<include>> Include relationship
<<extend>>
Extend relationship
 Definitions
Use case
• a set of actions, services, and functions that the system needs to perform.
Actor
• Actor is an external entity that interacts with the system.
• Most actors represent user roles, but actors can also be external systems.
• An actor is a role, not a specific user; one user may play many roles, and an actor may
represent many users.
Boundary
• A boundary is the dividing line between the system and its environment.
• Use cases are within the boundary.
• Actors are outside of the boundary.
Connection
• A connection is an association between an actor and a use case.
• Depicts a usage relationship
• Connection does not indicate data flow
 Definitions…
<<extend>> Relationship
• A connection between two use cases
• Extends a use case by adding new behavior or actions
• Specialized use case extends the general use case
<<include>> Relationship
• A connection between two use cases
• Indicates a use case that is used (invoked) by another use case
• Links to general purpose functions, used by many other use cases
<<extend>> - University Registration System
<<include>> - Order System
 Written Use Cases

• Document containing detailed specifications for a

use case

• Contents can be written as simple text or in a

specified format
 Logic Modeling
• Data flow diagrams do not show the logic inside
the processes.
• Logic modeling involves representing internal
structure and functionality of processes depicted
on a DFD.
• Logic modeling can also be used to show when
processes on a DFD occur.
 Logic Modeling Deliverables and Outcomes
• Structured English
– Modified form of English used to specify the logic of information processes
• Decision Tables
– A matrix representation of the logic of a decision
• Decision Trees
– A graphical representation of a decision situation
• State-transition diagrams
• Sequence diagrams
see object-oriented design
• Activity diagrams
Inventory Control System Structured English Representation

Dataflow Diagram
Requirements Structuring – Data Modeling
Relationship between data modeling and SDLC
 Conceptual Data Modeling
• A detailed model that captures the overall structure of data in
an organization
• Independent of any database management system (DBMS) or
other implementation considerations
 Process of Conceptual Data Modeling
• Develop a data model for the current system
• Develop a new conceptual data model that
includes all requirements of the new system
• In the design stage, the conceptual data model is
translated into a physical design
• Project repository links all design and data
modeling steps performed during SDLC
 Deliverables and Outcome
• Primary deliverable is an entity-relationship (E-R)
diagram or class diagram
• Various E-R or class diagrams are produced and
analyzed
– E-R diagrams for the application being replaced and
for the new application
• Second deliverable is a set of entries about data
objects to be stored in repository or project dictionary.
– Repository links data, process, and logic models of
an information system
Sample Conceptual Data Model
 Gathering Information for Conceptual Data Modeling

• Two perspectives
–Top-down
• Data model is derived from an intimate
understanding of the business.
–Bottom-up
• Data model is derived by reviewing
specifications and business documents.
 Requirements Determination Questions for Data Modeling
• What are subjects/objects of the business?
 Data entities and descriptions
• What unique characteristics distinguish between subjects/objects of the same type?
 Primary keys
• What characteristics describe each subject/object?
 Attributes and secondary keys
• How do you use the data?
 Security controls and user access privileges
• Over what period of time are you interested in the data?
 Cardinality and time dimensions
• Are all instances of each object the same?
 Supertypes, subtypes, and aggregations
• What events occur that imply associations between objects?
 Relationships and cardinalities
• Are there special circumstances that affect the way events are handled?
 Integrity rules, cardinalities, time dimensions
 Introduction to Entity-Relationship (E-R) Modeling

• Entity-Relationship (E-R) Diagram

–A detailed, logical representation of the entities,
associations and data elements for an organization
or business
• Notation uses three main constructs
–Data entities
–Relationships
–Attributes
 Association
between the
instances of one or
more entity types

Person, place, object, named property or

event or concept about characteristic of an
which data is to be entity
maintained
Entity type: collection of
entities with common
characteristics
Entity instance: single
entity
 Identifier Attributes

• Candidate key
– Attribute (or combination of attributes) that uniquely identifies each instance of
an entity type
• Identifier
– A candidate key that has been selected as the unique identifying characteristic for
an entity type
• Selection rules for an identifier
1. Choose a candidate key that will not change its value.
2. Choose a candidate key that will never be null.
3. Avoid using intelligent keys.
4. Consider substituting single value surrogate keys for large composite keys.
 Multivalued Attributes
• An attribute that may take on more than one value
for each entity instance
• Represented on E-R Diagram in two ways:
–double-lined ellipse
–weak entity
 Entity and Attribute Example
Simple attributes

Identifier Multivalued
attribute… each attribute… an
employee has a employee may have
unique ID. more than one skill.
 Degree of Relationship
• Degree: number of entity types that participate in a relationship
• Three cases
– Unary: between two instances of one entity type
– Binary: between the instances of two entity types
– Ternary: among the instances of three entity types
Example Relationships of Different degrees
 Associative Entities
• An entity type that associates the instances of one or
more entity types and contains attributes that are
peculiar to the relationship between those entity
instances
• An associative entity is:
– An entity
– A relationship
• This is the preferred way of illustrating a relationship with
attributes
A relationship with an attribute

…as an associative entity

Ternary relationship

…as an associative entity

A
relationship
that itself is
related to
other entities
via another
relationship
must be
represented
as an
associative
entity.
 Supertypes and Subtypes
• Subtype: a subrouping of the entities in an entity type that shares
common attributes or relationships distinct from other subtypes
• Supertype: a generic entity type that has a relationship with one or
more subtype
• Rules for Supertype/Subtypes Relationships
– Total specialization: an entity instance of the supertype must be an
instance of one of the subtypes
– Partial specialization: an entity instance of the supertype may or may not
be an instance of one of the subtypes
– Disjoint: an entity instance of the supertype can be an instance of only one
subtype
– Overlap: an entity instance of the supertype may be an instance of multiple
subtypes
Example of supertype/subtype
 Object Modeling Using Class Diagrams
• Object-oriented approach
• Based on Unified Modeling Language (UML)
• Object: an entity with a well-defined role in an application
• Each object has:
– State: encompasses the attributes, their values, and relationships of an object
– Behavior: represents how an object acts and reacts
– Identity: uniqueness, no two objects are the same
• Features
– Objects and classes
– Encapsulation of attributes and operations
– Polymorphism
– Inheritance
 Classes
• Class: a logical grouping of objects with similar
attributes and behaviors
• Operation: a function or service provided by all
instances of a class
• Encapsulation: the technique of hiding internal
implementation details of an object from external
view
 Class Diagram
• A diagram showing the static structure of an object-
oriented model
UML class diagram showing 2 classes
 Types of Operations
• Constructor
– Creates a new instance of a class
• Query
– Accesses the state of an object
• Update
– Alters the state of an object
• Scope
– Applies to a full class rather than an individual instance
 Representing Associations
• Association: a relationship among instances of
object classes
• Association role: the end of an association where
it connects to a class
• Multiplicity: indicates how many objects
participate in a given relationship
Examples of Association Relationships of Different Degrees

UML
associations
are analogous
to E-R
relationships.

UML
multiplicities
are analogous
to E-R
cardinalities.
 Generalization
• Superclass-subclass relationships
• Subclass inherits attributes, operations, and
associations of the superclass
• Types of superclasses
–Abstract: cannot have any direct instances
–Concrete: can have direct instances
 Example of Generalization, Inheritance, and Constraints

Generalization and inheritance implemented via superclass/subclasses in

UML, supertypes/subtypes in E-R
 Polymorphic Operations
• The same operation may apply to two or more
classes in different ways
• Abstract operations
–defined in abstract classes
–define the protocol, but not the implementation of
an operation
• Methods
–the implementation of an operation
Polymorphism, Abstract Operation, Class-Scope Attribute, and Ordering

Abstraction:
Student is an abstract class and calc-
tuition() is an abstract operation (italicized)

Polymorphism:
Here, each type of student has
its own version of calc-tuition()

Class scope: tuitionPerCred is a class-wide attribute

 Aggregation and Composition

• Aggregation
–A part-of relationship between a component and
an aggregate object
• Composition
–An aggregation in which the part object belongs to
only one aggregate object and lives and dies with
the aggregate object
Aggregation and Composition

Aggregation is represented with

open diamonds

Composition is represented with

filled diamonds
 IS 501
Systems Analysis & Design

Philip Ayoo, PhD

payoo@utamu.ac.ug
+256 772 666507

Feb 27 2021, 11am – 2pm