AICT Lecture 09 System Development LIfe Cycle (1)
AICT Lecture 09 System Development LIfe Cycle (1)
Communication Technologies
Fall 2024
Course Instructor:
Ms. Seemab Khan- Lecturer (Software Engineering )
Department of Creative Technologies
Air University - Islamabad
[email protected]
Lecture 9: System Development Life
Cycle
Requirement Analysis
Requirement Design
Requirement Implementation
Requirement Testing
Requirement Evolution
System Development Life Cycle :
SDLC
The Basics of Application Software
• Software ownership rights: Specify the allowable use of the program
• Software license: Specifies the conditions under which a buyer of the
program can use it
SDLC.
➢ Planning for the quality assurance requirement and identification of the
➢ Once the requirement analysis is done the next step is to clearly define
and document the software requirements and this is done through ‘SRS’.
➢ Software requirement specification(SRS) document which consists of all
Elicitation
Analysis Requirement
s Elicitation
• Analysis goes hand in hand with modeling
Requirement Analysis (Contd…)
• The process of studying and analyzing the user needs to arrive at a
definition of the problem domain and system requirements
• What is it?
• The process by which customer needs are understood and
documented.
• Expresses “what” is to be built and NOT “how” it is to be
built.
• Example 1:
• The system shall allow users to withdraw cash. [What?]
• Example 2:
• A sale item’s name and other attributes will be stored in a hash table
and updated each time any attribute changes. [How?]
Questions
• Requirements can be specified in terms of structure,
standards and writing rules but:
• How to identify the real problems to solve in elicitation
results?
• How to detect conflicting aspects?
• How to negotiate to resolve conflicts?
• How to decide what is important and priority?
• How to ensure that nothing is forgotten?
• How to validate that the findings of the analysis are good?
• How to use models in this context?
How to find the real problems?
• Ask : Why ?
• Root Cause analysis
• Recursively determine the factors that contribute to the problems
founds by the stakeholders
• All causes do not have the same impact nor the same weight
• Some may perhaps not deserve to be corrected, at least for the
moment
• Goal- Oriented modeling can help understand these causes and their
relationships
• This analysis identifies problems that need to be solved.
SDLC
Phase 03: Designing the Software
• Use-Case Approach:
• Formalization of usage-centered perspective to requirements elicitation
and modeling.
• Works well for business applications, Web sites, services that one system
provides to another, and systems that let a user control a piece of
hardware.
• Event-Response Tables:
• Applications such as batch processes, computationally intensive systems,
might have just a few simple use cases.
• The complexity of these applications lies in the computations performed
or the reports generated, not in the user-system interaction.
• A requirements technique often used for real-time systems is to list the
external events to which the system must react and the corresponding
system responses.
The Use-Case Approach
• A use case describes a sequence of interactions between a system and an
actor.
• An actor is a person, another software system, or a hardware device that
interacts with the system to achieve a useful goal.
• Another name for actor is user role, because actors are roles that the
members of one or more user classes can perform with respect to the
system.
• For example, the Chemical Tracking System's use case called "Request a
Chemical" involves an actor named Requester. There is no Chemical
Tracking System user class named Requester. Both chemists and
members of the chemical stockroom staff may request chemicals, so
members of either user class may perform the Requester role.
The Use-Case Approach
• Shift the perspective of requirements development to discussing what
users need to accomplish, in contrast to the traditional elicitation
approach of asking users what they want the system to do.
• The objective is to describe all tasks that users will need to perform with
the system.
• The stakeholders ensure that each use case lies within the defined project
scope.
(Partial) Use-case Diagram for the Chemical
Tracking System (UML notation)
Use-cases and Usage Scenarios
• A use case is a discrete, stand-alone activity that an actor can perform to
achieve some outcome of value.
• A single use case might encompass a number of similar tasks having a
common goal.
• A use case is therefore a collection of related usage scenarios, and a
scenario is a specific instance of a use case.
Use-case Description
• A unique identifier
• A name that briefly states the user task in the form of "verb + object," such
as "Place an Order"
• A short textual description written in natural language
• A list of pre-conditions that must be satisfied before the use case can begin
• Post-conditions that describe the state of the system after the use case is
successfully completed
• A numbered list of steps that shows the sequence of dialog steps or
interactions between the actor and the system that leads from the pre-
conditions to the post-conditions
Use-case Description
Use-case Description
SDLC
Phase 04: Developing the Software
➢ The testing activities are mostly involved in all the stages of SDLC.
➢ However this stage refers to the testing only that stage of the software
➢ Once the software is tested and no bugs or errors are reported then it is
deployed.
➢ After the software is deployed then its maintenance starts.
deliverables.