Software Engineering Principles

ICT 307

Session 1
Session Outline

1. Software engineering
2. The scope of Software Engineering
3. Software process
4. Software process model
5. Attributes of good software
6. The challenges facing software engineering
7. Professional and ethical issues
Definition

⚫ What is software?
⚫ The collection of computer programs,
procedures, rules and associated
documentation and data.
⚫ Category
1. Simple software
2. Industrial strength software systems.
Introduction

⚫ Development of large complex software

systems is an extremely difficult process.
⚫ Occurrence of large number of errors is
common in such systems.
⚫ Software engineering is the discipline that
attempts to provide methods to handle this
complexity and enable us to produce reliable
systems with maximum productivity.
Software engineering

1. A discipline whose aim is the production of

fault-free software, delivered on time and
within budget, that satisfies the client’s
needs.
⚫ Must be easy to modify when the user
needs changes.
2. It is the systematic approach to the
development, maintenance and retirement
of a software.
Software engineering

⚫ The IEEE definition:

– The application of a systematic,
disciplined, quantifiable approach to
the development, operation, and
maintenance of software.
– A systematic approach to design,
develop and implement reliable and
maintainable software within
schedule and budget.
Software Engineering

⚫ Software engineering focuses on the process

of software development, but not on the
software product itself.
Key Elements

⚫ Three key elements of software engineering:

1. Methods
2. Tools
3. Procedures
They enable the manager to control the process of
development and provides a sound foundation
for building high quality software in a
productive and economical manner.
Key Elements
Software Engineering Methods

⚫ They are the tasks such as: project

management, system and software
requirement analysis, design of data
structures, program architecture –
algorithms, coding, testing, maintenance.
SOFTWARE ENGINEERING TOOLS

⚫ Facilitate and enhance different stages

of the software development lifecycle
⚫ Integrated Development Environments
(IDEs): Eclipse, IntelliJ IDEA, Visual
Studio, PyCharm.
⚫ For code editing, debugging, and
project management features.
Development TOOLS

⚫ PyCharm: Integrated Development Environment

(IDE) for Python development.
⚫ JUnit, Selenium, TestNG: Testing tools for unit
testing and automated testing.
⚫ SonarQube, Checkstyle: Code quality analysis
tools.
⚫ Crucible, GitHub Pull Requests, GitLab Merge
Requests: Code review tools.
Project Management Tools:

⚫ Jira: Bug tracking and issue management

tool.
⚫ Trello: Visual project management and
collaboration tool.
Collaboration and Communication Tools

⚫ Slack, Microsoft Teams and Confluence: for

collaborating and communicating during
software development.
SOFTWARE ENGINEERING TOOLS

⚫ Version Control Systems tools:

⚫ - Examples: Git, SVN (Subversion),
Mercurial: to manage and track changes
across projects.
⚫ Facilitate collaboration, tracking changes
and monitor changes made to the source
code.
Software Engineering Procedures

⚫ Holds the methods and tools together.

⚫ They define the sequence in which the
methods will be applied, the deliverables
such as reports, manuals, forms that are
required, the controls that help quality
assurance and handling changes and
milestones that are used for assessing the
project progress.
Historical Aspects

⚫ The belief that software design,

implementation, and maintenance could be
put on the same footing as traditional
engineering disciplines.
⚫ NATO study group in 1967 coined the term
Software Engineering
⚫ In 1968, the name was endorsed by NATO in
a software engineering conference
Historical Background of SE

⚫ They believed that software production

should be an engineer-like activity
⚫ They concluded that software engineering
should use the philosophies and paradigms
of established engineering disciplines to
solve what they termed the software crisis.
⚫ A phenomenon where the quality of software
generally was unacceptably low and that
deadlines and budgets were not being met.
Historical Background of SE

⚫ The software crisis continued.

⚫ Long duration and poor projection led to software
depression
cancelled

23%

successful
49%

completed late,
28% over budget,
features
missing
Historical Background of SE

⚫ Too little software was delivered within

budget, fault free, and meeting its client’s
needs.
⚫ To achieve these goals, software engineer
has to acquire a broad range of skills, both
technical and managerial.
⚫ The skills should be applied to every step of
software production, from requirements to
post-delivery maintenance.
Software Process

⚫ A structured set of activities whose goal is to

develop software systems. The activities are:
1. Specification - what the system should do and its
development constraints
2. Development - production of the software system
3. Verification – checking that the software meets the
requirements
4. Validation - checking that the software is what the
customer wants or meets intended use
5. Evolution - changing the software in response to
changing demands.
Software Process Model
⚫ A description of the sequence of activities
carried out in a SE project, and the relative
order of these activities.
⚫ It provides a fixed generic framework that
can be customized to a specific project.
⚫ Project specific parameters/factors will
include: Size (person-years), budget and
Duration.
Challenges of Software Engineering

⚫ The problem of scale

⚫ Cost, schedule and quality
⚫ Inconsistency
⚫ Heterogeneity
⚫ Legacy
⚫ Delivery
⚫ Trust
 Dimensions of Software Quality

⚫ Quality has 3 dimensions.

⚫ Qualities related to the operation of the
system – correctness, reliability, efficiency,
usability and integrity.
⚫ Qualities related to the product transition –
portability, interoperability and reusability.
⚫ Qualities related to the maintenance –
flexibility, testability and modifiability.
Attributes of good Software Product
Attributes of good Software Product

⚫ Correctness
⚫ User friendliness
⚫ Portability
⚫ Reliability
⚫ Robustness
⚫ Reusability
⚫ Interoperability
⚫ Scalability
⚫ Security and integrity, maintainability, etc.
Professional and Ethical Responsibilities

⚫ Public – Software engineers shall act consistently

with the public interest.
⚫ Client and Employer - Software engineers shall act
in a manner that is in the best interest of their client
and employer consistent with the public interest.
⚫ Product – Software engineers shall ensure that
their product and related modifications meet the
highest professional standards possible.
Professional and Ethical Responsibilities

⚫ Profession – Software engineers shall advance

the integrity reputation of the profession
consistent with the public interest.
⚫ Colleagues – Software engineers shall be fair to
and supportive of their colleagues.
⚫ Self – Software engineers shall participate in
lifelong learning regarding the practice of their
profession and shall promote an ethical
approach to the practice of the profession.
END
SESSION OUTLINE

⚫ The software life cycle

⚫ Uses of development process models
⚫ Principles of software engineering
⚫ Types of software process models
The Software Life Cycle

⚫ From the time of inception to the time of

delivery and installation, the software
undergoes several phases.
⚫ Each of these phases results in the
development of either the part of the system
or preparation of a test plan or a user
manual, etc.
Software Life Cycle

⚫ IEEE: Software life cycle as the period of time

that starts when the product is conceived and
ends when the product is no longer available for
use.
⚫ A software life cycle is either prescriptive or
descriptive
⚫ A prescriptive life cycle model describes how
software systems should be developed.
⚫ Descriptive life cycle models characterize how
software systems are actually developed.
The Software Life Cycle
 Requirement Analysis and
Specification

⚫ The software is a part of larger system.

⚫ Must interface with other elements such as
hardware, people and databases.
⚫ For large systems that have many features,
and perform many tasks, understanding what
exactly the software must do is the most
important factor.
 Requirement Analysis and
Specification

⚫ Perform by a person or a team of persons

called system analyst.
⚫ The major objective of this phase is to
identify exactly “what types of features” the
software to be developed must provide.
⚫ Two major activities: problem understanding
and requirement specification.
 Key Activities of System
Analyst
⚫ Identifies and documents all business, technical, product
and process requirements
⚫ Makes sure that the situation and suggestion of change
are understood by the clients and the project team
⚫ Develops Requirement Management Plan and
disseminating the Plan to all stakeholders
⚫ Works with the client to organize the requirements in
order of importance.
⚫ Helps to define acceptance criteria for completion of the
solution.
Activities of System Analyst

⚫ The problem analysis includes- thorough

understanding of the problem, areas to be
automated, areas affected after automation.
⚫ This requires creative thinking, better inter-
personal skills and a close interaction
between the users, client, and analysts.
 Content of Requirement
Document
⚫ The requirements phase ends with a
requirement document.
⚫ Content: functional and performance
requirements, scope of the product, nature of
its interface to users, hardware requirements,
existing product, speed, precision, the
capacity and cost of the product, and
potential benefits to the organization
Requirement Document

⚫ The SRS document serves the basis of

contract, moral and legal between the client
and the developer, and should be
accompanied by a detailed plan, the
acceptance test by which a client will validate
a software as well as user manuals.
 Assignment 1
(Problem Identification)

1. Identify a department/unit within Dr. Hilla

Limann Technical and pay it a visit to learn at
first hand about their activities and a problem
that is solvable using software. Use the visit to
understand the existing problem regarding their
operations.
2. Write a report on your visit to the
department/unit.
Submission Date: 12th February, 2024
 Design and Specification Phase
(2nd phase)

⚫ This phase is the first step in moving from the

problem domain to the solution domain.
⚫ Starting with what is needed to how to obtain it.
⚫ The design phase focuses on four distinct attributes of
the software: Data Structure, Software Architecture,
Procedural Detail and Interface Design.
⚫ The design phase is usually divided into 2 stages:
⚫ System Design (Preliminary Design)
⚫ Detailed Design.
 Design and Specification Phase
