School of Computer Science and

Engineering
Agile Software Development and DevOps
(B22EF0603)
Dr. Anilkumar Ambore
Contents: Unit - 1
1: Requirements and Development process
1.1: Software Processes: Models

1.2: Process iteration

1.3: Process activities

2: Software Requirements
2.1: User requirements and System requirements

2.2: Functional and Non-functional requirements

2.3: Interface specification

2.4: The software requirements document

3: Requirements Engineering Processes

3.1: Feasibility studies
2
3.2: Requirements elicitation and analysis
Requirements and Development process
1: Requirements and Development process
A software process is a set of activities that leads to the production of a software product.
These activities may involve the development of software from scratch in a standard programming
language like Java or C and many. More.
Although there are many software processes, some fundamental activities are:

• Software specification: It serves as a blueprint for the software's development. It helps the development team

understand what the software should do and how it should perform.

• Software design and implementation: It is the stage in the software. engineering process at which an
executable software system is. developed.

• Software validation: The software must be validated to ensure that it does what the customer wants.

• Software evolution: The software must evolve to meet changing customer needs.
 1.1. Software process: models
Software process models are structured frameworks that describe the sequence of activities, tasks, and
procedures involved in software development. These models provide a systematic approach to ensure
software is developed effectively and efficiently while meeting quality and stakeholder requirements.

The Common Software process models are:

1.1.1: The waterfall model:

1.1.2: Evolutionary development

1.1.3: Component-based software engineering

These three generic process models are widely used in current software engineering practice. They are not mutually

exclusive and are often used together, especially for large systems development.
1.1.1: Water fall model
• The Waterfall Model is a linear and sequential software development methodology.

• It is one of the earliest and most traditional models used in software engineering.

• In this model, the development process flows downwards like a waterfall through
distinct phases, where each phase must be completed before moving on to the next.

• The Waterfall Model is simple to understand and implement but is not as flexible as
modern iterative approaches.
This is illustrated in Figure 4.1. Because of the cascade from one phase to another, this model is
known as the waterfall model or software life cycle.
• Requirements analysis and definition:

• We Gather and document all project requirements w.r.t the user requirements and we
produce document called Software Requirement Specification (SRS) document

• System and software design : Define the architecture and design of the software based on the SRS. Create
system and software design documents, including database schema, data flow diagrams, etc

• Implementation and unit testing: Developers write code according to the system design documents. Unit
testing involves verifying that each unit meets its specification.

• Integration and system testing: Combine all modules and test the entire system for errors, bugs, and
performance. After testing, the software system is delivered to the customer

• Operation and maintenance: Address issues, update software, and improve performance as needed. The
system is installed and put into practical use. Maintenance involves correcting errors which were not
discovered in earlier stages of the life cycle.
The advantage and disadvantage of Water fall model.
Advantages:

• Simplicity: The Waterfall model is easy to understand and implement due to its linear and
structured approach.

• Clear Documentation: Each phase produces detailed documentation, which helps in

understanding requirements and design clearly.

• Easy to Manage: Its rigidity and structured approach make it easier for project managers to
plan, schedule, and monitor.

• Ideal for Smaller Projects : Suitable for small-scale projects with clear objectives and limited
complexity
Disadvantages of waterfall model:

• Inflexibility to Changes: Once a phase is completed, going back to make changes is difficult,
costly, and time-consuming.

• Late Testing: Testing is performed after development is completed, making it harder to identify
and resolve issues early in the process.

• Unsuitable for Evolving Requirements: The model struggles in environments where

requirements are dynamic or unclear.

• Lack of Customer Feedback: Customers do not see a working product until late in the process,
increasing the risk of misaligned expectations.

• Not Suitable for Complex Projects: For large or complex projects, the linear approach may not
be efficient or scalable
1.1.2: Evolutionary development
• It is a software development approach where the software is built incrementally and iteratively.
• Instead of delivering the entire system at once, smaller, functional parts of the system are developed,
delivered, and refined over time.
• This approach is designed to accommodate changing requirements and ensure that the system evolves in
response to user feedback.

There are two fundamental types of evolutionary development

 Exploratory development
 Throwaway prototyping
