Software Engineering

(PC-IT-SOE204)

Dr. Gaurav Srivastava

 Syllabus
Unit 1
• Introduction to Software Engineering, Software
characteristics, Software components, Software
applications, Software Engineering Principles,
Software metrics and measurement, monitoring
and control. Software development life-cycle,
Water fall model, prototyping model, Incremental
model, Iterative enhancement Model, Spiral
model, agile models and recent developments in
SE models.
 Unit 2
• Requirements Elicitation Techniques, Requirements
analysis, Models for Requirements analysis,
requirements specification, requirements validation,
Modeling and Architecture, Design Principles,
Problem partitioning, abstraction. Top down and
bottom up – design, structured approach. Functional
versus object oriented approach of design, design
specification, Cohesiveness and Coupling. Overview
of SA/SD Methodology, structured analysis, UML
diagrams. Data flow diagrams, extending DFD to
structure chart.
 Unit 3
• Software project Planning, Project scheduling.
Software Metrics: Size Metrics like LOC, Token
Count, Function Count. Cost estimation using
models like COCOMO. Risk management
activities. Software Reliability and Quality
Assurance: Reliability issues, Reliability metrics,
reliability models, Software quality, ISO 9000
certification for software industry, SEI capability
maturity model, Client server software
development.
 Unit 4
• Verification and validation, code inspection, test
plan, test case specification. Level of testing:
Unit, Integration Testing, Top down and bottom
up integration testing, Alpha and Beta testing,
System testing and debugging. functional
testing, structural testing, Software testing
strategies, Software reliability and quality,
Software maintenance and reuse, Structured Vs
unstructured maintenance, Maintenance Models,
Configuration Management, Reverse
Engineering, Software Re-engineering.
 Books & References
• Software Engineering, Ian Sommerville,
Pearson Education, Inc., publishing as
Addison-Wesley.
• Software Engineering-A practitioner’s
approach, Roger S Pressman, Mcgraw-Hill
• Software Engineering: Principles And Practice,
Waman S Jawadekar, Tata McGraw-Hill
Education Pvt. Ltd.
 Software Engineering
• What is software engineering?
• Software engineering is a branch of engineering that involves
the systematic design, development, testing, and
maintenance of software systems.
• It encompasses a disciplined and systematic approach to the
entire software development life cycle, from initial
conception and requirements analysis to design, coding,
testing, deployment, and maintenance.
• IEEE Definition: The application of a systematic, disciplined,
quantifiable approach to the development, operation, and
maintenance of software.
 Primary Goal of Software Engineering
• Efficiency: Developing software in a way that
maximizes efficiency, both in terms of the resources
used during development and the performance of the
software during operation.
• Reliability: Ensuring that software behaves as
intended and is free from errors or bugs. This involves
rigorous testing and quality assurance processes.
• Maintainability: Designing software in a way that
makes it easy to understand, modify, and maintain
over time. This is crucial for adapting to changing
requirements and fixing issues.
Primary Goal of Software Engineering
• Scalability: Designing software systems that can
handle growth and increased demand without a
significant loss of performance.
• Reusability: Encouraging the reuse of code and
components to save time and resources during
development.
• Security: Implementing measures to protect software
systems from unauthorized access, data breaches, and
other security threats.
• Collaboration: Fostering effective communication and
collaboration within development teams, as well as
between development teams and other stakeholders.
 Definition
• Software is
1. Instructions (computer programs) that when
executed provide desired features, function,
and performance.
2. Data structures that enable the programs to
adequately manipulate information.
3. Documents that describe the operation and
use of the programs.
 Characteristics of Software
• Software is developed or engineered; it is not
manufactured in the classical sense.
 Characteristics of Software
• Software doesn’t wear out, but it does
deteriorate.
 Characteristics of Software
• Software deterioration" refers to the gradual
decline in the quality, reliability, or performance
of software over time. This degradation can occur
due to various factors and may manifest in several
ways:
• Bugs and Defects
• Performance Degradation
• Obsolete Dependencies
• Changing Requirements
• Environmental Changes
 Software Components
• Software components refer to the different
parts or modules that make up a software
system. These components work together to
achieve specific functionalities and contribute
to the overall operation of the software. Here
are various types of software components
commonly found in software systems.
 User Interface (UI) Components
• Forms, Buttons, Input Fields: These
components allow users to interact with the
software by providing input and receiving
output.
• Menus, Toolbars: UI components for
navigation and accessing various functions.
• Dialog Boxes, Alerts: Components for
displaying messages or requesting user input.
 Application Logic Components
• Business Logic: Components that implement
the rules and processes specific to the
application domain.
• Data Processing: Components that handle
data manipulation, calculations, and
transformations.
• Workflow Management: Components for
managing and coordinating tasks and
processes within the application.
 Data Storage Components
• Databases: Components that store and
manage structured data.
• File Systems: Components for storing and
retrieving files and unstructured data.
• Caches: Components that store frequently
accessed data for quick retrieval.
 Integration Components
• APIs (Application Programming Interfaces):
Components that define how software systems or
modules interact with each other.
• Middleware: Components that facilitate
communication and data exchange between
different software applications or components.
• Messaging Systems: Components for
asynchronous communication and event-driven
architectures.
 Security Components
• Authentication: Components for verifying
user identities and access rights.
• Authorization: Components that enforce
access control policies.
• Encryption: Components for securing data in
transit and at rest.
 Utility Components
• Logging and Monitoring: Components for
recording events, errors, and performance
metrics.
• Configuration Management: Components for
managing application settings and
parameters.
• Error Handling: Components that manage and
report errors and exceptions within the
software.
 Infrastructure Components
• Operating System Interfaces: Components
that interact with the underlying operating
system to manage resources.
• Networking: Components for communication
between distributed systems and services.
• Virtualization and Containerization:
Components for managing and isolating
software environments.
 Third Party Components
