The Systems Development Life Cycle
(SDLC)
INFT 447 3 CREDITS
Objectives
• The main objectives of the course is
• To enable students master Software Development Concepts.
• Principles, and Essential Processes of the SDLC.
• To demonstrate this knowledge by creating UML artifacts for
requirements gathering, analysis as well as design phases using
an object-oriented methodology.
Introductions
• A framework that describes the activities performed at
each stage of a software development project.
• Describes seven phases required to evolve an IT
system, from an initial feasibility study through
maintenance of the completed application.
•
1/22/2024
Phases of SDLC
• Problem definition
• Program design
• Coding
• Debugging
• Testing
• Documentation
• Maintenance
• Extension and Redesign
1/22/2024
The System Development Life Cycle
What are the phases of the system development cycle?
Phase 2. Analysis
▪ Conduct preliminary investigation
Phase 1. Planning ▪ Perform detailed analysis activities:
▪ Review project requests
Phase 3. Design
Study current system ▪ Acquire hardware
▪ Prioritize project Determine user requirements and software, if
requests necessary
Recommend solution
▪ Allocate resources ▪ Develop details of
▪ Identify project system
development team
Phase 5. Support Phase 4. Implementation
▪ Conduct post-implementation ▪ Develop programs, if necessary
system review ▪ Install and test new system
▪ Identify errors and enhancements ▪ Train users
▪ Monitor system performance ▪ Convert to new system
The System Development Life Cycle
Who participates
in the system
development life
cycle?
1/22/2024
Phase 1: Conceptual Planning
• It is during this phase that a need to acquire or
significantly enhance a system is identified, its
feasibility and costs are assessed, and the risks and
various project-planning approaches are defined.
Conceptual Planning-Considerations
• Evaluation criteria
➢ Strategic alignment: The extent to which the project
is viewed as helping the organization achieve its
strategic objectives and long-term goal.
➢ Potential benefits: The extent to which the project is
viewed as improving profits, customer service, and
the duration of the benefits.
Conceptual Planning-Considerations
• Potential costs and resource availability: The number
and types of resources the project requires and their
availability.
• Project size / duration: The number of individuals and
the length of time needed to complete the project
• Technical difficulty / risks: The level of technical
difficulty involved to complete the project within a
given time and resources.
Phase 2: Systems Analysis and user
requirements definition.
• This phase begins after the project has been defined and
appropriate resources have been committed. The user
requirements definition phase is based on the processes that
users conduct in their day-to-day activity.
• The user requirements should clearly describe what part of the
user process (activity) should be automated or enhanced, and
the expected capabilities and features.
• The key output of this phase is a summary document of user
requirements that explains what the system is supposed to do.
This phase also involves collecting, defining and validating
functional, support and training requirements.
Requirement Analysis and Design
• Design concepts –
• Design within the context of software engineering,
• Design Process, Design concepts, Design Model.
• Architectural Design - Software Architecture, Architectural Styles,
Architectural considerations, Architectural Design.
•Component level design – What is a component?
•Designing Class-Based Components,
•Conducting Component level design, Component level design for web-
apps.
1/22/2024
Requirement Analysis and Design
•Functional and non-functional requirements,
•Requirements engineering processes,
• Requirements elicitation, Requirements validation,
• Requirements change, Traceability matrix,
•Developing use cases, Software Requirements
• Specification Template, Personas, Scenarios,
•User stories, Feature identification.
1/22/2024
Requirements Engineering
• The process of establishing the services that the customer
requires from a system and the constraints under which it
operates and is developed.
• The requirements themselves are the descriptions of the
system services and constraints that are generated
during the requirements engineering process.
• It may range from a high-level abstract statement of a
service or of a system constraint to a detailed
mathematical functional specification.
•
1/22/2024
• User requirements-
• Statements in natural language plus diagrams of the services the
• system provides and its operational constraints. Written for
customers.
• System requirements-
• A structured document setting out detailed descriptions of the
system’s functions, services and operational constraints. Defines
what should be implemented so may be part of a contract between
client and contractor.
1/22/2024
1/22/2024
Functional and non-functional requirements
• Functional requirements-
Statements of services the system should provide, how the system should
react to
particular inputs and how the system should behave in particular situations.
May state what the system should not do.
• Non-functional requirements-
These define system properties and constraints e.g. reliability, response time
and storage requirements. Constraints are I/O device capability, system
representations, etc. Process requirements may also be specified mandating a
particular IDE, programming language or development method. Non-
functional requirements may be more critical than functional requirements. If
these are not met, the system may be useless.
Domain requirements
Constraints on the system from the domain of operation
1/22/2024
Types of NoN-functional Requirements
Requirements engineering processes
The processes used for Requirement Engineering vary widely depending on the application
domain, the people involved and the organisation developing the requirements. Requirement
Engineering is an iterative activity in which these processes are interleaved.
A spiral view of the requirements engineering process
1/22/2024
1. Requirements elicitation and analysis
• Sometimes called requirements elicitation or requirements discovery.
• Involves technical staff working with customers to find out about the
application domain, the services that the system should provide and the
system’s operational constraints.
• May involve end-users, managers, engineers involved in maintenance, domain
experts, trade unions, etc.
• These are called stakeholders.
Problems of requirements analysis
• Stakeholders don’t know what they really want.
• Stakeholders express requirements in their own terms.
• Different stakeholders may have conflicting requirements.
• Organisational and political factors may influence the system requirements.
• The requirements change during the analysis process. New stakeholders may
emerge and the business environment may change.
1/22/2024
Software engineers work with a range of system stakeholders to find out about the
application domain, the services that the system should provide, the required system
performance, hardware constraints, other systems, etc.
Stages include:
• Requirements discovery and understanding: process of interacting with
stake holders to discover their requirements. Domain requirements from
stakeholders and documentation are also discovered.
• Requirements classification and organization: this activity takes the
unstructured collection of requirements, groups related requirements and
organizes them into coherent clusters.
• Requirements prioritization and negotiation: when multiple stakeholders
are involved, requirements will conflict. This activity is concerned with
prioritizing requirements and finding and resolving requirements conflicts
1/22/2024
through negotiation.
The requirements elicitation and analysis process
1/22/2024
Requirements discovery (elicitation techniques)
The process of gathering information about the required and existing systems and distilling the
user and system requirements from this information.
Interaction is with system stakeholders from managers to external regulators. Systems normally
have a range of stakeholders.
✓ Interviewing
Formal or informal interviews with stakeholders are part of most RE processes.
Types of interview
• Closed interviews : stakeholders answers based on pre-determined list of questions
• Open interviews : in which there is no predefined agenda, where various issues are
explored with stakeholders
Effective interviewing
• Be open-minded, avoid pre-conceived ideas about the requirements and are willing to
listen to stakeholders.
• Prompt the interviewee to get discussions going using a springboard question, a
requirements proposal, or by working together on a prototype system.
Scenarios are real-life examples of how a system can be used. They should include:
1/22/2024
• A description of the starting situation;
• A description of the normal flow of events;
• A description of what can go wrong;
• Information about other concurrent activities;
• A description of the state when the scenario finishes.
Requirements specification
:
o The process of writing the user and system requirements in a requirements
document.
o User requirements have to be understandable by end-users and customers who
do not have a technical background.
o System requirements are more detailed requirements and may include more
technical information.
o The requirements may be part of a contract for the system development
o It is therefore important that these are as complete as possible.
Ways of writing a system requirements specification
1/22/2024
1/22/2024
System Analysis
➢ Collecting System Requirements: Requirement collection is process of
gathering and organizing information from users, managers, business
processes, an documents to understand how a proposed system should
work.
▪ System analysts use a variety of techniques to collect system
requirements
– Interviews: analysts interview people
– Questionnaires: analysts design and administer surveys.
– Observations: analysts observe workers at selected times
– Document analysis: analysts study business documents
▪ Critical Success Factors (CSF): analysts ask each person to define her
own personal CSFs.
▪ Joint Application Design (JAD): Special type of a group meeting
where all users and analysts meet at the same time
Phase 3: Systems Design
• The design phase is a complex and critical step in
determining which system design, based on systems
engineering and technology analysis, meets the user
and system requirements.
• During this phase, functional, support and training
requirements are translated into preliminary and
detailed designs.
• Decisions are made to address how the system will
meet functional requirements. For non-technical
solutions, the design may simply be a support process
to be implemented over time.
System Design
➢ Designing forms and reports
➢ Designing interfaces and dialogues
➢ Designing databases and files
➢ Designing processes and logic
Phase 4: Systems Development and Testing.
• The system development phase is the execution of the approved
design and in some cases may blend into the implementation
phase.
• A smaller test system is sometimes a good idea in order to get a
“proof-of-concept” validation prior to committing funds for large
scale fielding of a system without knowing if it really works as
intended by the user.
Phase 4: Systems Development and Testing.
• During this phase, systems are developed or acquired based on
detailed design specifications. The system is validated through a
sequence of unit, integration, performance, system, and
acceptance testing. The objective is to ensure that the system
functions as expected and that sponsor's requirements are
satisfied.
• This phase requires strong user participation in order to verify
thorough testing of all requirements and to meet all business
needs.
System Dev’t & Testing
➢ Software programming
➢ Software testing
▪ Developmental: Programmers test the correctness of
individual modules and the integration of multiple modules.
▪ Alpha: Software tester tests whether it meets design
specifications.
▪ Beta: Actual system users test the capability of the system
in the user environment with actual data.
Phase 5: Systems Implementation.
• Implementation includes all necessary activity to procure,
receive, configure, and install the new or revised system.
• During this phase, the new or enhanced system is installed in
the production environment, users are trained, data is converted
(as needed), the system is turned over to the sponsor, and
business processes are evaluated.
• This phase includes efforts required to implement, resolve
system problems identified during the implementation process,
and plan for sustainment.
System Implementation
➢ System conversion
▪ Parallel
▪ Direct
▪ Phased
▪ Pilot
➢ System documentation, training, and support
▪ User and reference guides
▪ Training and tutorials
▪ Installation procedures and troubleshooting guides
Phase 6: Operations and Maintenance
• The system becomes operational during this phase.
The emphasis during this phase is to ensure that
sponsors’ needs continue to be met and that the system
continues to perform according to specifications by
conducting maintenance and enhancements as
determined by periodic reviews.
Phase 6: Operations and Maintenance
• Hardware and software maintenance and upgrades are
performed to ensure effective system operations.
• User training continues during this phase, as needed, to
acquaint new users to the system or to introduce new
features to current users. Additional user support is
provided, as an ongoing activity, to help resolve
reported problems.
Maintenance and Review
• Maintenance (correcting bugs &
scheduled maintenance)
• Enhancement (adding functionality)
Phase 7: Systems disposition
• This phase represents the end of the system's life cycle.
It provides for the systematic termination of a system
to ensure that vital information is preserved for
potential future access and/or reactivation.
• The system, when placed in the Disposition Phase, has
been declared surplus and/or obsolete and has been
scheduled for shutdown.
•
Phase 7: Systems disposition
• The emphasis of this phase is to ensure that the system
(e.g., equipment, parts, software, data, procedures, and
documentation) is packaged and disposed of in
accordance with appropriate regulations and
requirements.
SDLC - Advantages
Focus on goals
• Controls: milestones, checklist, accountability
• Involves the use of CASE tools (Computer Aided
Software Engineering)
• Hierarchical decomposition
• Designed for user & manager involvement
SDLC - Reasons for Failure
• Scope too broad or too narrow
• Lack of needed skills
• Incomplete specifications
• Lack of management/user involvement
• Too time-consuming
Other Terminology for SDLC phases
• Many organizations and many authors use different
terminology for the phases of the SDLC
• However essentially the same activities are performed.
• Refer to examples of other terminology