(2nd phase)

⚫ The design phase is usually divided into 2 stages:

⚫ System Design (Preliminary Design)
⚫ Detailed Design.
 Design and Specification Phase
(2nd phase)

⚫ Software architecture {elements, form,

rationale}
⚫ Elements: processing, data or connections
⚫ Form: a ‘set of weighted properties and
relationships’,
⚫ Rationale: The motivation for particular choices.
Design and Specification Phase

⚫ The system design focuses on what

components are required.
⚫ It defines the general structure of the
software:
– the major modules,
– The functions provided by each module,
– the interface between modules,
– major data structures
– output formats of the system.
 Detailed Design
⚫ Focuses on how each component can be
implemented.
⚫ It specifies the internal logic of each module
specifying the algorithms and more detailed
data structures.
 Coding and Module Testing
(Phase 3)

⚫ The goal of the coding phase is to translate

the design into machine-readable form.
⚫ The system is divided into modules,
developed separately, and each module is
tested to ensure that it performs as expected.
⚫ Module testing is required to uncover the
errors in requirements, design or coding. The
errors in the coding are referred to as bugs.
Integration and System Testing

⚫ All tested, workable modules of the system are

put together according to the architectural
design and tested as a whole system.
⚫ System testing is required to check whether the
interconnection between the modules is
desirable or not.
Integration and System Testing

⚫ The system is tested against system

requirements to see if all requirements
specified in SRS are met or not.

⚫ Finally, acceptance test is performed with the

client, to demonstrate the developed software,
on real life data of the client, the operation of
the system.
 Product Delivery and
Maintenance

⚫ Once the system passes all the tests

including acceptance test, it is delivered to
the client.
⚫ Installed on the user’s system, and now
becomes operational.
⚫ Any modifications required by the user during
initial operating period are usually done
during this period.
Any Challenges of Classical Approach?
(Software Life Cycle)
Challenges of Classical Approach
⚫ Real projects hardly follow this sequential and linear row
of phases.
⚫ It requires that “all system requirements must be known
before proceeding to next stages”; which is not possible
for all types of problems.
⚫ It puts the patience of the client into test. They have to
wait till the working version of a program is available
after a long time.
⚫ Detecting major blunders at the ending stage of a project
during testing stage may be catastrophic.
Principles of Software Engineering

⚫ Principles are set of rules.

⚫ They represent the collected wisdom of
many dozens of people who have learned
through experience.
⚫ Software engineering principles are based on
the observation of thousands of projects.
Principles:
1. Make the quality number one objective
⚫ Quality must be the first objective of the software. A
customer will not tolerate the poor quality software.
Delivering the poor quality software in time is useless.
⚫ The quality is different for different people. To users, it
must be ‘perfect’, good response time and high capacity.
⚫ To developers it must be elegant design and code.
⚫ For some customers, it might be satisfying all their
perceived or not yet perceived needs.
Principles:

2. High quality software is possible

⚫ Quality of a software product can be increased by:
⚫ involving the users more
⚫ simplifying the design
⚫ prototyping
⚫ conducting inspections at the end of each phase
⚫ Hiring the best people.
Principles Cont.

⚫ Give products to customer early

⚫ Minimize the intellectual distance between
the developer and the user
⚫ Use appropriate Process Model
THE END
SESSION OUTLINE

⚫ Types of software process models

⚫ Software specification
⚫ Software design and implementation
⚫ Software validation
⚫ Software Development Team
Software Process

⚫ A structured set of activities whose goal is to

develop software systems.

Software Process Model:

⚫ A description of the sequence of activities carried
out in an SE project, and the relative order of
these activities.
⚫ Provides a fixed generic framework that can be
customized to a specific project.
 Uses of Development Process
Models

⚫ Following are the important uses of models:

1. As a means to organize, plan, staff, budget
& schedule and manage software projects.
2. As a perspective outline of the required set
of documents to be produced.
3. As a basis for determining which software
engineering tools and methodologies will be
most appropriate.
 Uses of Development Process
Models

4. As a framework for analyzing and estimating

patterns of resource allocation and consumption
during software life cycle.

5. As a basis for conducting empirical studies to

determine what affects software productivity, cost
and overall quality.
Types of Software Process Models

⚫ The Waterfall Model

⚫ The Prototype Model
⚫ Incremental Development Model
⚫ Agile Model
⚫ Code-and-Fix Model
⚫ Spiral Model
⚫ Extreme Programming Model,
⚫ Evolution-tree Model, etc.
The Waterfall Model Life Cycle

⚫ A popular version of the systems

development life cycle model for software
engineering.
⚫ This model describes a development method
that is linear and sequential.
⚫ Phases are organised in linear order
⚫ Each phase has distinct goals for the
software development.
The Waterfall Model Life Cycle
The Waterfall Model Life Cycle

⚫ No phase is complete until the document for

that phase has been completed and approved
by software quality assurance group.
⚫ Inherent in every phase is testing.
⚫ Modifications if necessary and Feedback loop
⚫ Validation and certification of each phase
⚫ The development proceeds to the next phase.
The Waterfall Model Life Cycle

⚫ It is well suited for routine type of

projects where all the requirements are
well understood.
⚫ The project requirements are well-
defined and the project goals are clear.
⚫ Projects with long timelines, small room
for error and stakeholders have a high
level of confidence in the outcome.
Minimum set of documents

1. Requirements document
2. Project plan document
3. System design document
4. Detailed design document
5. Test plan and test reports
Minimum set of documents

6. Final code
7. Software manuals (user,
installation, etc.)
8. Review reports
Advantages:

⚫ It enforces discipline: requirements define-

before- design, design before-code
⚫ It allows for departmentalization and
managerial control.
⚫ Document driven: People leave, documents
do not.
⚫ Fits other engineering process models: civil,
mechanical, etc.
Pitfalls:

⚫ This model is suitable to automate the existing

manual system for which all requirements are
known before the design starts.
⚫ This model is document driven; it may result in
very large number of document.
⚫ Difficult and expensive to change decisions.
⚫ Limited Flexibility: The Waterfall Model is a rigid
and linear approach to software development,
The Prototype Model

⚫ A working model that is functionally equivalent

to a subset of the product is built.
⚫ Build prototype and let the stakeholders interact
with it
⚫ One of the most popularly used Software
Development Life Cycle Models (SDLC models)
The Prototype Model

⚫ Develop prototype, Test, and Refine

⚫ Repeat till a final acceptable prototype is
achieved
⚫ This forms the basis for developing the
final product.
The Prototype Model

⚫ Experimentation by users, watch and take notes

⚫ Get feedback
⚫ Prepare requirements Specifications document
Prototype Construction Process
The Prototype Model Cont.

⚫ Prototype serves as a mechanism for

identifying software requirements.
⚫ Get feedbacks from time to time.
⚫ Suitable for projects where the
requirements are hard to determine.
⚫ It is an excellent technique for reducing
risks
Prototype Projects Suitability

⚫ Projects where requirements of the

product are not clearly understood
⚫ If requirements are changing quickly
⚫ Good choice to demonstrate the
technical feasibility of the product..
⚫ Systems with complex algorithms and
interfaces.
Advantages:

⚫ Helps user to get a proper clarity and 'feel'

of the functionality of software
⚫ Good for non-IT-literate people.
⚫ It reduces risk of failure
⚫ The final system developed will be closer
to the actual requirements.
Drawbacks:

⚫ Prototyping is usually done at the cost

of the developer.
⚫ Too much involvement of client is not
always preferred by the developer.
⚫ Too many changes can disturb the
rhythm of the development team.
⚫ It is a slow process.
Incremental Development Model

⚫ The development and delivery is broken down

into increments with each increment delivering
part of the required functionality
⚫ User requirements are prioritised and the highest
priority requirements are included in early
increments
⚫ Once the development of an increment is
started, the requirements are frozen though
requirements for later increments can continue to
evolve
Advantages

⚫ Customer value can be delivered with each

increment so system functionality is available
earlier
⚫ Early increments act as a prototype to help
elicit requirements for later increments
⚫ Lower risk of overall project failure
⚫ The highest priority system services tend to
receive the most testing
 Rapid Application Development
Model (RAD)

⚫ RAD was introduced by IBM.

⚫ A type of incremental model in which
there is an extremely short
development cycle.
⚫ The time frame for delivery (time-box)
is generally 60-90 days.
 Rapid Application Development
Model (RAD)

⚫ When the requirements are fully

understood
⚫ The component-based construction
approach is adopted then the RAD
model is used.
⚫ Multiple teams work on developing the
software system using the RAD model
parallelly.
Rapid Application Development
Model (RAD)
 Project Suitability

⚫ This is used for a system with known

requirements
⚫ Projects that require a short development time.
⚫ When already existing system components can
be used in developing a new system with
minimum changes.
 Merits of RAD

⚫ The use of reusable components

⚫ Feedback from the customer is available at the
initial stages.
⚫ Reduced costs as fewer developers are required.
⚫ It is easier to allow changing requirements due to
the short iteration time spans.
⚫ Productivity may be quickly boosted with a lower
number of employees.
 Demerits

⚫ Not every application can be used with RAD.

