DIT 201 System Analysis and

Design
Chapter 2: System Development Life Cycle

Presented by: Mr. Nicholas Kavoi

 Lesson Objectives

By the end of the class you should be able to:

i. Illustrate the SDLC listing it’s deliverables
ii. Discuss the phases of the SDLC
iii. Understand problem definition
iv. List the contents of a TOR
v. Discuss requirement elicitation types
vi. Discuss Feasibility study and the different types of
Feasibility study
 Introduction
System development life cycle (SDLC) is the lifespan of a system
from it’s inception until it is implemented or redesigned. It’s
usually refereed to as the systematic study and an orderly
approach to solving system problems. It involves the following
phases:
i. Problem Definition – Terms of Reference
ii. Preliminary Investigation – Feasibility Report
iii. System Analysis – Requirement Specification Document
iv. System Design – System Design Document
v. System Implementation – System Documentation
vi. System Maintenance – System Maintenance Report
 SDLC
Problem
Definition

System Preliminary
Maintenance Investigation

System
System Analysis
Implementation

System Design
 Phases in Summary
• Problem Definition : Clearly describe the problem or need
that the system aims to solve. This involves articulating the
current situation, identifying gaps, inefficiencies, or issues
within existing systems or processes.
• Preliminary Investigation: It involves the system analyst
investigating the current system, recording facts and
analyzing them with a view of designing a new system. It
involves:
i. Feasibility study
ii. Requirement Elicitation
 Phases in Summary
• System analysis: This phase uses the data/requirements
obtained from the preliminary investigation stage to create
different system models and structures that help the system
analyst to understand the system requirements. Analysis is an
Iterative process that takes place through out the
development process as new data and structures are unveiled
• System Design: Involves translating the requirements into a
form that can be implemented into a system. Whereas system
analysis focuses on logical implementation, design deals with
the physical implementation ie Technical specification
 Phases in Summary
• System Implementation: This Translates the design
Document into a software Product that can be used
to carry out the intended processing tasks

• System Maintenance: Makes the software product

easy to use and change in order to meet new user
and functional requirements
 Variations of SDLC

Different methodologies and models can be applied within the SDLC

framework, including:
Waterfall Model: A linear and sequential approach where each phase must
be completed before the next begins.
Agile Model: An iterative and incremental approach that promotes flexibility
and customer collaboration.
V-Model: An extension of the waterfall model that emphasizes verification
and validation at each stage.
Spiral Model: Combines iterative development with risk assessment and
prototyping.
DevOps: Integrates development and operations to enhance collaboration
and improve efficiency.
 Problem Definition
• This is a description detailing of an investigation that
has to be carried out and what the system does. At
this point a preliminary survey is conducted to
ascertain whether they is need for change. If change
is necessary an investigation is carried out and terms
of reference are drawn
• Terms of reference(TOR) is a formal document that
guides analysts and users of objectives to be
achieved.
 Contents of a TOR
• Title of the project
• Purpose of the study
• Project Schedule(Timetable)
• Constraints analysts will meet during the study
• Subject of Study
• Professionals involved in the project
• Necessary Materials to be used in the project
 Preliminary Investigation
• It’s divided into:
• Requirement Elicitation
• Feasibility Study
 Requirement elicitation Techniques
• Requirement elicitation is the process of gathering
requirements from stakeholders and other sources to
understand what the system should do. It is a crucial
phase in the system development life cycle (SDLC) as
it helps ensure that the system meets the needs of its
users and stakeholders.
 Common Requirement Elicitation Techniques

1. Interviews
2. Surveys/Questionnaires
3. Workshops
4. Observation
5. Document Analysis
6. Focus Groups – Student to research on
7. Brainstorming – Student to research on
 Interviews

Interviews involve direct, one-on-one or group discussions with

stakeholders to gather detailed information about their needs and
expectations.
Advantages:
In-depth Information: Allows for detailed, qualitative insights.
Clarification: Enables immediate clarification of ambiguities.
Personal Interaction: Builds rapport and trust with stakeholders.
Disadvantages:
Time-Consuming: Can be lengthy, especially with multiple
stakeholders.
Bias: Potential for interviewer or interviewee bias.
Costly: Requires significant time and resources to conduct.
 Surveys/Questionnaires

Surveys and questionnaires collect information from a large

number of stakeholders using structured forms with predefined
questions.
Advantages:
Broad Reach: Can gather data from a large number of participants.
Cost-Effective: Less expensive than conducting multiple interviews.
Quantifiable: Easy to analyze statistically.
Disadvantages:
Limited Depth: May not provide deep insights.
Misinterpretation: Questions might be misunderstood without
immediate clarification.
Response Rate: Low response rates can affect data quality.
 Workshops

Workshops bring together multiple stakeholders to

collaboratively discuss and define requirements.
Advantages:
Collaborative: Encourages stakeholder collaboration and
consensus.
Diverse Perspectives: Brings together different viewpoints.
Efficient: Can gather a lot of information quickly.
Disadvantages:
Logistics: Challenging to organize and schedule.
Dominance: Risk of dominant personalities overshadowing others.
Costly: Can be expensive to facilitate.
 Observation