Exploratory development:
• Focuses on building the system in collaboration with the customer to refine unclear or
incomplete requirements.
• The objective of the process is to work with the customer to explore their requirements and
deliver a final system.

Throwaway prototyping:
• Creates prototypes to understand requirements better.

• It is to understand the customer’s requirements and hence develop a better requirements

definition for the system. The prototype concentrates on experimenting with the customer
requirements that are poorly understood
Key Features of Evolutionary Development
• Iterative and Incremental Process

• The system is developed in small, manageable chunks or versions (increments), with each
iteration improving or extending the functionality of the system.

• User Feedback-Driven: Continuous interaction with users ensures that their requirements and
feedback are incorporated into the development process.

• Adaptability: The process accommodates changes in requirements, making it suitable for

projects where the scope is uncertain or dynamic.

• Parallel Development: Some components can be developed concurrently, speeding up the

process.
Examples of Evolutionary Development Models:

1.Spiral Model: Combines iterative development with risk analysis at each cycle.

2.Incremental Development: Develops the system in increments, where each adds

functionality to the system.

3.Agile Methodologies: Modern approaches like Scrum and Kanban embody evolutionary

principles by focusing on iterative delivery and adaptability.

The advantage and disadvantages of ED
Advantages of Evolutionary Development:
• Flexibility to Changes:
• Allows developers to accommodate evolving requirements easily.
• Early Delivery of Working Software:
• Users can start using parts of the system early, providing immediate value.
• Improved User Involvement:
• Continuous user feedback ensures the system aligns closely with user needs.
• Learning Opportunity:
• Both developers and stakeholders gain a better understanding of the project requirements
as development progresses.
Disadvantages of Evolutionary Development:
 Management Complexity:
• Managing frequent changes, iterations, and feedback can be challenging.
 Unclear Project Timeline:
• The iterative nature makes it harder to estimate timelines and costs accurately.
 Potential for Scope Creep:
• Continual user involvement and changing requirements may lead to uncontrolled expansion
of the project scope.
 Incomplete Documentation:
• Focus on rapid development may lead to inadequate documentation.
 Quality Risks:
• Frequent changes may impact the system’s architecture or result in technical debt.
1.1.3: Component-based software engineering

• It is a software development methodology that emphasizes building software systems by

assembling reusable, independent, and modular software components.

• The idea is to treat software development like assembling pre-built parts (components),

much like in manufacturing.

• This approach promotes reusability, scalability, and efficiency in the development process,

making it a popular choice for complex and large-scale projects.

Phases of CBSE:
• Component analysis: Analyze the system's requirements to identify reusable components or the
need for new components.
• Requirements modification: If necessary, customize the selected components to better fit the
specific needs of the project.
• System design with reuse: During this phase, the framework of the system is designed or an
existing framework is reused.
• Development and integration: Deploy the assembled system and maintain it over time,
updating or replacing components as needed.
The advantage of CBSE
• Faster Development:
Reusing existing components reduces development time significantly.
• Cost Efficiency:
Reduces costs by leveraging pre-built components instead of building everything from
scratch.
• Improved Quality:
Reusable components are often well-tested, reducing the likelihood of defects in the system.
• Scalability and Maintainability:
Modular design makes the system easier to scale and maintain. Individual components can
be updated or replaced without affecting the entire system.
• Focus on Core Functionality:
Developers can focus on the unique aspects of the system while relying on existing
components for standard functionalities.
• Flexibility:
Components can be swapped or upgraded to meet changing requirements or technologies.
The disadvantages of CBSE
• Integration Challenges:
Integrating components from different sources can be complex and may require significant
effort.
• Component Dependency:
Over-reliance on third-party components can create dependency issues, especially if the
component is discontinued or poorly maintained.
• Customization Limitations:
Pre-built components may not fully meet specific requirements, and customization may be
limited or costly.
• Compatibility Issues:
Components may have compatibility issues due to differing technologies, standards, or
interfaces.
• Security Risks:
Using third-party components introduces potential security vulnerabilities if the components
are not properly vetted.
1.2: Process Iteration
• Process iteration refers to the practice of repeating certain phases or activities in the
software development lifecycle to refine and improve the software.

• Instead of following a linear and sequential process (as in the Waterfall model), iteration
allows revisiting earlier stages based on feedback, evolving requirements, or identified issues.