⚫ Systems which cannot be modularized suitably
cannot use this model.
⚫ Customer involvement is required throughout the
life cycle.
⚫ If there is no appropriate modularization then
RAD projects fail.
 Spiral Model

⚫ Process is represented as a spiral rather than as a

sequence of activities with backtracking
⚫ Each loop in the spiral represents a phase in the
process.
⚫ No fixed phases such as specification or design -
loops in the spiral are chosen depending on what
is required
⚫ Risks are explicitly assessed and resolved
throughout the process
Spiral model
Detailed Spiral model
Determine objectives
Evaluate alternatives
alternatives and identify, resolve risks
constraints Risk
analysis
Risk
analysis
Risk
analysis Opera-
Prototype 3 tional
Prototype 2 protoype
Risk
REVIEW analysis Proto-
type 1
Requirements plan Simulations, models, benchmarks
Life-cycle plan Concept of
Operation S/W
requirements Product
design Detailed
Requirement design
Development
plan validation Code
Design Unit test
Integration
and test plan V&V Integr ation
Plan next phase test
Acceptance
Service test Develop, verify
next-level product
⚫ Objective setting
– Specific objectives for the phase are identified
⚫ Risk assessment and reduction
– Risks are assessed and activities put in place to reduce the
key risks
⚫ Development and validation
– A development model for the system is chosen which can
be any of the generic models
⚫ Planning
– The project is reviewed and the next phase of the spiral is
planned
Advantages

⚫ It is flexible
⚫ Project monitoring is easy
⚫ Risk Management is in-built feature
Drawbacks

⚫ Cost involve is high

⚫ It is difficult to meet budgetary and
scheduling requirements
⚫ It needs expertise to evaluate and review
project
 Iterative Enhancement
Model
⚫ This model is useful for product development in
which developers themselves provide specifications.
⚫ Combines the features of waterfall and prototype
⚫ First version of a product with minimal and essential
features is launched to the market.
⚫ Based on the feedback and experience with this
version, a list of additional requirements and
capabilities is prepared.
⚫ This list is the basis for developing new version of the
Advantages

⚫ The iterative model combines the features of

both waterfall and prototype model.
⚫ This approach results in better testing,
because testing in increments is easier than
testing the whole system at once.
⚫ The client can pay to the projects in
installments.
Code and fix model

This model starts with an informal general product

idea and just develops code until the product is
ready.
Or money or time runs out
Work is in random order.
Corresponds with no plan!
Code and fix Advantages

⚫ No administrative overhead
⚫ Signs of progress (code) early.
⚫ Low expertise, anyone can use it!
⚫ Useful for small projects.
Evolutionary development model

• Specification and development are interleaved

• Developing initial implementation and releasing to
client for comments and refinement
• Incremental development of specification
• Users have better understanding of product
• Not cost effective
• Change can disrupt the software structure
Evolutionary Model Types

⚫ Exploratory development
– Objective is to work with customers and to evolve
a final system from an initial outline specification.
Should start with well-understood requirements
⚫ Throw-away prototyping
– Objective is to understand the system
requirements. Should start with poorly understood
requirements
Applicability

⚫ For small or medium-size interactive systems

⚫ For parts of large systems (e.g. the user
interface)
⚫ For short-lifetime systems
Problems

⚫ Systems are often poorly structured

⚫ Lack of process visibility
⚫ Special skills (e.g. in languages for rapid
prototyping) may be required
⚫ Not cost effective
⚫ Change can disrupt the software structure
Evolutionary Model

Concurrent
activities

Initial
Specification
version

Outline Intermediate
Development
description versions

Final
Validation
version
Reuse-based development

⚫ The system is assembled from existing

components
⚫ Modify as required to reflect needs
⚫ Integrated into their system
⚫ Faster delivery of product
⚫ Reduced cost and risk
⚫ Some control may be lost over System evolution.
Reuse-oriented development

⚫ Based on systematic reuse where systems

are integrated from existing components or
COTS (Commercial-off-the-shelf) systems
⚫ Process stages
– Component analysis
– Requirements modification
– System design with reuse
– Development and integration
Extreme Programming

⚫ New approach to development based on the

development and delivery of very small
increments of functionality
⚫ Relies on constant code improvement, user
involvement in the development team and
pair programming
Agile Development Methodology

⚫ The main aim of the Agile model is to

facilitate quick project completion.
⚫ Respond to change rapidly
⚫ Values flexibility, collaboration, and
customer satisfaction.
⚫ Primarily designed to help a project
adapt quickly to change requests.
Software Development
Methodology

⚫ They are the tasks such as: project

management, system and software
requirement analysis, design of data
structures, program architecture –
algorithms, coding, testing,
maintenance.
⚫ They enable the manager to control the
process of development
Agile Development Methodology

⚫ Agile development requires a high

degree of collaboration and
communication among team members,
willingness to adapt to changing
requirements and feedback from
customers.
Agile Development Methodology

⚫ The time required to complete an

iteration is known as a Time Box.
⚫ Time-box: The maximum amount of
time needed to deliver an iteration to
customers.
⚫ Central principle: deliver an increment
to the customer after each Time-box.
Agile Development Methodology

⚫ Ensures customer satisfaction by rapid,

continuous delivery of useful software.
⚫ People and interactions are
emphasized rather than process and
tools.
⚫ Customers, developers and testers
constantly interact with each other.
Agile Development Methodology

⚫ Face-to-face conversation is the best

form of communication.
⚫ Close daily cooperation between
business people and developers.
⚫ Working software is delivered
frequently (weeks rather than months).
Agile Development Methodology

⚫ Continuous attention to technical

excellence and good design.
⚫ Regular adaptation to changing
circumstances.
⚫ Even late changes in requirements are
welcome
Agile Development
Methodology
Agile Project Suitability

⚫ When frequent modifications are required.

⚫ Highly qualified and experienced team is
available.
⚫ When a customer is ready to have a
meeting with the team all the time.
⚫ Project needs to be delivered quickly.
Principles of the Agile Model

1. Establish close contact with stakeholders

to revaluate requirements at the end of
each iteration
2. Emphasizes reliance on working software
deployment rather than comprehensive
documentation.
3. Frequent delivery of incremental versions
in intervals of a few weeks.
Principles of the Agile Model

4. Requirement change requests from the

customer are encouraged
5. It emphasizes efficient team to enhance
communications and collaboration
6. Small development team size
recommended
7. Agile usually deploys Pair Program
Characteristics of the Agile Process

⚫ Must be adaptable to technical and

environmental changes.
⚫ Must be incremental.
⚫ Customer feedback is must input to create the
next increment of the process.
⚫ Short span of time increment delivery.
⚫ It must be iterative so that each increment can be
evaluated regularly.
Agile Project Suitability

⚫ Projects with few regulatory requirements or not

certain requirements.
⚫ Projects utilizing a less-than-strict current
methodology
⚫ The product proprietor is easily reachable
⚫ Flexible project schedules and budgets.
Merits of Agile

1. Faster delivery of software products.

2. Customer satisfaction is prioritized.
3. Daily interactions are required
4. Lates requirements changes is
accepted
5. Better adaption to rapidly changing
requirements and respond faster.
Demerits of Agile

⚫ Requires a high degree of expertise.

⚫ Not suitable for larger and complex
project.
⚫ Resource requirement and effort are
difficult to estimate.
⚫ Sometimes the requirement is not clear
difficult to predict the expected result.
Reading Assignment

⚫ Scrum
⚫ Models
⚫ Lean Development
⚫ Atern
⚫ Feature-driven development
⚫ Extreme programming (XP):
⚫ Unified Process
⚫ Kanban
DevOps Methodology

⚫ DevOps = Development + Operations

⚫ Aim: Speedy delivery of applications and
services.
⚫ DevOps promotes collaboration between
development and operations teams
⚫ Result: Better communication, increased
efficiency and faster delivery of the new
products and frequent updates.
DevOps
Advantages

1. Faster delivery of product and frequent

update
2. Better resource utilisation.
3. Provides customer satisfaction as the
releases and update are very frequent.
4. Promotes collaboration between teams,
resulting in better communication,
increased efficiency and reduced friction.
Disadvantages

1. Sometimes implementing DevOps can be

costly process.
2. Finding a qualified DevOps person is very
challenging.
3. DevOps is still a relatively new field, and
there is a lack of standardization in terms
of tools, nd processes.
Software Engineering Teams

⚫ Managing software engineers is more difficult

⚫ The following characteristics are more
prevalent among software engineers and
programmers:
⚫ Logical: Reasonable, practical
⚫ Artistic: Creative, imaginative, inventive
⚫ Possessive
Software Engineering Teams

⚫ Temperamental
⚫ Diverse productivity ratio (as much as 20:1)
⚫ Software projects organized as teams; each
team is responsible for a specific function
⚫ Project manager must form the teams
Team Work Goals

⚫ Volunteers are better than draftees

⚫ Creating and sustaining an environment that
fosters cooperation;
⚫ team leadership must inspire growth
⚫ Share common goals; committed to achieving
the goals
⚫ Mutual respect and common code of conduct
⚫ Sense of enjoyment; desire to do what is needed
to succeed
⚫ Sharing a common reward; equitable
compensation; selective
⚫ rewards only for extraordinary work
⚫ Team spirit: team needs are more important than
personal needs
⚫ Recognition for team achievements
⚫ Clear definition of team vision and objectives;
consensus on goals and individual
responsibilities - develop organization structure
Team Organization
Chief Programmer Team