Observation involves watching stakeholders in their natural environment to

understand how they interact with current systems and processes. Observation is
particularly useful for understanding workflow and user interactions in detail,
especially when users may not be able to articulate their needs clearly.
Advantages:
Real-World Insight: Provides genuine insights into user behavior.
Contextual Understanding: Helps understand the context of requirements.
Non-Intrusive: Can be conducted without disrupting normal work.
Disadvantages:
Limited Scope: Only captures observable behaviors and may miss important but less
visible aspects.
Time-Intensive: Conducting thorough observations requires a significant time
investment.
Hawthorne Effect: People may alter their behavior if they know they are being
observed, potentially biasing the results.
 Document Analysis/Record Inspection

• It’s a requirement elicitation technique used to gather

information from existing documentation to
understand the system requirements, context, and
constraints.
• This method involves reviewing and extracting
relevant information from various documents that are
pertinent to the project. It is particularly useful in
projects where there is a wealth of existing
documentation that can provide historical context,
detailed specifications, and background information.
 Document Analysis/Record Inspection

Advantages:
Historical Insight: Provides background and context by reviewing existing
documentation, which can be useful for understanding the evolution of
requirements.
Cost-Effective: Utilizing existing documents is generally inexpensive.
Detailed Information: Can uncover detailed and specific requirements,
especially technical and operational details.
Disadvantages:
Outdated Information: Documents may not reflect current needs or
processes.
Interpretation: Requires careful interpretation to ensure that the
information is relevant and accurate.
Gaps: Documents might not cover all necessary aspects of the requirements.
 Factors to consider when selecting a requirement Elicitation Tool

i. Complexity of the project

ii. Stakeholder Availability
iii. Budget
iv. Time Constraints
 Feasibility Study

• A feasibility study is an analysis that evaluates the

viability of a proposed project or system. It aims to
determine whether the project is technically,
economically, legally, operationally, and schedule-
wise feasible. Conducting a feasibility study helps in
identifying potential risks and benefits, and in making
informed decisions about proceeding with the project.
 Objectives of a Feasibility Study

• Assess the practicality of the project.

• Identify potential obstacles and risks.
• Estimate the required resources (time, money,
technology, personnel).
• Provide a basis for decision-making.
• Ensure that the project aligns with organizational
goals and objectives.
 Types of Feasibility Studies

• Economic Feasibility
• Technical Feasibility
• Legal Feasibility
• Operational Feasibility
• Social Feasibility
• Schedule Feasibility
 Technical Feasibility

Technical feasibility assesses whether the proposed technology and

technical resources are available and capable of meeting the
requirements of the project.
Factors to Consider:
i. Technology: Availability and suitability of the technology
required.
ii. Technical Expertise: Availability of technical skills and expertise.
iii. System Requirements: Compatibility with existing systems and
infrastructure.
iv. Scalability: Ability to scale up as the project grows.
v. Reliability: Ensuring the system will function reliably under
expected conditions.
 Legal Feasibility

Legal feasibility examines whether the project complies with

legal and regulatory requirements.
Factors to consider:
i. Regulatory Compliance: Adherence to industry regulations
and standards.
ii. Legal Restrictions: Any legal constraints that may affect
the project.
iii. Intellectual Property: Issues related to patents, trademarks,
and copyrights.
iv. Contracts and Agreements: Analysis of any contractual
obligations.
 Operational Feasibility

Operational feasibility assesses whether the project can be

integrated into the organization’s operations and if it will function
as intended.
Factors to Consider:
i. Operational Impact: Effect on current operations and
workflows.
ii. User Acceptance: Likelihood of user acceptance and adoption.
iii. Support and Maintenance: Availability of support and
maintenance resources.
iv. Organizational Fit: Alignment with organizational culture and
goals.
 Social Feasibility

Social feasibility is a type of feasibility study that

evaluates the social implications and acceptance of a
proposed project or system.
It focuses on understanding how the project will impact
stakeholders, communities, and society at large.
Assessing social feasibility helps ensure that the project
aligns with social norms, values, and expectations, and
that it will be accepted and supported by those it affects.
 Schedule Feasibility

Schedule feasibility evaluates whether the project can be

completed within the desired timeframe.
Factors to Consider:
i. Project Timeline: Realistic project schedule and
milestones.
ii. Resource Availability: Availability of resources when
needed.
iii. Critical Path Analysis: Identifying critical tasks and their
dependencies.
iv. Deadline Constraints: Any hard deadlines that must be
met.
 Review

By now you should be able to:

i. Illustrate the SDLC listing it’s deliverables
ii. Discuss the phases of the SDLC
iii. Understand problem definition
iv. List the contents of a TOR
v. Discuss requirement elicitation types
vi. Discuss Feasibility study and the different types of
Feasibility study