• It is a key aspect of iterative and incremental development approaches.

The two process models that have been explicitly designed to support process iteration:
 Incremental delivery
 Spiral development
Incremental delivery
• Incremental delivery: The software specification, design and implementation are broken down
into a series of increments that are each developed in turn.

• In this a development approach where the system is built and delivered in small, manageable
increments rather than delivering the entire system all at once.

• Each increment represents a functional subset of the final product.

• Each increment represents a partial system with added functionality, allowing for the project's
gradual development.

• The key feature of this model is its iterative process, where increments are developed, tested,
and integrated one after another into the evolving system.

• By breaking the project into increments, teams can prioritize features and address changes
efficiently.
• Once the system increments have been identified, the requirements for the services to be
delivered in the first increment are defined in detail, and that increment is developed.

• During development, further requirements analysis for later increments can take place.

• Once an increment is completed and delivered, customers can put it into service.
Advantages of incremental development
• Customers do not have to wait until the entire system is delivered before they can
gain value from it.
• Customers can use the early increments as prototypes and gain experience.
• There is a lower risk of overall project failure.
• As the highest priority services are delivered first, and later increments are
integrated with them,

Dis-advantages of incremental development

• Increments must be carefully planned.
• Frequent deliveries and testing may overhead the deliveries.
• Incorrect prioritization can lead to inefficient or incomplete functionality.
Spiral development
• Spiral development is a risk-driven software development process model introduced by
Barry Boehm in 1986.

• It combines elements of iterative development and the waterfall model, focusing on early
identification and mitigation of project risks.

• This model is particularly suitable for large, complex, or high-risk projects.

• Rather than represent the software process as a sequence of activities with some
backtracking from one activity to another, the process is represented as a spiral.
• Each loop in the spiral represents a phase of the software process.

• The innermost loop might be concerned with system feasibility. The next loop with requirements
definition, the next loop with system design and so on.

• Each loop in the spiral is split into four sectors

 Objective setting

Risk assessment and reduction

 Development and validation

Planning
• Objective setting:
o Identify objectives for the current iteration.
o Define system requirements and constraints and explore alternative requirements.
• Risk assessment and reduction:
o Identify potential risks (technical, financial, operational, etc.).
o Evaluate and prioritize risks.
o Develop strategies to address or mitigate these risks (e.g., prototyping).
• Development and validation:
o Implement a deliverable, such as a prototype, a subsystem, or an increment of the system.
o Build and refine based on the selected strategies.
• Planning:
o The project is reviewed and a decision made whether to continue with a further loop of
the spiral.
o Decide whether to proceed to the next spiral, revisit the current phase, or terminate the
project.
1.3: Process activities

• Process activities refer to the fundamental tasks or stages involved in the development and
maintenance of software systems. The four basic process activities are:

1. Specification

2. Development

3. Validation

4. Evolution
Software specification (Requirements Engineering process)
• Purpose: Define the functionality and constraints of the software system.
There are four main phases in the requirements engineering process:
• Feasibility study:

An estimate is made of whether the identified user needs may be satisfied using current

software and hardware technologies.

The study considers whether the proposed system will be cost-effective from a business

point of view.

whether it can be developed within existing budgetary constraints.

• Requirements elicitation and analysis: This is the process of deriving the system requirements through
observation of existing systems, discussions with potential users and procurers, task analysis and so on.
 The requirements engineering process

• Requirements specification: The activity of translating the information gathered during the
analysis activity into a document that defines a set of requirements

• Requirements validation: Ensure the software meets requirements and is free from defects. It
involves unit testing, integration testing and so on.
Software design and implementation

• The implementation stage of software development is the process of converting a system

specification into an executable system.

• It always involves processes of software design and programming

• The design process may involve developing several models of the system at different levels of
abstraction.

• As a design is decomposed, errors and omissions in earlier stages are discovered. The below
Figure shows the block diagram.
The specific design process activities are:
1. Architectural design: Defining the high-level structure of the system, including modules,
components, their relationships, and communication protocols.

2. Abstract specification: For each sub-system, an abstract specification of its services and the
constraints under which it must operate is produced. E.g send(), recv(), etc.