⚫ Team leader is both a technical mentor and the

team’s coordinator..
⚫ Team coordination may take as much as 50% of
team leader’s time to;
⚫ Assign tasks to the team members
⚫ Provide advice and guidance
⚫ Supervise the work of team members
⚫ Coordinate activities
Democratic Teams

⚫ No team leader per se;

⚫ Nominal team leader
⚫ the team leader is mostly in charge of coordination
⚫ technical decisions made by the whole team
⚫ ideal for experienced software developers; not so ideal
for junior developers
⚫ leads to ego-less programming: everyone is equally
responsible
Is it Really a Team?

⚫ Positive indicators:
⚫ collaborative climate
⚫ Free flow of information
⚫ Positive interpersonal interaction
⚫ High energy
⚫ High morale; fun to come to work
Is it Really a Team?

⚫ Negative indicators:
⚫ Suspicious and un-trusting climate
⚫ Information is withheld
⚫ Finger-pointing prevails
⚫ Defensiveness and counterproductive
factions form
⚫ No fun to work
Assignment: Problem Description
A client has a challenge in running a barbering business located in the Wa
Municipality. He is considering streamlining the running and management of the
Business. He needs software that would facilitate the various operations to
manage appointments, barbers and customer information.
⚫ You have been tasked to:
i. Identify the prospective/supposed client within the Wa Municipality.
ii. Prepare a project management plan for developing the software using
duration of 10 weeks. [Submission date: 26th February, 2024]
iii. Design and develop quality software that would be used to manage the
Barbering business effectively.
iv. Prepare the necessary documentations of the project
v. Prepare a presentation of 20 slides maximum, for a presentation of your
software product to a panel of three members. [Presentation date: 1st April,
2024]
Software specification

⚫ The process of establishing what services

are required and the constraints on the
system’s operation and development
⚫ Requirements engineering process
– Feasibility study
– Requirements elicitation and analysis
– Requirements specification
– Requirements validation
The requirements engineering
process

Feasibility Requirements
study elicitation and
analysis
Requir ements
specification
Feasibility Requirements
report validation
System
models
User and system
requirements

Requirements
document
 Features of Good Requirements

⚫ A good set of requirements has at least eight

characteristics, which can be arranged under
three broad sets dealing with different issues.
⚫ Eight Features of good requirements
⚫ Communication
⚫ Control
⚫ Construction
 Communication
⚫ The good requirements communicate between
the users and the developers.
⚫ Complete - All that is needed is stated.
– They must have all of the: Functional requirements
⚫ Clear - They are unambiguous.
– They must be understood with only one meaning.
– “The system will be fast”.
⚫ Consistent - They do not contradict other
requirements.
 Control

⚫ They should be certifiable, chosen and

Traceable.
⚫ Certifiable - They can be verified and validated.
⚫ Chosen - They have been ranked as to
importance.
⚫ Traceable: Forward and backwards.
– Check a requirement both back to its business reason,
and through to the design and testing documentation.
 Construction

⚫ Credible - What is asked for is technically

possible.
– feasibility means comparing the time, resources,
quality and scope of the projects and assessing the
risk of ever achieving it.
⚫ Clean - They do not have any implementation
decisions.
⚫ Only the logical structure has been defined, and
decisions about physical design and
implementation have been left out.
 Functional Requirements

Functional requirements need to be clear, simple, and

unambiguous.
• The system must send a confirmation email whenever an
order is placed.
• The system must allow users to reset their password by
clicking on "I forgot my password" and receiving a link to
their verified email address.
 Software design and
implementation

⚫ The process of converting the system

specification into an executable system
⚫ Software design
– Design a software structure that realises the
specification
⚫ Implementation
– Translate this structure into an executable program
⚫ The activities of design and implementation are
closely related and may be inter-leaved
 Software design and
implementation

⚫ Movement from the problem domain to the solution

domain.
⚫ Starting with what is needed to how to obtain it.
⚫ The design phase focuses on four distinct attributes of
the software: Data Structure, Software Architecture,
Procedural Detail and Interface Design.
⚫ The design phase is usually divided into 2 stages:
⚫ System Design (Preliminary Design)
⚫ Detailed Design.
Design process activities

⚫ Architectural design
⚫ Abstract specification
⚫ Interface design
⚫ Component design
⚫ Data structure design
⚫ Algorithm design
The software design process
Design methods

⚫ Architectural Styles: Client-server,

layered, microservices
⚫ This provides templates for organizing
system components and interactions.
⚫ The Components (modules, classes)
⚫ Connectors: interfaces, communication
channels) that interact to fulfil system
requirements.
 Architecture Design Principles
I. Separation of concerns: Divide the system
into distinct modules or layers
II. Modularity: Encapsulate related
functionality
III. Abstraction: Hide implementation details
IV. Loose Coupling: Minimize dependencies
between components to enhance flexibility,.
V. High Cohesion: Ensure components within
the same module have strong functional
cohesion, focusing on a single, well-defined
purpose.
 Systems Models: Symbols used in
DFDs

• Named circles – to represent processes.

• Data flows: Labeled arrows entering or
leaving processes.
• Named Rectangles: represents the external
entities such as vendors or customers with
whom the system interacts. Entities
supplying data are sources and those that
consume data are called sinks.
 Systems Models: Symbols used in
DFDs

• Labeled straight line – represents all

external files such as employee's records,
company records, etc.
⚫
 Systems Models

⚫ A data flow can take place:

⚫ Between processes
⚫ File to process
⚫ External entity to process
⚫ Process to external entity
⚫ Process to file
Data Flow Diagrams
Detailed Design

Design Class Diagrams:

• Use UML class diagrams to visually
represent the classes and their relationships.
• Specify attributes (data members) and
methods (functions) within each class.
Detailed Design
Design Use Case Diagram
Detailed Design methods

User Class:
Code snippet
classDiagram
class User {
+ id: int (PK)
+ username: string
+ password: string (hashed)
+ email: string
+ role: string (e.g., "admin", "attendant", "customer")
+ created_at: datetime
+ updated_at: datetime
+ authenticate(username, password): boolean
+ change_password(new_password): boolean
}
Programming and debugging

⚫ Translating a design into a program and

removing errors from that program
⚫ Programming is a personal activity - there is
no generic programming process
⚫ Programmers carry out some program
testing to discover faults in the program and
remove these faults in the debugging
process
The debugging process

Locate Design Repair Re-test

error error repair error program
Software validation

⚫ Verification and validation is intended to

show that a system conforms to its
specification and meets the requirements of
the system customer
⚫ Involves checking and review processes and
system testing
⚫ System testing involves executing the system
with test cases that are derived from the
specification of the real data to be processed
by the system
The Testing Process

Unit
testing
Module
testing
Sub-system
testing
System
testing
Acceptance
testing

Component Integration testing User

testing testing
Testing stages

⚫ Unit testing
– Individual components are tested
⚫ Module testing
– Related collections of dependent components are tested
⚫ Sub-system testing
– Modules are integrated into sub-systems and tested. The
focus here should be on interface testing
⚫ System testing
– Testing of the system as a whole. Testing of emergent
properties
⚫ Acceptance testing
– Testing with customer data to check that it is acceptable
Testing phases

Requirements System System Detailed

specification specification desig n design

System Sub-system Module and

Acceptance
integration integration unit code
test plan
test plan test plan and tess

Acceptance System Sub-system

Service
test integration test integration test
Software evolution

⚫ Software is inherently flexible and can change.

⚫ As requirements change through changing
business circumstances, the software that
supports the business must also evolve and
change
⚫ Although there has been a demarcation between
development and evolution (maintenance) this is
increasingly irrelevant as fewer and fewer
systems are completely new
END
TEAM ORGANIZATION

⚫ DEMOCRATIC TEAM
TASK ASSIGNMENT

⚫ Allocation of Areas
⚫ Group Briefing
⚫ Appointment of titular leaders
⚫ Assigning Necessary Documents
Feasibility Studies

⚫ Visit Work places

⚫ Introduction of Members
⚫ Exchange of Documents
Session Outline

⚫ Software requirements
⚫ Functional and non-functional requirements
⚫ User requirements
⚫ System requirements
⚫ Interface specification
⚫ The software requirements document
What are software Requirements?

⚫ The requirements are the descriptions

of the system services and constraints
that are generated by observing the
current practice, talking to the people
who are involved in the practice.
Software Requirements Problem

⚫ The Software requirements analysis phase

is difficult and error-prone activity. Why?
1. For automating existing manual systems,
basic requirements can be understood by
observing the current practice.
2. Talking to the people who are involved in
the practice, involving them in
requirements phase can be difficult.
Software Requirements Problem

1. As the people become more involved in

this phase, their idea keeps on changing
2. Inputs from multiple users may become
inconsistent, imprecise and ambiguous.
Software Requirements Problems

2. To develop non-existing systems for which no

current manual practice is available, they have
to be visualized and created.
3. Requirements for complex systems, may change
even after complete SRS is specified.
4. Changes: Sometimes frequent changing
requirements lead to a sour relationship
between the developer and clients.
Software Requirements Problems