• Third-Party Libraries: Components developed
by external vendors or open-source
communities that provide additional
functionalities. For ex: NumPy
• Frameworks: Pre-built components and
structures that simplify software development
for specific tasks or domains (e.g., web
frameworks, UI frameworks, React (Java script
library for building user interface).
 Types of Software
• System Software:
• It is a collection of programs written to service
other programs. For ex- compilers, editors,
operating system, drivers etc.
 Application Software
• Application software consists of standalone
programs that solve a specific business need.
• Ex: MS word, paint etc.
 Enterprise Software
• Enterprise software is designed to meet the needs
of an organization rather than individual users.

Enterprise Resource Planning (ERP) -SAP ERP, Oracle

ERP Cloud.
Supply Chain Management(SCM) - SAP SCM, Oracle
SCM Cloud.
Customer Relationship Management (CRM) -
Salesforce, HubSpot CRM
 Engineering/Scientific Software
• Engineering and scientific software refers to
specialized applications developed for
performing complex calculations, simulations,
modeling, analysis, and data visualization in
scientific research, engineering design, and
technical computing fields.
• Ex: CAD, MATLAB, R etc.
 Embedded Software
• Embedded software refers to computer programs
and code that are specifically designed to control
and operate embedded systems.
• An embedded system is a specialized computing
system that is part of a larger device or machine,
typically with dedicated functions and often with
real-time computing constraints.
• Ex: Keypad control for a microwave oven
(firmware)
 Product Line Software
• Designed to provide a specific capability for
use by many different customers.
• Ex: database management software,
multimedia software, financial application
software.
 Web Applications
• Web application software refers to software
applications that run on web servers and are
accessed by users over the internet through
web browsers.

• Ex: Social Media Platforms: Facebook, Twitter, Instagram

• E-commerce Platforms: Amazon, flipkart etc
 Artificial Intelligence Software
• Artificial Intelligence (AI) software refers to
computer programs and systems that exhibit
behavior and capabilities traditionally associated
with human intelligence. These software applications
use algorithms, data, and machine learning
techniques to simulate cognitive functions such as
problem-solving, learning, reasoning, perception,
understanding natural language, and
decision-making.
• Ex:
 Software Engineering Principles
• Rigor and Formality
• Separation of Concerns
• Modularity and Decomposition
• Abstraction
• Anticipation of Change
• Generality
• Incrementality
• Reliability
 Rigor and Formality
• Rigor involves applying precise and meticulous
attention to detail in software development.

• Formality refers to the use of formal methods

and mathematical techniques to specify,
develop, and verify software systems.
 Separation of Concerns
• This principle involves dividing a software
system into distinct sections, each addressing
a separate concern or functionality.
 Modularity and Decomposition
• Modularity is the division of a software system
into discrete modules that can be developed,
tested, and maintained independently.
Decomposition refers to breaking down a
complex system into smaller, manageable
parts.
 Abstraction
• Abstraction involves hiding the complex
implementation details of a system and
exposing only the necessary and relevant
aspects.
 Anticipation of Change
• Designing software with the expectation that
requirements will change over time and
ensuring that the system can adapt to these
changes with minimal impact.
 Generality
• Generality involves designing software
components to be as general and reusable as
possible, rather than specific to one particular
use case.
 Incrementality
• Incremental development involves building a
system in small, manageable increments or
iterations, each adding a small amount of
functionality.
 Reliability
• Reliability refers to the ability of a software
system to perform its required functions
under stated conditions for a specified period
of time.
 Software Development Myths
Management Myths
• We already have a book that's full of
standards and procedures for building
software. Won't that provide my people with
everything they need to know?
• If we get behind schedule, we can add more
programmers and catch up .
• If I decide to outsource the software project
to a third party, I can just relax and let that fi
rm build it
 Customer Myths
• A general statement of objectives is sufficient
to begin writing programs—we can fill in the
details later.
• Software requirements continually change,
but change can be easily accommodated
because software is flexible.
 Practitioner’s Myths
• Once we write the program and get it to work,
our job is done.
• Until I get the program “running” I have no
way of assessing its quality.
• The only deliverable work product for a
successful project is the working program.
• Software engineering will make us create
voluminous and unnecessary documentation
and will invariably slow us down.
 Software Metrics and Measurement
• Software Metrics are quantitative measures used to assess
various aspects of software development and performance.

1. Product Metrics: Measure the characteristics of the software

product itself.
Examples: Lines of Code (LOC), complexity metrics (e.g., cyclomatic
complexity), and code coverage.
2. Process Metrics: Measure the effectiveness and efficiency of the
software development process.
Examples: Defect density, mean time to failure (MTTF), and development
time.
3. Project Metrics: Measure the management and progress of a
software project.
Examples: Schedule variance, cost variance, and effort estimation
accuracy.
SDLC
 What are the five generic process
framework activities?
• The following generic process framework is
applicable to the majority of software
projects.
• Communication.
• Planning.
• Modeling.
• Construction.
• Deployment.
 Process Models
• Software engineering process models are
structured frameworks used to plan, manage,
and control the development of software
systems.
• These models provide a systematic approach
to software development, ensuring that all
aspects of the software lifecycle are
addressed.
 Process Models
• Every software engineering organization should
describe a unique set of framework activities for
the software process it adopts.
• Waterfall Life Cycle Model.
• Iterative Waterfall Life Cycle Model.
• Incremental Model
• RAD Model
• Evolutionary Process Model
- Prototyping Model.
- Spiral Model.
 Waterfall Model
Winston Royce introduced the Waterfall Model in 1970.
It follows a sequential approach. Also called as classic lifecycle model.
Phases of the Classical Waterfall Model
Characteristics of the Waterfall Model
• Sequential and Linear: Each phase must be
completed before the next one begins.

• Documentation-Driven: Emphasizes detailed

documentation at each phase.

• Simple and Easy to Understand: Clear

structure and milestones.
 Pros and Cons
• Pros:
• Easy to Understand and Manage: Simple and clear structure.
• Well-Documented: Extensive documentation helps in
understanding and managing the project.
• Clear Milestones: Defined phases with specific deliverables.

• Cons:
• Inflexible to Changes: Difficult to go back to a previous phase
once completed.
• No overlapping of phases: It lack overlapping and interactions
among phases.
• Late Testing: Testing is done late in the process, leading to late
discovery of issues.
• Risky for Complex Projects: Not suitable for projects with high
uncertainty or complex requirements.
• Model doesn’t support delivery of system in pieces.
When to Use the Waterfall Model
• Small Projects: Suitable for small, simple
projects with well-understood requirements.
• Stable Requirements: When requirements are
clear, well-documented, and unlikely to
change.
• Project Control: When a structured approach
with clear documentation and milestones is
needed.
Iterative Waterfall model
 Advantages
• Flexibility: Allows for changes and improvements
at each stage, reducing the risk of costly errors
and rework.
• Risk Reduction: Early identification and resolution
of issues through continuous feedback and
iteration.
• Improved Quality: Frequent testing and
refinement lead to higher quality software.
• Stakeholder Involvement: Continuous feedback
from stakeholders ensures that the final product
meets their needs and expectations.
 Disadvantages
• Increased Complexity: Managing iterations
and changes can add complexity to the
project.
• Potential for Scope Creep: Frequent changes
and refinements may lead to scope creep if
not managed properly.
• Extended Timeline: Iterations may extend the
project timeline if not carefully controlled.
 V- model
• The V-Model, also known as the Verification and
Validation Model, is a software development
model that extends the Waterfall Model by
emphasizing the importance of verification and
validation.
• The V-Model illustrates the relationship between
development stages and their corresponding
testing stages, with a focus on ensuring that each
development phase is matched with appropriate
validation activities.
V - model
 Incremental Model
• A model where the software is developed in
incremental parts or modules, with each
increment adding functionality. This approach
allows partial product delivery and iterative
refinement.
Incremental Model
 Advantages
• Early Delivery of Functionality: Users get to use and
benefit from parts of the system early in the
development process.
• Adaptability: Allows for changes and refinements
based on user feedback and evolving requirements.
• Risk Management: Reduces risk by delivering
incremental parts of the system, making it easier to
identify and address issues early.
• Continuous Improvement: Enables ongoing
enhancement and refinement of the system based on
real-world usage and feedback.
 Disadvantages
• Integration Complexity: Frequent integration of
new increments can lead to challenges in ensuring
all components work together seamlessly.
• Incomplete System: Users may experience an
incomplete system if key functionalities are not
delivered in early increments.
• Scope Creep: There is a risk of scope creep as new
requirements and changes may be introduced in
each increment.
 RAD
• The Rapid Application Development (RAD) model
is a type of incremental software development
methodology that emphasizes an extremely short
development cycle.
• The RAD model is a high-speed adaptation of the
Waterfall model, where components or functions
are developed in parallel as mini-projects.
• The developments are time-boxed, delivered, and
then assembled into a working prototype.
• This model allows for iterative user feedback and
rapid adjustment, which leads to a final product
that meets user requirements more closely.
RAD
 When to use RAD model
• Short Development Timeframe.
• Well-Defined Business Objectives.
• High User Involvement and Feedback.
• Flexible and Adaptive Requirements.
• Availability of Skilled Team.
• Small and medium sized product.
 Advantages
• Speed: RAD significantly reduces the time required to
develop a software system, as it emphasizes rapid
prototyping and iterative delivery.
• Flexibility and Adaptability: Changes can be
incorporated quickly into the development process
based on user feedback, making it highly adaptable.
• User Involvement: Continuous user interaction
ensures that the final product meets user
requirements and expectations.
• Reduced Risk: Early and continuous iterations help
identify and mitigate risks early in the development
process.
 Disadvantages
• Need sufficient skilled human resources.
• The developed system should have proper
modularization characteristics.
• Requires User Commitment.
• Not suitable for large, complex projects.
 Evolutionary models
• What if the requirements at the beginning is
not very clear or the requirements are
expected to change over time.
• It is a combination of the Iterative and
Incremental models of the software
development life cycle.
 Prototype model
• The Prototype Model is a software
development approach that involves creating
a preliminary version of the software, called a
prototype, to explore and refine the
requirements and functionalities before
developing the final product.
• The Prototype Model (1975) was formally introduced by
Dr. Barry Boehm, a prominent figure in software
engineering, in his paper "Software Engineering with
Limited Resources".
 Cont..
• This model is particularly useful in projects
where requirements are not well understood
or are expected to change during the
development process.
• Prototype is the process of quickly putting
together a working model (a prototype) in
order to test various aspects of a design.
Cont..
 Two types of Prototype Models
• Throwaway prototype model
• Evolutionary prototype model
 Throwaway prototype model
• The Throwaway Prototype Model, also known
as Rapid Prototyping, involves creating a
preliminary version of the software to
understand and refine requirements before
discarding it.
• The focus is on quickly building a prototype to
gather feedback and improve the
understanding of the system's needs.
 Evolutionary Prototype Model

• The Evolutionary Prototype Model involves

continuously refining and evolving the
prototype until it becomes the final system.

• Unlike the throwaway approach, the

prototype in this model is not discarded but
incrementally improved through multiple
iterations.
 Pros & Cons
• Pros:
• Improved Understanding of Requirements.
• Early Detection of Issues.
• Enhanced User Involvement.
• Increased Flexibility.
• Risk Reduction
• Cons:
• Potential for Scope Creep.
• Increased Development Time and Cost.
• Incomplete or Inaccurate Prototypes.
• Over-Reliance on the Prototype.
 Spiral Model
• Originally proposed by Barry Boehm (1988), the spiral
model is an evolutionary software process model that
couples the iterative nature of prototyping with the
controlled and systematic aspects of the waterfall
model.
• Using the spiral model, software is developed in a
series of evolutionary releases.
• During early iterations, the release might be a model
or prototype.
• During later iterations, increasingly more complete
versions of the engineered system are produced.
Spiral Model
 Cont..
• The spiral model is a realistic approach to the
development of large-scale systems and
software.
• It is a risk driven process model, designed to
identify and mitigate risks throughout the
software development life cycle.
 Pros and Cons
• Pros:
1. Effective risk management.
2. Flexible to changes in requirements.
3. Continuous stakeholder involvement and
feedback.
• Cons:
1. Can be more complex to manage due to
continuous risk analysis.
2. Requires expertise in risk assessment and
management.
3. May be more costly due to the risk analysis
steps.
 Agile Methodology
• Agile methodology is an iterative and
incremental approach to software
development that emphasizes flexibility,
collaboration, customer feedback, and rapid
delivery.
• It is designed to accommodate change and
deliver high-quality software that meets user
needs.
 Cont..
• It is a combination of a philosophy and a set of
development guidelines.
• The philosophy encourages customer satisfaction and
early incremental delivery of software; small, highly
motivated project teams; informal methods; minimal
software engineering work products; and overall
development simplicity.
• The development guidelines stress delivery over analysis
and design (although these activities are not
discouraged), and active and continuous communication
between developers and customers.
 Key Principles of Agile Methodology
• Focus on effective communication and
collaboration among team members.
• Prioritize delivering functional software over
extensive documentation.
• Engage customers throughout the
development process to ensure the product
meets their needs.
• Embrace and adapt to changes in
requirements, even late in the development
process.
 Cont..
• An agile team is a nimble team able to
appropriately respond to changes.
• Changes in the software being built, changes to
the team members, changes because of new
technology, changes of all kinds that may have an
impact on the product they build.
• It emphasizes rapid delivery of operational
software and deemphasizes the importance of
intermediate work products.
• It adopts the customer as a part of the
development team.
 Agility Principle
• In 2001, Kent Beck and 16 other noted software developers,
writers, and consultants (referred to as the “ Agile Alliance ”)
signed the “Manifesto for Agile Software Development.
• The Agile Alliance defines 12 agility principles for those who
want to achieve agility.
1. Our highest priority is to satisfy the customer through early
and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development.
Agile processes harness change for the customer's
competitive advantage.
 Cont..
3. Deliver working software frequently, from a couple of weeks
to a couple of months, with a preference to the shorter
timescale.
4. Business people and developers must work together daily
throughout the project.
5. Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the
job done.
6. The most efficient and effective method of conveying
information to and within a development team is face-to-face
conversation.
7. Working software is the primary measure of progress.
 Cont..
8. Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain a
constant pace indefinitely.
9. Continuous attention to technical excellence and good design
enhances agility.
10. Simplicity—the art of maximizing the amount of work not
done—is essential.
11. The best architectures, requirements, and designs emerge
from self organizing teams.
12. At regular intervals, the team reflects on how to become
more effective, then tunes and adjusts its behavior accordingly.
 Extreme Programming
• Extreme Programming (XP) is the most widely
used approach to agile software development.
• Extreme Programming uses an object-oriented
approach as its preferred development
paradigm and encompasses a set of rules and
practices that occur within the context of four
framework activities: planning, design,
coding, and testing.
 Planning
• It begins with listening—a requirements
gathering activity that enables the technical
members of the XP team to understand the
business context for the software and to get a
broad feel for required output and major
features and functionality.
• Listening leads to the creation of a set of “
stories ” (also called user stories) that describe
required output, features, and functionality
for software to be built.
 Design
• XP design rigorously follows the KIS (keep it
simple) principle.
• XP encourages the use of CRC
(class-responsibility-collaborator) cards as an
effective mechanism for thinking about the
software in an object-oriented context.
 Cont..
• If a difficult design problem is encountered as
part of the design of a story, XP recommends
the immediate creation of an operational
prototype of that portion of the design, called
a spike solution, the design prototype is
implemented and evaluated.
 Coding
• After stories are developed and preliminary
design work is done, the team does not move
to code, but rather develops a series of unit
tests that will exercise each of the stories that
is to be included in the current release.
• Once the unit test has been created, the
developer is better able to focus on what
must be implemented to pass the test
 Testing
• The unit tests that are created should be
implemented using a framework that enables
them to be automated.
• This encourages a regression testing strategy
whenever code is modified.
• As the individual unit tests are organized into
a “universal testing suite”, integration and
validation testing of the system can occur on a
daily basis.
XP
 Advantages
• Enhanced Communication and Collaboration.
• High-Quality Software.
• Flexibility and Adaptability.
• Customer Satisfaction.
• Simplicity in design.
• Sustainable Development Pace.
• Collective code ownership.
 Disadvantages
• Intensive Customer Involvement Required.
• Not Suitable for Large Teams or Projects (best
for small co-located teams).
• Risk of Incomplete Documentation.
• Requires Skilled and Committed Team
Members.
• Short-Term Focus.
Unit 2
 Unit 2
• Requirements Elicitation Techniques,
Requirements analysis, Models for
Requirements analysis, requirements
specification, requirements validation.
 Requirement Engineering
• Software Requirement Engineering (SRE), also
known as Requirements Engineering, is a
systematic and disciplined approach to the
specification and management of software
requirements throughout the software
development process.
 Definition of a requirement according to IEEE standards, in the
context of software engineering

1. A condition or capability needed by a user to

solve a problem or achieve an objective.
2. A condition or capability that must be met or
possessed by a system or system component
to satisfy a contract, standard, specification,
or other formally imposed document.
3. A documented representation of a condition
or capability as in (1) and (2).
 The major tasks
• It involves understanding, documenting, and
managing the needs and constraints of
stakeholders to ensure that the software
solution meets their expectations.
• Requirements Engineering can be divided
into two main set of activities
1. Requirements Definition
2. Requirements Management
 Key aspects of Requirements Definition

• Elicitation
• Analysis
• Specification / Documentation
• Validation / Review
 Elicitation
• This is the process of gathering requirements
from stakeholders. It involves techniques such
as interviews, surveys, workshops, and
observations to identify and understand the
needs of users, customers, and other
stakeholders.
 Requirement Elicitation Activity
• Fact – finding: consists of study of the
organization in which the target system will
operate and defining the proposed system
approach.
• Requirement gathering: captures information
from the viewpoint of various users to identify
what is to be built.
 Cont..
• Evaluation: identifies the inconsistencies in
the gathered requirements and examines why
a requirement has been stated.
• Prioritization: determines the relative
importance of the requirements.
• Consolidation: brings together the
information collected from the previous steps
into a set of requirements consistent with the
goals identified during fact – finding.
 Requirements Elicitation Techniques
• There are many requirements elicitation
techniques, such as, CORE, IBIS, FODA.
• There is no single approach that provide the
best results in all the cases.
• So the analyst should aware of a set of
techniques and select the best sub-set of
techniques to tackle different scenarios in the
project.
 CORE(Controlled Requirements
Expression)
• To start with, CORE is the first technique used to
accomplish the task of requirements elicitation. It
is a requirements elicitation, analysis and
specification method developed in late 1970’s and
refined during early 1980’s.

• It is a viewpoint based technique. A specific

system is viewed from number of viewpoints and
the principle behind CORE is that a complete
picture of system requirements can only emerge
by putting together these various viewpoints.
• Viewpoint: A viewpoint represents the
perspective of a stakeholder or a set of
stakeholders on a system. Each viewpoint is
defined by a set of concerns or interests that are
relevant to those stakeholders. Viewpoints help in
structuring and organizing the system's
architecture and requirements to address the
diverse concerns of different stakeholders.
• Well-suited for projects with relatively stable and
straightforward requirements.
• Example: Consider a complex system, such as an air traffic control system.
Different stakeholders, such as air traffic controllers, system
administrators, and software developers, may have different concerns and
priorities regarding the system.
• Air Traffic Controller Viewpoint:
– Concerns: Real-time information, system responsiveness, user interface
simplicity.
• System Administrator Viewpoint:
– Concerns: System maintenance, reliability, scalability.
• Software Developer Viewpoint:
– Concerns: Code maintainability, system architecture, software interfaces.
• Each viewpoint would have its set of requirements, constraints, and
design considerations. By addressing these viewpoints, the overall system
architecture and design can better meet the needs of diverse
stakeholders.
 Drawbacks of CORE
• In CORE, the requirements specifications are
put together by the users, customers and the
analysts, not just the analysts alone.
• The role of the analyst is somewhat passive.
This is the major drawback of CORE as the
passive analyst is unlikely to get the
requirements properly.
 Drawbacks of CORE
• CORE delays the consideration of the
constraints at the later stage and does not
give enough importance to non –functional
requirements.
• It does not address documenting the rationale
behind each requirement, something that is
needed in case requirements need to be
prioritized or conflicts between requirements
need to be resolved.
 Issue Based Information System
• One of the main concerns in requirements is
understanding the rationale behind them.
• The rationale is necessary to make choices and
prioritize between the requirements.
• It is also important for another reason-when the
original analysts are no longer available, informed
decisions cannot be taken without knowing the
rationale.
• A methodology that focuses on understanding the
documentation of the rationale behind the
requirements is IBIS.
 Cont..
• Any problem to be solved has many stakeholders
involved, each with a different view and different
concerns.
• Dialog is required to resolve various issues.
• IBIS is a method that provides a framework for
resolving issues and gathering requirements while
tracking the pending issues and also documenting
the rationale behind the requirements.
• This approach is suitable for complex and
ill-defined problem.
 Cont..
• The framework used is:
Question(Issue)
A question is stated.
Idea (Position)
The response is the idea expressed.
Argument (Justification)
Argument for or against each idea are further
documented.
 Drawback
• IBIS does not address identifying consistency
problems.
• It also does not support resolving conflicts and
reaching consensus.
• In IBIS, the representation does not depict
how old an issue is and whether the issue is
now no longer relevant.
• Also in this framework iterative nature of
elicitation is not catered.
Feature Oriented Domain analysis
• A problem that often occurs in requirements
definition is the poor understanding of the
application domain and lack of common
terminology between the users and the
analyst.

• The requirements need to be looked from the

domain point of view and hence domain
analysis is required to be performed.
 Cont..
• The term "domain analysis" is used for the
process of identifying, collecting, organizing
and representing the relevant information in a
domain.
• Knowledge about a domain can be gathered
by studying various specific applications in
that domain and using these to abstract and
refine the underlying domain features.
 Cont..
• The FODA methodology consists of three steps.
• 1. Context analysis: This defines the extents
(bounds) of the domain for analysis.
• 2. Domain Modeling: This describes the problem
space in the domain to be addressed by the
software.
• 3. Architecture Modeling: This gives the software
architecture for implementing solutions.
 Cont..
• Context analysis defines the scope of the
domain, its relationships to other domains,
inputs, outputs of the domain and the
high-level stored data requirements. It is
expressed as a context model and may be
done using structure diagrams and context
diagrams.
 Cont..
• Domain modeling is concerned with
identifying the commonalties and differences
of various applications of the domain.
• Analysis is performed to obtain the features of
the domain and the standard vocabulary used
for the domain.
• The entities and the software requirements
are understood using typical specification
techniques like control flow and data flow.
 FODA wrt healthcare management
software domain
• Context Analysis:
In the healthcare management software domain, context
analysis involves understanding the broader context in
which the software will be used. This includes identifying
stakeholders such as healthcare providers, administrators,
patients, and regulatory bodies. It also involves
understanding the goals and constraints of the healthcare
domain, including patient privacy regulations,
interoperability standards, and the need for accurate and
timely clinical information.
 Example:
• Stakeholders in this domain include doctors,
nurses, hospital administrators, insurance
providers, and government health agencies.
Context analysis would entail understanding the
specific needs of each stakeholder group, such as
electronic health record (EHR) management for
healthcare providers, appointment scheduling and
billing for administrators, patient engagement
features for patients, and compliance with
regulations for data security and privacy.
 Domain Modeling
• Domain modeling in the healthcare management
software domain involves identifying the core
concepts, relationships, and behaviors relevant to
healthcare operations. This includes entities such as
patients, healthcare providers, medical records,
appointments, treatments, medications, and medical
conditions. Relationships between these entities, such
as patient-provider relationships, treatment plans,
medication prescriptions, and diagnostic tests, would
also be modeled. Additionally, behaviors such as
patient registration, medical history management,
treatment planning, and billing processes would be
defined as part of domain modeling.
 Example
• Domain modeling might include entities like "Patient,"
"Physician," "Nurse," "Appointment," "Medical
Record," "Prescription," "Diagnosis," and "Insurance
Coverage." Relationships between these entities
would include "Patient visits Physician," "Physician
creates Medical Record," "Nurse updates Medical
Record," "Physician prescribes Medication," and
"Patient has Insurance Coverage." Behaviors such as
"Scheduling appointments," "Updating medical
records," "Prescribing medications," and "Processing
insurance claims" would also be modeled.
 Architecture Modeling
• Architecture modeling in the healthcare
management software domain focuses on
designing a flexible and scalable software
architecture that can accommodate various
healthcare workflows and requirements. This
involves identifying reusable components such as
patient management, clinical decision support,
electronic health record (EHR) systems, billing and
insurance management, and interoperability
modules. These components would have
well-defined interfaces that allow them to interact
with each other seamlessly.
 Example
• Architecture modeling might involve designing
modular components such as "Patient
Management," "Clinical Decision Support,"
"Electronic Health Record (EHR) System,"
"Billing and Insurance Management," and
"Interoperability Module." These components
would have interfaces for functionalities like
patient registration, medical data entry,
treatment planning, billing, and information
exchange with external systems.
 Drawback
• Domain modelling is not possible for all the
cases for example: if domain is immature or
evolving rapidly.
 Prototyping
• As a tool for requirement elicitation.
• A prototype is a mock up of the proposed
system, which is released to the users during
the requirements definition or early design
stages.
• It is not a substitute of SRS, it helps in
clarifying the exact requirement.
 Prototyping
• Two approaches:
• 1. Evolutionary
• 2. Throw away approach
 Advantage
• Improved communication between the
developers and end users.
• Increased user involvement.
• Ability to clarify hidden or ambiguous
requirement.
• Quicker review of SRS.
 Disadvantage
• User may get disillusioned with prototype
since the prototype is not robust and does not
contain full functionality.
• It may give impression to user that system is
ready.
• The cost of prototyping is added.
• Developers may start considering prototype as
a substitute for SRS.
 Requirement Analysis
• Once requirements are gathered, they need to
be analyzed to ensure they are clear,
complete, and consistent. This involves
refining and organizing the requirements,
resolving conflicts, and identifying
dependencies.
 Requirement analysis models
• Data flow diagram
• Entity relationship diagram
• Object Class diagram
• State Transition Diagrams
• Use-Case Diagrams
• Requirement analysis starts in parallel with
requirement elicitation and involves refining
and modeling the requirements to identify
inconsistencies, errors or other defects.
• Requirement analysis is usually done with the
use of one or more system models that
present an abstract description of the system.
• These models also act as a bridge between the
users, customers and the developers, as the
model are easily understandable by all parties.

• There are many well known models available

and the analyst selects the most suitable
model for the situation at hand.
 Typical activities classified as
requirement analysis
• Depiction of the scope of the system in the
form of diagram.
• Developing prototypes, which users evaluate
and provide further requirements or refine
the requirements.
• Performing feasibility analysis.
• Modeling of the requirements in the form of
various graphical representations.
 Most widely used models
• Data flow diagram:
A data flow diagram (DFD) is a graphical
representation of the movement of data between
external entities, processes and data stores within a
system.

DFDs are part of structured analysis and design

methods, which predate UML. They are used to
model the functional aspects of a system's
processes and data flows.
• Structured analysis and design methods were prominent in the 1970s and
1980s as approaches to software development that emphasized
systematic analysis and decomposition of a system into smaller, more
manageable parts.
• These methods aimed to address the complexity of large-scale software
systems by breaking them down into structured components and defining
clear interfaces between them.
• Structured analysis focused on understanding and modeling the functional
requirements of a system, including its processes, data flows, and data
stores. This phase aimed to identify the system's inputs, outputs,
processes, and data stores, along with the flow of data between them.
• Structured design, on the other hand, focused on transforming the
requirements identified during structured analysis into a detailed design
that could be implemented using programming languages and software
development tools.
• A data flow diagram has four basic elements.
The elements include external entities, data
stores, processes, and data flows. The
elements are best represented by the two
main methods of notation used in DFDs
– Yourdon & Coad, and Gane & Sarson.
• DFD symbols vary slightly depending on
methodology. Even so, the basic ideas remain
the same.
 Process

– The work or actions performed on data so that they

are transformed, stored, or distributed.

– Process labels should be verb phrases!

145
 Data Flow

– A path for data to move from one part of the

system to another.
– Data in motion!
• Arrows depict the movement of data.
– NO VERBS

146
 Data Store

– Used in a DFD to represent data that the system

stores
– Data at rest!
– Labels should be noun phrases
• (NO VERBS)
147
External Entity aka Source/Sink

– The origin or destination of data!

• This represents things outside of the system.
– Source – Entity that supplies data to the system.
– Sink – Entity that receives data from the system.
– The labels should be noun phrases!
148
 General DFD Rules
YES NO
A process to another process

A process to an external entity

A process to a data store

An external entity to another external entity

An external entity to a data store

A data store to another data store

149
• DFD rules and tips
• Each process should have at least one
input and an output.
• Each data store should have at least one
data flow in and one data flow out.
• Data stored in a system must go through a
process.
• All processes in a DFD go to another
process or a data store.
 SRS
• SRS stands for Software Requirements Specification. It's a
comprehensive document that outlines the functional and
non-functional requirements of a software system.
• The SRS document describes in detail what the software will
do and how it will perform under various conditions.
• It typically includes sections such as introduction, scope,
functional requirements, non-functional requirements,
system features, user interfaces, and more.
• The SRS serves as a contract between the client and the
development team, ensuring a common understanding of
the software requirements and guiding the development
process.
 Functional requirements
• Functional requirements are specifications
that define what a system or software
application is supposed to do.
• They describe the functionality, features, and
operations that the system must support to
fulfill the needs of the users and stakeholders.
• These requirements focus on the behavior of
the system, detailing the tasks, processes, and
interactions it must perform.
 Non-functional requirements
• Nonfunctional requirements, or NFRs, are a
set of specifications that describe the
system’s operation capabilities and
constraints.
• These are basically the requirements that
outline how well it operates, including things
like speed, security, reliability, data integrity,
etc.
 Non-functional requirements
1. Performance. How fast does the system return results?
• Specifies the system's response time, throughput, resource usage, and scalability under certain
conditions.
• Example: The system must support 1000 concurrent users with an average response time of
less than 2 seconds.

2. Scalability. How much will performance change with higher workloads?

• Specifies the system's ability to handle increased loads, either in terms of data volume or
number of users.
• Example: The system must scale horizontally to support an additional 100,000 users without
performance degradation.
3. Portability. Which hardware, operating systems, and browsers, along with their versions, does
the software run on?
• Specifies the system's ability to operate in different environments, such as different operating
systems or hardware configurations.
• Example: The application should run on Windows, macOS, and Linux platforms without
requiring changes to the codebase.
 NFRs Cont..
4. Reliability. How often does the system experience critical failures?
• Specifies the system's ability to perform its functions consistently and
accurately over time.
• Example: The system should have an uptime of 99.9% and a mean time
between failures (MTBF) of at least 10,000 hours.
5. Maintainability. How much time does it take to fix the issue when it
arises?
• Specifies the system's ability to undergo modifications, updates, and
enhancements with minimal effort.
• Example: The system should be modular, allowing for individual
components to be updated without affecting the overall system.
6. Availability. How long is the average system downtime?
• Specifies the percentage of time the system should be operational and
accessible.
• Example: The system should be available 24/7, with a maximum downtime
of 1 hour per month.
 NFRs Cont..
7. Security. How well are the system and its data protected against attacks?
• Specifies the system's ability to protect data and resources against unauthorized
access, use, disclosure, disruption, modification, or destruction.
• Example: The system must enforce multi-factor authentication for all users accessing
sensitive data.
8. Usability. How easy is it to use the system?
• Specifies the ease with which users can learn, operate, prepare inputs, and interpret
outputs of the system.
• Example: The system should allow a new user to complete a basic task with less than
30 minutes of training.
9. Interoperability. Does the system conflict with other applications and processes?
• Specifies the system's ability to interact with other systems or components, either
within the organization or with third-party systems.
• Example: The system should seamlessly integrate with the organization's existing
CRM and ERP systems via standard APIs.
10. Efficiency : Specifies how efficiently the system uses resources, such as CPU,
memory, or network bandwidth.
• Example: The system should utilize no more than 70% of CPU resources during peak
operations.
 Functional vs. Non-Functional
Requirements
• Functional Requirements: Focus on what the
system should do (e.g., user login, report
generation, data entry).
• Non-Functional Requirements: Focus on how
the system performs its functions, including
performance, security, scalability, and
usability (e.g., system must load a page within
2 seconds).
 Quiz

Q: Which of the following is a non-functional requirement?

• a) The system must allow users to log in with a username
and password.
• b) The system must respond to user queries within 3
seconds.
• c) The system must allow user to edit their profile.
• d) The system must generate monthly reports for
administrators.
 The SRS is typically used by the