3. Interface design: For each sub-system, its interface with other sub-systems is designed and
documented.
4. Component design: Services are allocated to components and the interfaces of these
components are designed.

5. Data structure: The data structures used in the system implementation are designed in detail
and specified.

6. Algorithm design: The algorithms used to provide services are designed in detail and specified.
Software Validation
• Software validation is the process of evaluating a software system to ensure it meets the
requirements and expectations of the end user.

• Validation ensures that the software behaves as intended in real-world conditions.

• satisfies all functional and non-functional requirements.

For small programs, system should not be tested as single module. The below figure shows the
three stage testing process.
• Component testing:
It also known as module testing or unit testing, is the process of testing individual software
components or modules to ensure they function as intended.
It focuses on verifying the behavior of a single, isolated component, such as a function, class, or
module, without considering its interactions with other components.
• System testing:
System testing is a critical phase in the software development lifecycle where the entire
integrated software system is tested as a whole to ensure it meets the specified requirements.
It evaluates the system's behavior, performance, and compliance with business and technical
specifications in an environment that closely resembles the production setup.
• Acceptance testing (alpha testing):
Acceptance testing is the final phase of the testing process in the software development
lifecycle (SDLC). Its primary purpose is to validate whether the software meets business
requirements and is ready for deployment.
Software evolution
• Software evolution refers to the process of modifying and adapting software systems after their
initial deployment.
• It helps to meet changing user needs, fix defects, improve performance, and adapt to new
environments or technologies.
• It ensures that software remains useful, relevant, and aligned with organizational goals
throughout its lifecycle.
2. Software Requirements
• Software requirements are the cornerstone of any software project.

• It refers to the conditions or capabilities that a software system must have to meet the needs of
stakeholders, including users, customers, and developers.

• The different types of requirements are:

• User requirements

• System requirements

•Functional Requirements (what the system should do)

•Non-Functional Requirements (how the system should perform)

2.1 User and System requirements
User Requirements:

• Requirements from the perspective of the end users, often in simple, understandable
language.

• Focus on what users expect the system to do.

• These requirements are often written in simple language to ensure that they are
understandable by non-technical stakeholders

• User requirements generally focus on the functionalities that the system

Examples of User Requirements:
1.Login/Authentication:
1. "The user must be able to log into the application using a username and password."
2. "The system should allow users to reset their passwords via a 'Forgot Password' link."
• The various problems can arise when requirements are written in natural
language sentences
1. Lack of clarity:
• It is sometimes difficult to use language in a precise and unambiguous way without
making the document wordy and difficult to read.

2. Requirements confusion:
• Functional requirements, non-functional requirements, system goals and design
information may not be clearly distinguished.

3. Requirements amalgamation:
• Several different requirements may be expressed together as a single requirement.

This requirement includes both conceptual and

detailed information
System requirements:
• System requirements describe how the software system should behave at a technical level.
• These are intended to guide developers.
• It explains how the software should be implemented to meet the user needs and expectations.

• System requirements are technical specifications that describe how the software should be
built, including its functionality, performance, security, and other technical aspects to meet user
needs and business objectives.

Examples of System Requirements:

1.Functional System Requirements:
1. "The system shall store user information, including name, email, and password, securely
in a relational database."
The requirements specifications written in natural language are prone to misunderstandings.
Therefore, the below notations are followed:
Structured language specifications

• Structured language specifications are a formal approach to documenting software requirements

that combines natural language's clarity with some elements of formality and structure.

• This method is often used to reduce ambiguity and improve the consistency of requirements.

• The advantage of this approach is that it maintains most of the expressiveness and
understandability of natural language.

• It ensures that some degree of uniformity.

The main components of Structural language specification are:
 Unique Identifier:
 Description : Description of the function or entity being specified
 Inputs : Description of its inputs and where these come from
 Source : Input data source
 Outputs : Description of its outputs and where these go to
 Destination
 Action : Description of the action to be taken
 Requires : Any Samples/data etc
Pre-condition : what must be true before the function is called
Post-condition : what is true after the function is called
 Side effects : Description of the side effects (if any) of the operation
Eg. Insulin pump control

• It is difficult to write
requirements in an
unambiguous way, particularly
when complex computations are
required.

• To address this problem, you can