5. Incorrect interpretation of specification

may lead to requirements changes.
 Software Requirements
Specification Document

1. A detailed document should be created

after spelling out what the software will
do.
2. A thorough and rigorous requirements
study and specifications leads to a high
quality and relatively stable
requirements specifications.
 Software Requirements
Specification Document

⚫ The SRS document is the basis of

contract, moral and legal between the
client and the developer
⚫ Should be accompanied by a detailed
plan
⚫ The acceptance test by which a client
will validate a software as well as user
manuals.
 Importance of SRS

1. SRS bridges the communication gap

between the client, users and developers.
2. SRS is a medium through which clients
and user needs are understood accurately
by the developer and specified in the
domain of software.
 Importance of SRS

3. Helps the clients and users to understand

their precise requirements.
4. IT serves as the basis for agreement
between the client and the developer.
⚫ Client clearly specifies the capabilities to
be provided.
Importance of SRS

5. Serves as a reference for validation of

the final product. The delivered
software should satisfy all requirements
specified in the document.
6. A good-quality SRS reduces the errors
in system, and therefore helps in a
tremendous reduction in the project
cost.
 Characteristics of good
requirements

⚫ The requirements spell out:

⚫ System services
⚫ Constraints
 Characteristics of good
requirements

⚫ Good requirements have three broad sets of

characteristics:
1. Communication: complete, clear consistent.
2. Control: certifiable, chosen, traceable.
3. Construction : credible, clean.
Communication Characteristics

⚫ Complete - All that is needed is stated.

⚫ Clear - They are unambiguous.
⚫ Consistent - They do not contradict other
requirements.
Complete

⚫ It captures functional requirements and Non-

functional requirements describing the
performance and development constraints on
the system.
⚫ Design objectives to guide the system
designers
⚫ Reference material for definition of terms
used and units of measurement.
Clear

⚫ They must have one understanding and one

meaning.
⚫ No ambiguity, no vagueness.
⚫ Make specific to avoid vague ill-thought out
terms such as the “the system will be fast”.
Requirements must have enough detail that
developers can design a system that does
what the users want.
Consistent

⚫ Consistency means no requirement

contradicts what another says.
⚫ Non-functional requirements should not be in
conflict with the functional ones. E.g
⚫ Functional requirement:
– The system should enable all users to generate
and print a receipt within 3 seconds.
⚫ Functional requirement:
– The system should allow the system administrator
only to print receipts
Control Characteristics

⚫ The key control characteristics are that the

requirements must be:
⚫ Certifiable - They can be verified and
validated. This means they should be
expressed in physical terms and measurable
attributes.
⚫ Chosen - They have been ranked as to
importance.
⚫ Traceable - They can be traced forward and
backwards.
Chosen

⚫ Not all requirements are created equal, some

“Must” be included, or the system will be a
waste of effort, others “Could” be included as
they enhance what the system could achieve.
All systems are subject to constraints on time,
resources and quality, so control of the scope
of the project is important.
⚫ Prioritization of the requirements.
Traceable

⚫ It must be possible to trace a requirement

both back to its business reason, and
through to the design and testing
documentation.
⚫ Without the ability to chase them through it is
impossible to compare any documentation to
see if they have been implemented.
Construction Characteristics

⚫ Credible
⚫ Credible means seeing if the project is
technically feasible and achievable within the
constraints of the project.
⚫ If a project is not credible then it is better to say
at the requirements stage then wait until later.
⚫ Technical feasibility means comparing the
requirements logical model, with what is
currently technically possible.
Clean

Clean - They do not have any implementation

decisions.
A clean set of requirements is one where only the
logical structure has been defined, and decisions
about physical design and implementation have
been left out. The more physical design
decisions that are taken by the users the fewer
the options that are available to the developers
to deliver what is needed.
END
 SESSION OUTLINE

⚫ Last Session Highlights

⚫ Categories of requirements
⚫ Software requirement document
⚫ Structure of SRS document
⚫ Requirements of Engineering process
What are software Requirements?

⚫ The requirements are the descriptions of the system

services and constraints that are generated by
observing the current practice, talking to the people
who are involved in the practice.
⚫ This is inevitable as requirements may serve a dual
function
– May be the basis for a bid for a contract - therefore
must be open to interpretation;
– May be the basis for the contract itself - therefore
must be defined in detail.
 Categories of Requirements

⚫ Requirements are grouped into two:

1. Functional requirements
2. 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.
⚫ They specify an action that the target product
must be able to perform or provide.
⚫ They are often expressed in terms of inputs and
outputs.
⚫ They should be both complete and consistent.
Functional requirements

⚫ Describe functionality or system services.

⚫ Depend on the type of software, expected
users and the type of system where the
software is used.
⚫ Functional user requirements may be high-
level statements of what the system should
do but functional system requirements
should describe the system services in detail.
Example: A Library system

⚫ A library system that provides a single

interface to a number of databases of articles
in different libraries.
⚫ Users can search for, download and print
these articles or reading materials.
 Examples of functional
requirements

⚫ The user shall be able to search either all of the

initial set of databases or select a subset from it.
⚫ The system shall provide appropriate viewers for
the user to read documents in the document
store.
⚫ Every order shall be allocated a unique identifier
(ORDER_ID) which the user shall be able to
copy to the account’s permanent storage area.
Non-functional requirements

⚫ The constraints on the services or functions

offered by the system such as timing
constraints, platform constraints, constraints
on the development process, standards, etc.
⚫ These define system properties and
constraints e.g. reliability, response time and
storage requirements. Constraints are I/O
device capability, budget, etc.
 Non-functional requirements
classification
⚫ Product requirements
– Requirements which specify that the delivered product must behave in a
particular way e.g. execution speed, reliability, etc. Portability, usability
requirements
⚫ Organisational requirements
– Requirements which are a consequence of organisational policies and
procedures e.g. process standards used, implementation requirements,
⚫ External requirements
– Requirements which arise from factors which are exterior to the system
and its development process e.g. interoperability requirements,
legislative requirements, ethical requirements, etc. e.g. the system
should not disclose other personal information about customers apart
from name and ID
 Non-functional requirements
examples

⚫ Product requirement
The user interface for Library system shall be
implemented as simple HTML without frames or
Java applets.
⚫ Organisational requirement
The system development process documents shall
conform to the process defined by the organisation.
⚫ External requirement
The system shall not disclose any personal
information about customers apart from their ID to
the operators of the system.
Domain requirements

⚫ The first task of development team is to

acquire a basic understanding of the
application domain.
⚫ The specific environment in which the target
software product is to operate.
⚫ The domain could be education, banking,
election, hotel, automobile manufacturing,
etc.
Knowing the Application Domain

⚫ The task of the developers is to determine

exactly what the client needs and to find out
from the client what constraints exist.
⚫ Some of the constraints are:
1. The deadline
2. Reliability. product must be operational
99%
3. Cost
User requirements

⚫ Should describe functional and non-

functional requirements in such a way that
they are understandable by system users
who don’t have detailed technical knowledge.
⚫ User requirements are defined using natural
language, tables and diagrams as these can
be understood by all users.
System requirements

⚫ More detailed specifications of system

functions, services and constraints than user
requirements.
⚫ They are intended to be a basis for designing
the system.
⚫ They may be incorporated into the system
contract.
⚫ System requirements may be defined or
illustrated using system models.
Requirements and design

⚫ Requirements should state what the system

should do and the design should describe
how it does this.
⚫ In practice, requirements and design are
inseparable
– A system architecture may be designed to
structure the requirements;
– The system may inter-operate with other systems
that generate design requirements;
– The use of a specific design may be a domain
requirement.
Problems with NL specification

⚫ Ambiguity
– The readers and writers of the requirement must
interpret the same words in the same way. NL is
naturally ambiguous so this is very difficult.
⚫ Over-flexibility
– The same thing may be said in a number of
different ways in the specification.
⚫ Lack of modularisation
– NL structures are inadequate to structure system
requirements.
Alternatives to NL specification

Notation Description
Structured natural This approach depends on defining standard forms or templates to express the
language requirements specification.
Design This approach uses a language like a programming langu age but with more abstract
description features to specify the requirements by defining an operational model of the system.
language s This approach is not now widely used although it can be useful for interface
specifications.
Graphical A graphical languag e, supplemented by text anno tations is used to define the
notations functional requirements for the system. An early example of such a graphical
language was SADT. Now, use-case descriptions and sequence d iagrams are
commonly used .
Mathematical These are notations based on mathematical concep ts such as finite-state machines or
specifications sets. These unambiguous specifications reduce the arguments between customer and
contractor about system functionalit y. Howeve r, most customers don’t understand
formal specifications and are reluctant to accept it as a system contract.
Graphical models

⚫ Graphical models are most useful when you

need to show how state changes or where
you need to describe a sequence of actions.
⚫ Different graphical models can be used.
Sequence diagrams

⚫ These show the sequence of events that take

place during some user interaction with a
system.
⚫ You read them from top to bottom to see the
order of the actions that take place.
⚫ Cash withdrawal from an ATM
– Validate card;
– Handle request;
– Complete transaction.
 Sequence diagram of ATM
withdrawal
ATM Database

⚫ See diagram; Card

Card number