following entities
• Customers and users for understanding what they are
expected to get.
• Project managers to estimate and plan the project to
deliver the system.
• Designers and programmers to know what to build.
• Testers to prepare for test activities.
• Maintenance teams for understanding the system that
they will maintain.
• Trainers to prepare training material for training the
end users.
• Users to understand the proposed system.
 Characteristics of SRS
• The SRS should address the issues related to functionality,
external interfaces, non-functional requirements as well as
design constraints.
• A “good” SRS document has the following characteristics.
• Completeness
• Clarity
• Correctness
• Consistency
• Modifiability
• Traceability
• Feasibility
• Testability
 Completeness
• For completeness, we need to ensure the following:
• Elicitation of the requirements from all the
“stakeholders”
• Focusing on user tasks, problems, bottlenecks and
improvements required; rather than the system
functionality.
• Ranking or prioritizing each requirement.
• Marking areas where requirements are not known as
“TBD: To be determined”.
• Resolving all the TBDs before the design phase.
 Cont..
• To be considered “complete” the SRS
document should contain all functional and
non-functional requirements and features
that are expected in the system.
• This includes the identification of all
realizable classes of valid and invalid input
data and the specification of the expected
system responses to these input data.
 Clarity
• The documented requirements should lead to
only a single interpretation, independent of the
person or time when the interpretation is done.
• The SRS needs to be unambiguous to the authors,
the users, other reviewers as well as the
developers and testers who will use the
document.
• Focusing on clarity only for the developers and
testers may prove insufficient.
 Issues related to clarity