add extra information to natural
language requirements
using tables or graphical
models of the system.
The below figure is a revised description
of the computation of the insulin dose

Mathematical specification language

The Graphical models are most useful when you need to show how state
changes

Graphical notations
2.2: Functional and Non-functional requirements
Functional requirements:

• Functional requirements define the specific actions or functionalities a software system must
perform to meet the needs of its users.

• These requirements describe what the system should do, focusing on behaviors, tasks, and
operations the software.
Non-functional requirements

• Non-functional requirements describe how the system should perform, ensuring reliability, usability, and

scalability
• Some of the metrics of non functional requirements are:

Performance : Define system speed, responsiveness, and throughput

Security : Protecting the system and data from unauthorized access.

Portability : Deploying the system across multiple environments

Availability : Ensuring the system is available for use when needed

Recoverability : System recovery in case of failure.

Size : K Bytes, RAM size

Robustness : Time to restart after failure

The types of non-functional requirements are:

1. Product requirements :
These requirements specify product behaviour. Examples include performance requirements
on how fast the system must execute.

2. Organisational requirements:
These requirements are derived from policies and procedures in the customer’s and
developer’s organisation. E.g: implementation requirements such as the programming language.

3. External requirements: This broad heading covers all requirements that are derived from factors
external to the system and its development process.
2.3 Interface Specification

• An interface specification defines the contract between different components or systems.

• It describes the inputs, outputs, and behaviors of software modules.

• It enables developers to interact with them without needing to understand their internal
workings

• There are three types of interface

1. Procedural interfaces

2. Data structures

3. Representations of data
e.g.
• Procedural interfaces :

It define how different components, modules, or systems interact by specifying the procedures
(or functions/methods) that one component offers to another . These interfaces are sometimes
called Application Programming Interfaces

• Data structures: These are passed from one sub-system to another.

• Representations of data: It describes data by using a diagram of the structure with

annotations explaining the function of each group of bits.
2.4 The software requirements document
• The software requirements document (sometimes called the software requirements
specification or SRS) is the official statement of what the system developers should implement.

• It is a formal document that specifies the functional, non-functional, and system requirements
of a software system.

• It acts as a bridge between stakeholders (e.g., clients, users) and the development team,
ensuring that everyone involved has a clear understanding.

• number of large organisations, such as the US Department of Defense and the IEEE, have
defined standards for requirements documents.
e.g. IEEE standard format for SRD.
3. Requirements Engineering Processes
3.1 Feasibility study

• A Feasibility Study in software engineering is an analysis conducted during the early stages of a
project to assess its viability.

A feasibility study is a short, focused study that aims to answer a number of questions:

1. Does the system contribute to the overall objectives of the organisation?

2. Can the system be implemented using current technology and within given cost and schedule
constraints?

3. Can the system be integrated with other systems which are already in place?

It determine whether the project is worth pursuing

It involves information assessment, information collection and report writing.

• Information assessment phase:

It identifies the information that is required to answer the three questions set out
above.

• Information collection: Discuss the source of information to answer the above

questions by consulting with managers, software engineers, or any related
departments.

• Report writing: Once all the information's is gathered, document those in a report.
3.2: Requirements elicitation and analysis
• Requirements Elicitation and Analysis is a critical phase in software engineering where the
project team gathers, examines, and defines the needs and expectations of stakeholders for a
software system.

• It ensures that the requirements are well-understood, documented, and feasible for
implementation.
It is an iterative process with continual
feedback.

The process of requirement elicitation and

analysis process consists of four activities:

• Requirements discovery:

• Requirements classification and organization:

• Requirements prioritization and negotiation:

• Requirements documentation
1. Requirements discovery:
• This is the process of interacting with stakeholders in the system to collect their
requirements.
• Domain requirements from stakeholders and documentation are also discovered during
this activity.

2. Requirements classification and organization:

• This activity takes the un-structured collection of requirements, groups related
requirements and organizes them into coherent clusters.

3. Requirements prioritization and negotiation:

• Multiple stakeholders are involved and their requirements sometimes will conflict.
• It is concerned with prioritizing requirements, and finding and resolving requirements
conflicts through negotiation.

4. Requirements documentation: The requirements are documented and input into the next round
of the spiral.
Thank You