Card OK
PIN request
PIN
Option menu Validate card

<<exception>>
invalid card

Withdraw request Balance request

Balance
Amount request
Handle request
Amount
Debit (amount)

<<exception>> Debit response

insuf ficient cash

Card

Card removed
Complete
Cash transaction

Cash removed
Receipt
Guidelines for writing requirement

⚫ Invent a standard format and use it for all

requirements.
⚫ Use language in a consistent way. Use shall
for mandatory requirements, should for
desirable requirements.
⚫ Use text highlighting to identify key parts of
the requirement.
⚫ Avoid the use of computer jargon.
The requirements document

⚫ The requirements document is the official

statement of what is required of the system
developers.
⚫ Should include both a definition of user
requirements and a specification of the
system requirements.
⚫ It is NOT a design document. As far as
possible, it should set of WHAT the system
should do rather than HOW it should do it
Users of a requirements document

⚫ They are:
IEEE requirements standard

⚫ Defines a generic structure for a

requirements document that must be
instantiated for each specific system.
– Introduction.
– General description.
– Specific requirements.
– Appendices.
– Index.
The Structure of SRS Document
⚫ Preface
⚫ Introduction
⚫ Glossary
⚫ User requirements definition
⚫ System architecture
⚫ System requirements specification
⚫ System models
⚫ System evolution
⚫ Appendices
⚫ Index
 REQUIREMENTS OF
ENGINEERING PROCESS

⚫ To develop a product on time and within

budget the members of the software
development team should agree on what the
software product is to do.
⚫ The first step in achieving this unanimity is to
analyze the client’s current situation as
precisely as possible.
Requirements engineering

⚫ The process of establishing the services that

the customer needs from a system and the
constraints under which it operates and is
developed.
Feasibility Studies

⚫ It is basically the test of the proposed system

in the light of its workability.
⚫ It aim is to determine whether it would be
financially and technically feasible to develop
the product.
⚫ The areas: Technical, Economic, Legal,
Operational, and Schedule.
 Requirements Elicitation and
Analysis

⚫ The process of discovering the client’s

requirements is termed requirements
elicitation.
⚫ The process of refining and extending them
is known as requirements analysis.
Information Gathering

⚫ The first step in user requirements analysis is

to gather background information about the
users and stakeholders and the processes
that currently take place.
⚫ Stakeholder analysis
⚫ User surveys
Stakeholder analysis

⚫ identifies all the users and

stakeholders.
⚫ This helps ensure that the needs of all
those involved are taken into account.
⚫ User groups may include end users,
supervisors, installers, and maintainers.
User Surveys

⚫ This involves administering a set of

written questions to a sample
population of users.
Parallel Design Sessions

⚫ Have a few small groups of designers

working independently, to generate a
range of diverse solutions.
⚫ This promotes creativity and innovation
Methods

⚫ Interview
⚫ Evaluating an existing or competitor
system
⚫ Brainstorm: generate new ideas by freeing
the mind to accept any idea that is suggested
⚫ Prototyping
END
Session outline

⚫ Last week KeyNotes

⚫ Documentation details
⚫ System models
Requirement Gathering Methods

⚫ User Needs Identification

1. Stakeholder analysis
2. Interviewing
3. Task analysis
4. Evaluating an existing or competitor
system
5. Future workshops
 Requirements Validation and
Evaluation

⚫ Initial user requirements developed

⚫ User feedback can then be obtained on the
prototype to validate and refine the user
requirements.
⚫ Potential techniques are:
 Brainstorming

⚫ This session brings together a set of design

and task experts to inspire each other in the
creative, idea generation phase of the
problem solving process.
⚫ They are used to generate new ideas by
freeing the mind to accept any idea that is
suggested, thus allowing freedom for
creativity.
Prototyping
⚫ Designers create paper or software-based
simulations of user interface elements (menus,
buttons, icons, windows, dialogue sequences,
etc.) in a static or dynamic way.
⚫ When a paper prototype has been prepared,
a member of the design team sits before a
user and 'plays the computer' by moving the
paper and card interface elements around in
response to the user's actions.
Allocation of function
⚫ The division of system tasks into those
performed by humans and those performed
by technology" to specify a clear system
boundary.
Parallel Design Sessions

⚫ A few small groups of designers working

independently, to generate a range of
diverse solutions.
⚫ The aim is to develop and evaluate different
system designs before choosing a solution
(possibly drawing from several solutions) as
a basis for the implemented system.
Documentation

⚫ Introduction
ARK High School is currently using the
traditional database system in keeping records.
This method of record keeping always leads to
destruction of about 10% of vital documents in
stock, due to mishandling by workers, pests
attack and water. These prompted software
engineering team to develop a system to help
manage the records of the school.
 Purpose

⚫ This project is on the whole aim at creating

an efficient and reliable database system to
handle or manage the records of students
and staff of ARK High School.
⚫ The system will be designed to cater for
keeping and having rapid access to stored
data.
Glossary

⚫ Glossary (Definitions, Acronyms and

abbreviations)
1. ARK High School : Afriyie Rockson Kwasi
High School. The name of the school.
2. The Clear Button: A clickable area which
works by erasing the data.
3. Others.
DESCRIPTION

Product perspective
⚫ The product is designed to help store and
manage the general information of staff and
students of ARK High School
⚫
Product functions

⚫ The system will have a very friendly and

interactive graphic user interface (GUI) which
will make it easy for anyone with little
knowledge in Windows Operating System to
get familiar with.
⚫ The system is designed with Java SDK.
⚫ The system puts maximum control in the
hands of the user by providing interactive
forms of command buttons, input boxes,
tables, drop down lists, etc.
User Characteristics

⚫ The software is designed to provide a login screen