• Since natural language is imprecise and
ambiguous in nature, any SRS written in
natural language needs to reviewed by an
independent entity (independent of the
analyst, developers and users) to identify
ambiguous use of the natural language.
• Use of languages such as XML or JSON.
• Use of requirement modeling techniques.
 Following are some guidelines to
improve the readability of SRS
• Consistently number chapters, sections and sub-sections and
individual requirements.
• Align text to the left margin rather than "justified both margins".
• Use white space to reduce eye strain.
• Use highlighting features (italics, bold, underline, fonts and font
sizes).
• Do not use colors as far as possible. If you use colors, print out the
document in black and white and check that effect is not lost (and
of course that the colored portions are still readable).
• Create a table of contents-use the word-processor's capabilities
and do not hardcode.
• If your word-processor allows it, use hyperlinks within the
document for easy navigation.
 Correctness
• The SRS can be considered as correct if every
requirement stated in the SRS is required in the
proposed system.
• There are no real tools or procedures that ensure
correctness.
• If there are any preceding documents, then the
"requirements" from those earlier documents need to
be traced to the SRS.
• In addition, all stakeholders, especially users, need to
review the SRS and confirm that the requirements
stated in the SRS correctly reflect their needs.
 Consistency
• Requirements at all level must be consistent with each other. Any
conflict between requirements must be resolved. The types of
conflicts that are likely to be found in an SRS are:
• Characteristics (format, details) of a real-world entity interacting
with the system may be conflicting. For example, in a time sheet
system one requirement may assume that an individual cannot
work for more than 16 hours on any day, whereas another
requirement may assume that a person can work for 24 hours on
any day.
• There may be a logical or temporal conflict between two specified
items. One requirement may specify that the time sheets not
submitted by the end of next week (Sunday) are treated as
"missing", whereas another requirement may specify that time
sheets not submitted by the end of the last working day of the
next week (Friday or before are treated as "missing".
 Cont..
• The terminology used for some
entities/events may be different. For
ex-ample, "Start of the Week" may be
interchangeably used with "Monday".
• This could create confusion when we are
dealing with a situation where Monday is a
holiday. The standard terminology should be
defined and used consistently.
 Modifiability
• The SRS needs to be documented in such a manner that a history
of changes can be contained in the document.
• It will also be necessary to be able to highlight and trace the
changes to the requirements as we progress through the project.

• Certain good practices that can lead to high modifiability are:

1. Minimal redundancy. Though redundancy itself is not an error, it

can lead to inconsistencies when changes are incorporated.

2. Labeling. If requirements are labeled (or numbered), it is easy to

pinpoint the requirements that have changed. This includes labels
and references to figures, tables, diagrams and appendices in the
SRS.
 Traceability
• Labeling (or numbering) of requirements
provides a mechanism to trace each
requirement through the design, into the test
plans, test cases and source code.
• Fine grained, structured and precise
statements are much more preferable to
large, narrative paragraphs.
 Feasibility
• Though it may not be possible to confirm the
feasibility of implementation of all the
requirements, any requirement which is
apparently infeasible, should be eliminated
from the SRS, after giving the reasoning.
 Testability
• The SRS needs to be stated in such a way that
it is possible for the tester to create test plans
and confirm whether the requirements are
met or not.
• Non-testable statements example:
User-friendly, high bandwidth, fairly large
memory etc.
Contents of SRS
 Common problems with SRS
• Making bad assumptions:
It typically occur either because authors of the SRS
do not have access to sufficient information or the
information does not exist. You can eliminate the
first problem by eliciting, analyzing and
documenting the information critical to the
proposed system.
This information then must be made available to all
authors of the SRS, by creating and maintaining a list
of other relevant documents and making these
easily accessible to each author.
 Cont..
• Writing implementation (HOW) instead of
requirements (WHAT)
• SRS should state WHAT is needed, not HOW it
is to be provided.
• This is a common mistake made by
requirement writers, as they wear their
developer hat while documenting
requirements.
 Cont..
• Using incorrect terms: The terms must be used in
a very specific manner.
• Requirements use shall
• Statements of facts use will
• Goals use should

• The terms such as “are”, “is”, “was” and “must” so

not belong in a requirement. They may be used in
a descriptive section.
1. Requirements (use shall):
1. Requirements specify what the system must do or the constraints it must
satisfy. These are typically stated using the word "shall" to denote a
mandatory requirement.
2. Example: "The system shall authenticate users using a username and
password."
2. Statements of Facts (use will):
1. Statements of facts describe characteristics or properties of the system or
its environment that are expected to hold true. These are typically stated
using the word "will" to denote a statement about what will happen or be
the case.
2. Example: "The system will be deployed on a cloud-based infrastructure."
3. Goals (use should):
1. Goals represent desired outcomes or objectives that the system should
achieve. These are typically stated using the word "should" to denote a
recommended course of action or a desirable property.
2. Example: "The system should provide real-time updates to users."
 Requirements Review
• Requirement review is the activity after
elicitation, analysis and documentation.
• For maximum effectiveness, review and
verification should not be treated as a discrete
activity to be done only at the end of the
preparation of SRS.
• Review should be treated as a continuous activity
that is threaded into the elicitation, analysis,
modeling and documentation, with a formal
phase-end review scheduled after the SRS
document is ready.
 Phase End Review
• Once the SRS is built and ready according to the authors
(analysts), the document needs to undergo a formal review.

• As the SRS is the foundation for estimation, design and

subsequent software engineering activities, extreme care
should be taken in conducting the review.

• Improper review can result in an incorrect or incomplete

system or subject the development team to a constant set
of changes to requirements. As we know, errors in
requirements are 100 to 500 times more expensive to fix in
the operations phase as compared to finding and fixing in
the requirements phase.
 Cont..
• Requirements review currently is a manual process,
which involves reviewers reading the SRS and
verifying that the SRS is complete, clear, correct,
consistent, modifiable, traceable, feasible and
testable.
• Reviews may be conducted using any one of the
various review methods. In one of the review
methods, called the Walkthrough method, the
authors "walk" the reviewers through the proposed
system, explaining each requirement. The review
team members raise issues, which are recorded.
 Some problems encountered in the
review of SRS
• Review of large SRS document is a daunting
activity.
• Too many potential reviewers.
• Geographical separation.
 Requirement Sign-off
• A sign-off by the representatives of the
customer, users and development team marks
the end of the requirements definition
activities and the start of the requirements
management activities.
• It is important that all signatories understand
what the sign-off means and avoid the typical
pitfalls associated with sign-off.
 Requirements Management
• Changes to software requirements are inevitable.
• Changes to the SRS should be controlled through
a well-defined Change Management Process.
• In addition to handling changes, we need to
ensure that the downstream products that we are
building are traceable to the SRS and that the SRS
is traceable to these downstream products.
Change Management Process
Maintaining Requirements Traceability
• Traceability between SRS and System Test
Plan