which gives the users (actors) of the system
access to login or get into the system.
⚫ The user enters a username and password, and
clicks the login button to authenticate and get him
into the system.
⚫ The next page provides the data entry clerk or the
user of the system another page to enter or set
student’s information or data.
⚫ It gives the Date of Admission, Student ID (which
Constraints

⚫ The system shall run on Windows operating

system platform.
⚫ The system should be used alongside the
existing systems.
⚫ After entering the information or data of a
student, user clicks the Save Button to save
the student record.
⚫ The fields shall be cleared after saving the
student data.
Assumptions and Dependencies

⚫ The requirements for the system will be

gathered based on the information available.
⚫ The system will be used by data entry clerks
who are trained by the developer.
⚫ Any other computing skill acquired by the user
will help improve the user’s ability to use the
system.
 Requirements

Functional Requirements
⚫ The system shall provide a list of modules
from which a user will select from.
⚫ The system shall provide hyperlinks between
pages
⚫ The system shall provide a means for
entering and storing information about a
selected module.
 Functional Requirements

⚫ The system shall take into consideration the

type of input values in terms of data types that
is to be used for a given module.
⚫ The system shall notify the user if no valid
data has been entered for a given module and
shall indicate the causes that prevent the
system from accepting such data.
⚫ All interfaces shall follow the windows XP
standard.
User requirements

⚫ This system is designed to be user-friendly.

The users of this system will be able to:
⚫ Display student’s information when queried.
⚫ Enable the various users (actors) of the
system access to view some portions of
stored data
⚫ Provide a baseline record against which
improvement or deterioration may be judged.
System requirements

The system will:

⚫ Store all information the school deemed
important in one centralized database - from
basic student records, teachers’ details,
student houses, etc.
⚫ Some of the captured records will remain the
same such as date of birth while others will
change due to current updates.
Performance Requirements

⚫ Automatically generates ids or

codes for students, staff, course,
etc.
⚫ Allows quick entry of student, staff,
etc. records into the system.
Specification

⚫ Software or application shall be user-friendly

and flexible for use.
⚫ Software should be easy to learn and use.
⚫ Software shall always show login screen to
authenticate users to use the system.
⚫ Software shall have a logout functionality or
link so that users can logout to prevent
unauthorized access to the system by people
who are not part of the system.
Specification

⚫ Shall allows a user to enter username and

password for authentication before system
use.
⚫ A user-friendly interface which allows any
user to learn it in a very short time without
problems.
END
Session Outline

⚫ Requirement Analysis
⚫ System Models
⚫ Types of Models
⚫ Merits of DFD
 System Models

⚫ A model is a conceptual system view.

⚫ Models are used as part of a systemic
approach to a range of different situations.
⚫ Used in different ways as part of a process for
1. improving understanding of a situation
2. identifying problems
3. formulating opportunities
4. supporting decision making.
Types of Models

⚫ Models provide different system

information.
⚫ They use function-based decomposition
to focus on the function performed in the
problem domain, data consumed and
produced by the functions.
 Types of Models

1. Data flow models are used to form the data

processing in a system.
2. Context models show the position of a system in
its environment with other systems and processes.
3. State machine models are used to form the
system’s behaviour in response to internal or
external events.
4. Sequence models show the interactions between
actors and the system objects that they use.
Data Flow Diagrams (DFDs)

⚫ Important tool used by system analysts.

⚫ A data flow diagram models a system using
external entities from which data flows to a
process which transforms the data and create
output data: go to other processes or external
entities such as files.
⚫ Data in files may also flow as input to
processes.
Data flow diagrams

⚫ DFDs model the system from a functional

perspective.
⚫ Tracking and documenting how the data
associated with a process is helpful to develop
an overall understanding of the system.
⚫ Data flow diagrams may also be used in
showing the data exchange between a system
and other systems in its environment.
Merits of DFD

⚫ Provide an overview of what data a system

would process, what transformations of data are
done, what files are used and where the results
flow.
⚫ The graphical representation of the systems
makes it a good communication tool between a
user and analyst.
⚫ Starting from a simple diagram provides a broad
overview at a glance, expanded to a hierarchy of
diagrams giving more and more detail.
Symbols used in DFDs

⚫ Named circles – to represent processes.

process processes show what system do

⚫ Data flows – Labeled arrows entering or

leaving processes.
Symbols used in DFDs

⚫ Named Rectangles – represents the external

entities such as clients, vendors or customers
with whom the system interacts.

Customer External entity

-Entities supplying data are sources and

those that consume data are called sinks.
Symbols used in DFDs

⚫ Labeled straight line – represents all external

files such as employee's records, company
records, etc.
⚫ A data flow can take place:
1. Between processes
2. File to process
3. External entity to process
4. Process to external entity
5. Process to file
DFDs: Rules
⚫ Every data flow must involve a process
⚫ No crossing/dividing/joining of data flows
⚫ Data flow cannot take place between files; between
external entities
⚫ Data flows are not bidirectional
⚫ No miracles (no output only)
⚫ No blackholes (no inputs only)
Symbols used in DFDs
Context Diagram

⚫ The context diagram treats entire system as a

single process with all its inputs, outputs, links
and sources identified.
Context Diagram of Budget system
Context Diagram

⚫ The system interacts with 3 external entities:

Department, Management and Suppliers
⚫ 3 main data flows from department entity:
1 spending request
2. rejected/approval
3. Delivery
Top Level DFD for Budget
Monitoring System
 Top Level DFD for Budget
Monitoring System Cont’d

⚫ Spending request” from departments goes to ‘check

funding’ process.
⚫ This process checks whether a special request for
approval is required or not.
⚫ If a special approval request is needed, it places the
request for approval.
⚫ The ‘classify expenditure’ process receives approved
request and they are entered into data stores
DEPARTMENTAL-ACCOUNTS and TYPEACCOUNTS.
⚫ Finally, it required on ‘order’ is placed with the
SUPPLIERS.
Example of process

Equipment procurement process

Complexity of Diagrams

⚫ If a DFD contains all details, then it will have too

many data flow lines.
⚫ Mixed up and it will be difficult to understand all
data flows and their processing.
⚫ Start with a context diagram and expand the
process into interconnected set of processes.
⚫ This expanded DFD should specify the next
level of detail and should be understandable at
glance.
Context Diagram: Sales
Leveling

⚫ Each of the processes in this top-level DFD is

further expanded into another DFD.
⚫ The method of expanding a process in a DFD
into a set of equivalent smaller processes is
called leveling.
⚫ DFDs that are hierarchically organized are called
leveled DFDs.
⚫ For the hierarchy to be consistent, net inputs and
outputs for a process are same as that of the
process in the higher level DFD.
⚫ Let us consider the classify expenditure process
1. Process 3.1 classifies the entries in each approved
request by expense type (such as material and capital
overhead).
2. Process 3.2 uses this classification to update type
accounts.
3. The process 3.3 sums up all entries for the whole
request.
4. Process 3.4 updates the Departmental-Accounts file.
Expanded DFD for process
'classify expenditure'
Data dictionaries

⚫ A data dictionary is a central repository that

provides a comprehensive list of data elements and
their definitions.
⚫ It describes a system's data elements and
structures.
⚫ Purpose: It serves as a reference guide for
developers, providing detailed information about the
data attributes, relationships, and constraints within a
system.
Data dictionaries

⚫ They contain the details of the structure of

data items and files used in DFDs.
⚫ Descriptions of the entities, relationships and
attributes are also included.
⚫ Advantages
– Support name management and avoid
duplication;
– Store of organisational knowledge linking
analysis, design and implementation;
⚫ The data dictionary entries for the process 3 (‘Classify Accounts’)
are shown below.
⚫ DEPARTMENTAL – ACCOUNTS=DEPT-NO+TOTAL-EXP
⚫ TYPE-ACCOUNTS=TYPE+TOTAL-AMOUNT
⚫ Approved- Request =DEPT-NO+REQUEST-
NO+AMOUNT+DESCRIPTION
⚫ Classified-Request = DEPT-NO+REQUEST-
NO+AMOUNT+TYPE
⚫ Update = DEPT-NO+REQUEST-NO+AMOUNT
⚫ Request-total = DEPT-NO+REQUEST-NO+ Request-Sum
⚫ Recorded-request = DEPT-NO+REQUEST-NO+ Request-Sum
Data Dictionary

⚫ Sample data Dictionary

Name Description Type Date
Details of the published article that may be ordered by
Article Entity 30.12.2002
people using LIBSYS.
The names of the authors of the article who may be due
authors Attribute 30.12.2002
a share of the fee.
The person or organisation that orders a co py of the
Buyer Entity 30.12.2002
article .
A 1:1 relationship between Article and the Copyright
fee- Relation 29.12.2002
Agency who should be paid the copyright fee.
payable-to
The address of the buyer. This is used to any paper
Address Attribute 31.12.2002
billing information that is required.
(Buyer)
 Verification of DFDs and Data
Dictionaries

⚫ verify that DFD and associated DD are correct.

⚫ Look for some common errors:
⚫ Unlabelled data flows.
⚫ Missing data flows; information required by a
process is not available.
⚫ Data flows are not being used in the system.
⚫ Consistency not maintained during leveling
refinement.
⚫ Missing processes.
Steps in data flow analysis

⚫ Study the physical environment of the current

system.
⚫ Construct the context diagram showing the
inputs, outputs, links, sources etc. for the
whole system.
⚫ Draw the top level DFD of the system,
showing the data flows and processes in the
current system.
Data flow analysis cont’d

⚫ Draw the detailed DFD containing expanded

hierarchical processes of the top-level
processes.
⚫ Verify the DFD of the system.
⚫ Create the data dictionary.
Method Weaknesses

⚫ They do not model non-functional system

requirements.
⚫ They do not usually include information about
whether a method is appropriate for a given
problem.
⚫ The may produce too much documentation.
⚫ The system models are sometimes too detailed
and difficult for users to understand.
CLASS WORK: Problem Statement
GHS lacks a centralized surveillance system which poses
significant challenges in ensuring consistent quality control,
real-time monitoring, and data analysis across all surgical
operation departments. To address these pressing concerns, a
web-based surveillance system capable of seamlessly
integrating with GHS existing infrastructure and providing
comprehensive monitoring functionalities across its network
of branches is required. 1. State three functionalities of the
system
2. Draw the context diagram of the system
ASSIGNMENT PRESENTATION
Software Design
⚫ System design
⚫ Implementation
Software Design
Software Design
⚫ The Unified Modeling Language, is 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
⚫ Business modeling and other non-software
systems.
Software Design
⚫ The UML uses mostly graphical notations to
express the design of software projects.
Using the UML helps project teams
communicate, explore potential designs, and
validate the architectural design of the
software.
System design
⚫ Unified modelling Language illustrates the
architectures of the software components and the
dependencies between them
⚫ The UML uses graphical notations to express the
design of software projects.
System design
System design
⚫ During design, the components do not exist
⚫ The designer specifies only the abstract
(intangible) specifications of the different
components.
⚫ The goal is to specify the modules in a system
and their abstraction.
⚫ Once the different modules are specified during
the detailed design, the designer can
concentrate on one module at a time.
System design
⚫ The task in detailed design and
implementation is essentially to implement
the modules such that the abstract
specifications of each module are satisfied.
Designing a Product
⚫ There are basically two ways:
1. Operation-oriented design
2. Data-oriented design.
In the operation-oriented design, the emphasis
is on the operation; an example is data flow
analysis, where the objective is to design
modules with high cohesion.
Data-oriented design
⚫ In data-oriented design, the data are
considered first.
⚫ Thus, the structure of the data is determined
first, and then the procedures are designed
to conform to the structure of the data.
Design and Abstraction

⚫ The design phase consists of three activities:

- architectural design,
- detailed design
- design testing.
⚫ The input of the design process is the
specification document, a description of what the
product is to do.
⚫ The output is the design document, a description
of how the product is to achieve this.
Architectural design

⚫ Known variously as general design, logical

design, or high-level design), a modular
decomposition of the product is developed.
⚫ That is, the specification are carefully
analysed and a module structure that has the
design functionality is produced.
Detailed design
⚫ The next activity after architectural design is
the detailed design, also known as modular
design, physical design, or low-level design,
during which each module or class is
designed in depth or thoroughly.
⚫ For instance, specific algorithms are selected
and data structures are chosen.
Design Testing
⚫ Testing is an integral part of design, just as it is
an integral part of software development and
maintenance process.
⚫ The goal of testing the design is to verify that the
specifications have been accurately and
completely incorporated into the design as well
as to ensure the correctness of the design itself
⚫ For example, the design must have no logic
faults and all interfaces must be correctly
defined.
⚫ It is important that any faults in the design be
detected before coding commences;
otherwise, the cost of fixing the faults will be
considerably higher.
Design Principles

⚫ The design of a system is correct if a system is

built according to the requirements of that
system.
⚫ The purpose of design phase is to produce the
current designs.
⚫ The goal of the design process is to find the best
possible design.
⚫ To evaluate a design, specify some properties
and criteria that can be used for evaluation.
⚫ Some of the desirable properties for a software
system design are:
-Verifiability
-Completeness
-Consistency
-Efficiency
-Traceability
-Simplicity/Understandability
Design Reviews

⚫ The purpose of design review is to ensure that

the design satisfies the requirements and that
the design is of good quality.
⚫ Detecting errors in design is the aim of design
reviews.
⚫ The design review process involves a group of
people get together to discuss the design with
the aim of revealing design errors or
undesirable properties.
Composition of review group

⚫ The review group must include a member of:

1. the system design team
2. the detailed design team,
3. author of the requirement document
4. author responsible for maintaining the
design document
5. Independent software quality engineer.
Reviewing a Design

⚫ Each member studies the design before the

meeting and marks items deems incorrect or
needs clarification.
⚫ The aim of the meeting is to uncover design
errors and not try to fix them. Fixing is done later.
⚫ The meeting ends with a list of action items,
which are later acted upon by the design team.
⚫ Further reviews may be organized if needed.
Detailed Design Methods

⚫ Many design techniques, like the structured

design, identify the major modules and major
data flow among them.
⚫ The functionality of the module is
communicated by the name of the module,
and the interface is expected to be derived
from the data flow to and from the module.
 Program Description Language
(PDL)

⚫ Also known as Process Design Language, or

pseudo-code) (PDL) is one way in which the
design can be communicated precisely.
⚫ Pseudo-Code is simply a numbered list of
instructions to perform some task
⚫ PDL can be used to specify the complete
design – system as well as logic design – to
whatever degree of detailed desired by the
designer.
⚫ Pseudo-code the task of computing the final price of an
item after figuring in sales tax. Note the three types of
instructions: input (get), process/calculate (=) and output
(display)
1. get price of item
2. get sales tax rate
3. sales tax = price of item times sales tax rate
4 final prince = price of item plus sales tax
5. display final price
6. halt
Variables: price of item, sales tax rate, sales tax, final price
⚫ PDL has an overall outer syntax of a
structured programming language and has a
vocabulary of a natural language.
⚫ Since the structure of a design expressed in
PDL is formal using the formal language
construct, some amount of automated
processing can be done on such designs.
 PDL Example
⚫ Finding out the minimum and maximum of a set of numbers in a file,

minmax (infile)
Array a
Do UNTIL end of input
READ an item into a
ENDDO
(Max, min) := first item of a
DO FOR each item in a
IF max < item THEN Set max to item
IF min > item THEN Set min to item
ENDDO
END
Advantages of PDL

⚫ PDL gives the entire logic of the procedure but

little about the details of implementation in a
particular language.
⚫ To implement this in a language, each of the
PDL statements will have to be converted into
programming language statements.
⚫ With PDL, a design can be expressed in
whatever level of detail that is suitable for the
problem.
Advantages of PDL

⚫ A PDL has the advantage that it generally is

clear and concise, and the implementation
step usually consists merely of translating the
comment into the relevant programming
language.
Pitfalls

⚫ The weakness is that sometimes there is the

tendency for the designer to go into too much
detail and produce a complete code of a
modular rather than a PDL detailed design.
Coding the design

⚫ After it has been fully documented and

successfully tested, the detailed design is
handed over to the implementation team for
coding.
Coding the Design

⚫ After it has been fully documented and

successfully tested, the detailed design is
handed over to the implementation team for
coding.
Verification and Validation

⚫ Verification refers to the set of activities that

ensure that software correctly implements a
specific function.
⚫ Validation refers to a different set of activities
that ensure that the software that has been
built is traceable to customer requirements.
Verification and Validation

⚫ Verification: Are we building the product right?

⚫ Validation: Are we building the right product?

SRS Validation

⚫ Encompasses a lot of SQA activities:

⚫ Formal technical reviews
⚫ Quality and configuration audits
⚫ Performance monitoring
⚫ Simulation
⚫ Feasibility study
SRS Validation

⚫ Documentation review
⚫ Database review
⚫ Algorithm analysis
⚫ Development testing
⚫ Qualification testing
⚫ Installation testing
SRS Validation

⚫ Common types of errors in SRS are:

⚫ Omission: - Some user requirement is not
included in SRS. This error directly affects the
external completeness of the system.
⚫ Inconsistency: - Is due to contradictions in
requirements or incompatibility of state
requirements.
SRS Validation

⚫ Incorrect fact: - Some facts recorded in SRS

are not correct.
⚫ Ambiguity: - Some requirements have
multiple meanings.
Methods of Requirements
Validation

⚫ The output of the system design should be

verified before proceeding with activities of the
next phase.
⚫ Requirements Reviews
Methods of Requirements
Validation

⚫ SRS is carefully reviewed by representatives

of clients, users and developers.
⚫ Each participant is asked to go through
requirements, mark the defects before
attending the meeting.
⚫ The participant goes through a list of defects,
the requirements analyst provides clarification
if there is an error, or else accepts the defect
and makes a note of it.
Methods of Requirements
Validation

⚫ Are all hardware resources specified?

⚫ Have response times for all functions been
specified?
⚫ Have all hardware, external software and data
interfaces been specified?
⚫ Is each requirement testable?
Methods of Requirements
Validation

⚫ Is initial state of the system specified?

⚫ Are all future modifications specified?
⚫ Are the responses to exceptional conditions
specified?
Reading

⚫ Someone other than SRS author is asked to

read the document and detect errors.
⚫ Using this method, many of the requirements
problems caused by misinterpretations and
ambiguities can be identified.
⚫ The issues that could cause problems later
may also be detected.
Scenarios

⚫ Scenarios are used for clarifying

misunderstandings in the man-machine
interaction.
⚫ Scenarios describe different situations of how
the system will work once if it is operational.
⚫
Prototypes

⚫ Prototypes are used to test the feasibility of

some requirements.
⚫ A prototype that is built during problem
analysis can also aid validation.
Software Testing

⚫ Testing is an integral component of the

software development process and activity
that must be carried out throughout the life
cycle.
⚫ Software Quality Assurance (SQA) group.
What then is testing?

⚫ It is the process of analyzing a software item

to detect the differences between existing and
required conditions (i.e., bugs) and to
evaluate the features of the software items.
⚫ The process of analyzing software with the
intent of finding errors.
⚫ .
Testing Fundamentals

⚫ Error: The term error is used to refer to the

discrepancy between computed, observed, or
measured value and the true or specified
value.
⚫ In other words, it is the difference between the
actual output of software and correct output.
⚫
Testing Fundamentals

⚫ Fault: Fault is a condition that causes a

system to fail in performing its required
function.
⚫ Failure: Failure is the inability of a system to
perform a required function according to its
specifications.
Testing Fundamentals

⚫ Defect: Defect is a general term that refers to

fault, failure or error.
Test Plan

⚫ A plan for conducting the necessary tests that

incorporates testing strategies, test
procedures, test data, and a test schedule.
Types of Test

⚫ Integration Testing
⚫ Incremental Testing
⚫ System Testing
⚫ Acceptance Testing
Alpha and Beta Testing

⚫ A plan for conducting the necessary tests that

incorporates testing strategies, test
procedures, test data, and a test schedule.
Alpha and Beta Testing

⚫ A customer conducts the alpha test at the

developer’s site. The software is used in a
natural setting with the developer "looking
over the shoulder" of the user and recording
errors and usage problems.
⚫ Alpha tests are conducted in a controlled
environment.
⚫ The developer is present taking notes of the
difficulties of the user.
Alpha and Beta Testing

⚫ A customer conducts the alpha test at the

developer’s site. The software is used in a
natural setting with the developer "looking
over the shoulder" of the user and recording
errors and usage problems.
⚫ Alpha tests are conducted in a controlled
environment.
⚫ The developer is present taking notes of the
difficulties of the user.
Beta Testing

⚫ The beta test is conducted at one or more

customer sites by the end-user of the
software.
⚫ The developer is generally not present.
Therefore, the beta test is a "live” application
of the software in an environment that cannot
be controlled by the developer.
Beta Testing

⚫ The customer records all problems that are

encountered during beta testing and reports
these to the developer at regular intervals.
⚫ As a result of problems reported during beta
tests, the developers make modifications and
then prepare for release of the software
product to the entire customer base.
Acceptance Testing

⚫ This is the testing performed to make sure

that the product delivered indeed satisfies the
requirements as agreed by the client
⚫ Perform by SQA group in the presence of
client representative, or an independent SQA
group hired by the client for this purpose.
Acceptance Testing

⚫ The four major components of acceptance

testing are: testing correctness, robustness,
performance and documentation.
Acceptance Testing

⚫ When to Stop Testing

⚫ After a product has been successfully
maintained for many years.
⚫
Acceptance Testing

⚫ It eventually may lose its usefulness and be

superseded by a totally different product.
⚫ A product may be still useful but the cost of
porting it to new hardware or running it under
a new operating system may be more than a
cost of constructing a new product
⚫ So, finally, the software product is
decommissioned and removed from service.