Software Engineering

• Software Engineering is the process of

designing, developing, testing, and
maintaining software. It is a systematic and
disciplined approach to software development
that aims to create high-quality, reliable, and
maintainable software.
 Software Engineering
• Software engineering includes a variety of techniques,
tools, and methodologies, including requirements
analysis, design, testing, and maintenance.
• It is a rapidly evolving field, and new tools and
technologies are constantly being developed to
improve the software development process.
• By following the principles of software engineering and
using the appropriate tools and methodologies,
software developers can create high-quality, reliable,
and maintainable software that meets the needs of its
users.
 Software Engineering
• Software Engineering is mainly used for large
projects based on software systems rather than
single programs or applications.
• The main goal of Software Engineering is to
develop software applications for improving
quality, budget, and time efficiency.
• Software Engineering ensures that the software
that has to be built should be consistent, correct,
also on budget, on time, and within the required
requirements.
 Software engineering process
A software engineering process is crucial
because it provides a structured framework for
developing software, ensuring high quality,
efficient production, manageable costs, and
reliable delivery by following defined steps like
requirement gathering, design, implementation,
testing, and maintenance, ultimately leading to
better customer satisfaction and adaptability to
changing needs.
 Importance
• Handling Big Projects: A corporation must use a
software engineering methodology in order to handle
large projects without any issues.
• To manage the cost: Software engineering
programmers plan everything and reduce all those
things that are not required.
• To decrease time: It will save a lot of time if you are
developing software using a software engineering
technique.
• Reliable software: It is the company’s responsibility to
deliver software products on schedule and to address
any defects that may exist.
 Importance
• Effectiveness: Effectiveness results from things
being created in accordance with the standards.
• Reduces complexity: Large challenges are broken
down into smaller ones and solved one at a time
in software engineering. Individual solutions are
found for each of these issues.
• Productivity: Because it contains testing systems
at every level, proper care is done to maintain
software productivity.
 Core principles
• Modularity: Breaking the software into smaller, reusable
components that can be developed and tested independently.
• Abstraction: Hiding the implementation details of a component and
exposing only the necessary functionality to other parts of the
software.
• Encapsulation: Wrapping up the data and functions of an object
into a single unit, and protecting the internal state of an object from
external modifications.
• Reusability: Creating components that can be used in multiple
projects, which can save time and resources.
• Maintenance: Regularly updating and improving the software to fix
bugs, add new features, and address security vulnerabilities.
 Core principles
• Testing: Verifying that the software meets its
requirements and is free of bugs.
• Design Patterns: Solving recurring problems in
software design by providing templates for solving
them.
• Agile methodologies: Using iterative and incremental
development processes that focus on customer
satisfaction, rapid delivery, and flexibility.
• Continuous Integration & Deployment: Continuously
integrating the code changes and deploying them into
the production environment.
 Software engineering Processes
• In software engineering, "Communication
Practices, Planning Practices, Modelling
Practices, Construction Practices, and
Software Deployment" represent the five core
stages of a typical software development
lifecycle (SDLC), outlining the key activities
involved from initial stakeholder interaction to
delivering a fully functional software product
 Software engineering Processes
• Breakdown of each practice:
• Communication Practices:
• This phase focuses on establishing clear
communication channels with stakeholders to
understand project requirements, gather feedback, and
manage expectations throughout the development
process.
• Planning Practices:
• Involves defining project scope, timelines, resource
allocation, risk management, and creating a detailed
development plan to guide the project effectively.
 Software engineering Processes
• Modelling Practices:
• This stage involves creating visual representations of the software
system, such as use case diagrams, class diagrams, and data flow
diagrams, to design the architecture and functionality before coding
begins.
• Construction Practices:
• Refers to the actual coding and implementation phase where
developers write code based on the established design, conduct
unit testing, and integrate components to build the software.
• Software Deployment:
• The final phase where the developed software is deployed to the
production environment, including installation, configuration, and
user acceptance testing before making it available to end users.
Requirements Engineering Process in
Software Engineering
Requirements Engineering is the process of
identifying, eliciting, analyzing, specifying,
validating, and managing the needs and
expectations of stakeholders for a software system.
To guarantee the effective creation of a software
product, the requirements engineering process
entails several tasks that help in understanding,
recording, and managing the demands of
stakeholders.
 Requirements Engineering Process
steps
• Feasibility Study
• Requirements elicitation
• Requirements specification
• Requirements for verification and validation
• Requirements management
Requirements Engineering Process
steps
 Requirements Engineering
• Feasibility Study
• The feasibility study mainly concentrates on
below five mentioned areas below.
• Technical Feasibility: In Technical Feasibility
current resources both hardware software along
required technology are analyzed/assessed to
develop the project. This technical feasibility
study reports whether there are correct required
resources and technologies that will be used for
project development.
 Requirements Engineering
• Operational Feasibility: how easy the product will be
to operate and maintain after deployment.
• Economic Feasibility: In the Economic Feasibility
study cost and benefit of the project are analyzed.
• Legal Feasibility: In legal feasibility, the project is
ensured to comply with all relevant laws, regulations,
and standards.
• Schedule Feasibility: In schedule feasibility, the
project timeline is evaluated to determine if it is
realistic and achievable.
 Requirements Engineering
• 2. Requirements Elicitation
• It is related to the various ways used to gain
knowledge about the project domain and
requirements. The various sources of domain
knowledge include customers, business manuals, the
existing software of the same type, standards, and
other stakeholders of the project.
 Requirements Engineering
• Interviews: These are one-on-one conversations with stakeholders
to gather information about their needs and expectations.
• Surveys: These are questionnaires that are distributed to
stakeholders to gather information about their needs and
expectations.
• Focus Groups: These are small groups of stakeholders who are
brought together to discuss their needs and expectations for the
software system.
• Observation: This technique involves observing the stakeholders in
their work environment to gather information about their needs
and expectations.
• Prototyping: This technique involves creating a working model of
the software system, which can be used to gather feedback from
stakeholders and to validate requirements.
 Requirements Engineering
• 3. Requirements Specification
• This activity is used to produce formal software requirement
models. All the requirements including the functional as well
as the non-functional requirements and the constraints are
specified by these models.
 Requirements Engineering
• Functional Requirements: These describe what the software
system should do. They specify the functionality that the system
must provide, such as input validation, data storage, and user
interface.
• Non-Functional Requirements: These describe how well the
software system should do it. They specify the quality attributes of
the system, such as performance, reliability, usability, and security.
• Constraints: These describe any limitations or restrictions that must
be considered when developing the software system.
• Acceptance Criteria: These describe the conditions that must be
met for the software system to be considered complete and ready
for release.
 Requirements Engineering
• Requirements Verification and Validation
• Verification: It refers to the set of tasks that ensures that the
software correctly implements a specific function.
• Validation: It refers to a different set of tasks that ensures
that the software that has been built is traceable to customer
requirements. If requirements are not validated, errors in the
requirement definitions would propagate to the successive
stages resulting in a lot of modification and rework. The main
steps for this process include:
 Requirements Engineering
• Requirements Management
• Requirement management is the process of analyzing,
documenting, tracking, prioritizing, and agreeing on the
requirement and controlling the communication with relevant
stakeholders.
 Functional vs. Non Functional
Requirements
• Functional vs. Non Functional Requirements
Requirements are generally split into two types: Functional and
Non-functional requirements. functional requirements define
the specific behavior or functions of a system. In contrast, non-
functional requirements specify how the system performs its
tasks, focusing on attributes like performance, security,
Functional vs. Non Functional
Requirements
Tools and software used in requirements
Engineering.
• Tools Involved in Requirement Engineering
• Observation report
• Questionnaire ( survey, poll )
• Use cases
• User stories
• Requirement workshop
• Mind mapping
• Roleplaying
• Prototyping
Tools and software used in requirements
Engineering.
• Interviews:
– Conducting one-on-one or group interviews with stakeholders, including end-
users, clients, and subject matter experts. This allows for direct interaction to
gather detailed information about their needs, expectations, and concerns.
• Surveys and Questionnaires:
– Distributing surveys and questionnaires to a broad audience to collect
information on a larger scale. This technique is useful for gathering feedback
from a diverse set of stakeholders and can be particularly effective in large
projects.
• Workshops:
– Organizing facilitated group sessions or workshops where stakeholders come
together to discuss and define requirements. Workshops encourage
collaboration, idea generation, and the resolution of conflicting viewpoints in
a structured environment.
• Observation:
– Directly observing end-users in their work environment to understand their
workflows, pain points, and preferences. Observational techniques help in
uncovering implicit requirements that users might not explicitly state.
Tools and software used in requirements
Engineering.
• Prototyping:
– Creating mockups or prototypes of the software to provide stakeholders with
a tangible representation of the proposed system. Prototyping allows for early
visualization and feedback, helping to refine requirements based on
stakeholders' reactions.
• Use Cases and Scenarios:
– Developing use cases and scenarios to describe how the system will be used in
different situations. This technique helps in understanding the interactions
between users and the system, making it easier to identify and document
functional requirements.
• Document Analysis:
– Reviewing existing documentation, such as business process manuals, reports,
and forms, to extract relevant information. This technique provides insights
into the current processes and helps identify areas for improvement.
 Software used in requirements
Engineering
• IBM Rational DOORS:
• A widely recognized industry standard for complex systems, known for its robust
traceability features.
• Jira:
• A versatile project management tool with built-in features for requirement
management, particularly beneficial for Agile development methodologies.
• Jama Software:
• Specializes in handling complex projects with advanced capabilities for requirement
definition, testing, and risk assessment.
• ReqView:
• A cloud-based solution offering comprehensive requirement management features with
emphasis on collaboration and communication.
• Visure:
• Provides high level of customization to tailor the tool to specific project requirements.
• Codebeamer:
• An integrated Application Lifecycle Management (ALM) platform with strong
requirements management capabilities.
 Requirement Engineering Task:
• The broad spectrum of tasks and techniques that
lead to an understanding of requirements iscalled
requirements engineering. From a software process
perspective, requirements engineering is a major
software engineering action that begins during the
communication activity and continues into the
modeling activity. Requirements engineering provides the
appropriate mechanism for understanding what the customer
wants, analyzing need, assessing feasibility, negotiating a
reasonable solution, specifying the solution unambiguously,
validating the specification, and managing the requirements
as they are transformed into an operational system.
 Requirement Engineering Task:
• It encompasses seven distinct tasks: inception,
elicitation, elaboration, negotiation, specification, validation,
and management
• Inception
• Elicitation
• Elaboration
• Negotiation
• Specification
• Validation
• Management
 Requirement Engineering Task:
• Inception: This is the initial phase of a project where high-level
goals and objectives are identified. It includes feasibility studies and
understanding the stakeholders' needs, as well as defining the
scope of the project.
• Stakeholders from the business community define a business case
for the idea, try to identify the breadth and depth of the market, do
a rough feasibility analysis, and identify a working description of the
project’s scope.
• At project inception, you establish a basic understanding of the
problem, the people who want a solution, the nature of the
solution that is desired, and the effectiveness of preliminary
communication and collaboration between the other stakeholders
and the software team.
 Requirement Engineering Task:
• Elicitation: The process of gathering requirements from
stakeholders, users, and other sources. This step focuses on
understanding what users need and what the system should
do.
• Ask the customer, what the objectives for the system or
product are, what is to be accomplished, how the system or
product fits into the needs of the business, and finally, how
the system or product is to be used on a day-to-day basis.
 Requirement Engineering Task:
• Elaboration: This phase involves refining and expanding on
the requirements, providing more detail to ensure clarity and
alignment with the project goals. It often involves discussions
to refine and prioritize needs.
• The information obtained from the customer during inception
and elicitation is expanded and refined during elaboration.
This task focuses on developing ā refined requirements
model that identifies various aspects of software function,
behavior, and information.
 Requirement Engineering Task:
• Negotiation: In this phase, conflicting requirements are
addressed and compromises are made. Different stakeholders
may have different needs, and this step ensures that the
system meets as many needs as possible while balancing
trade-offs. You have to reconcile these conflicts through a
process of negotiation. Customers, users, and other
stakeholders are asked to rank requirements and then discuss
conflicts in priority. Using an iterative approach that prioritizes
requirements, assesses their cost and risk, and addresses
internal conflicts, requirements are eliminated, combined,
and/or modified so that each party achieves some measure of
satisfaction
 Requirement Engineering Task:
• Specification: The requirements are formally documented
and specified. This phase aims to provide clear, precise, and
detailed descriptions of what the system should do.
• Specification means different things to different people. A
specification can be a written document, a set of graphical
models, a formal mathematical model, a collection of usage
scenarios, a prototype, or any combination of these.
 Requirement Engineering Task:
• Validation: The requirements are verified to ensure that they
correctly reflect the stakeholders' needs and that they are
feasible. This step involves checking whether the system, once
built, will meet the expectations of users and stakeholders.
• It refers to a different set of tasks that ensures that the
software that has been built is traceable to customer
requirements. If requirements are not validated, errors in the
requirement definitions would propagate to the successive
stages resulting in a lot of modification and rework. The main
steps for this process include:
 Requirement Engineering Task:
• Management: This phase involves tracking, managing, and
controlling requirements throughout the life cycle of the
project. It includes changes, updates, and ensuring that the
final product aligns with the evolving needs of stakeholders.

• Summary:
Each stage has its role in ensuring that the project is aligned with
the needs of stakeholders, is feasible, and is well-managed
throughout the development process. In practical terms, these
phases ensure that the end product is what users want and
meets the project goals efficiently.
 Software Requirement Specification
(SRS)
• Software Requirement Specification (SRS) Format :
As the name suggests, is a complete specification
and description of requirements of the software that
need to be fulfilled for the successful development of
the software system. These requirements can be
functional as well as non-functional depending upon
the type of requirement. The interaction between
different customers and contractors is done because
it is necessary to fully understand the needs of
customers.
Software Requirement Specification
(SRS)
 Software Requirement Specification (SRS)

A Software Requirement Specification (SRS) is a comprehensive document that describes

the software system to be developed, including functional and non-functional requirements,
constraints, and the interaction between the system and its users, hardware, or other systems.
It serves as a bridge between the client's needs and the developers' work. It also acts as a
reference point for validation and verification during the software development process.

Need for SRS

1. Clear Understanding: It provides a clear understanding of what is expected from the

system, both for the development team and the client. This helps in avoiding
misunderstandings, reducing ambiguity, and ensuring that the final product meets the
requirements.
2. Reference Point: Acts as a foundation for design, development, testing, and
validation. It ensures the team works on the same objectives and reduces scope creep.
3. Communication: It serves as a communication tool among stakeholders, such as
customers, developers, project managers, and testers, ensuring that everyone is
aligned on what needs to be delivered.
4. Risk Management: Early identification of potential risks, such as technical feasibility
or resource constraints, helps mitigate issues before they arise.
5. Documentation: It helps in documenting the specifications and agreements made
during the project, useful for audits, future updates, and maintenance.
6. Quality Assurance: It forms the basis for testing the system’s compliance to
requirements, ensuring that the software works as intended and meets the client’s
needs.
7. Maintenance and Upgrades: When modifications are necessary after the initial
development phase, the SRS serves as a reference for ensuring that updates remain
aligned with the original system's objectives.

Format of SRS

The format of an SRS document can vary, but it generally follows a structured template that
covers key areas of the system. Below is a typical structure:

1. Introduction
o Purpose: Describes the purpose of the SRS document and its intended
audience.
o Scope: Outlines the boundaries of the software, including the main objectives
of the system.
o Definitions, Acronyms, and Abbreviations: Lists any terms that require
clarification.
o References: Cites any reference materials, such as related documents, books,
or standards.
o Overview: Gives an overview of the contents of the SRS document.
2. Overall Description
o Product Perspective: Describes how the system fits into its larger context or
interacts with other systems.
 o Product Functions: A summary of the software features and functionalities.
o User Characteristics: Describes the different types of users who will interact
with the system.
o Assumptions and Dependencies: Lists assumptions made and any external
dependencies (such as third-party software or hardware).
3. System Features and Requirements
o Functional Requirements: Describes what the system must do, including all
the core functionalities.
o Non-functional Requirements: Describes the performance, security,
reliability, scalability, and other quality attributes of the system.
o External Interface Requirements: Specifies how the software will interact
with other systems, hardware, and users.
o System Design Constraints: Lists limitations, such as specific technologies,
coding standards, and compliance requirements.
o User Interfaces: Describes the user interface requirements and expectations.
4. Other Requirements
o Performance Requirements: Specifies system speed, response time, etc.
o Security Requirements: Defines the security measures that need to be
implemented.
o Reliability and Availability Requirements: Specifies uptime and error
tolerance levels.
o Maintainability and Portability Requirements: Details how the software
should be updated or migrated to new platforms.
5. Appendix (Optional)
o Any additional material, such as use cases, diagrams, and supplementary
information.

Characteristics of a Good SRS

1. Correctness: The SRS must correctly represent all the requirements of the software
system as understood by the stakeholders. It should not contain any errors or
omissions.
2. Unambiguous: Each requirement should have only one possible interpretation. It is
crucial to avoid vague terms such as “easy,” “fast,” or “user-friendly,” as they can be
open to interpretation.
3. Completeness: The SRS should include all necessary requirements. It should cover
both functional and non-functional requirements and detail every aspect of the system.
4. Consistency: The document should not contain conflicting requirements or
statements. Every part of the SRS should be coherent with the rest.
5. Verifiability: The requirements must be testable. This means the system can be tested
to ensure it meets each requirement. The specification should be written in such a way
that testers can verify the correctness of the system.
6. Modifiability: The SRS should be easy to change. If any requirements are updated or
changed, the document should allow for modifications without impacting the structure
of the entire document.
7. Traceability: It should be possible to trace each requirement through the entire
software development life cycle, from design to testing, to ensure it has been properly
implemented and tested.
 8. Understandability: The document must be clear and easy to understand by both
technical and non-technical stakeholders. It should avoid jargon and technical terms
that might confuse the reader.
9. Feasibility: The requirements described in the SRS should be achievable within the
constraints of the project, such as time, budget, and resources.
10. Maintainability: As the project progresses or needs change, the SRS should remain
flexible enough to accommodate new requirements or modifications without losing its
clarity or integrity.

By following these guidelines and format, a Software Requirement Specification can be a

valuable tool throughout the development lifecycle of the software system.
 User Vs System Requirement in requirement engineering
:

In requirement engineering, the distinction between User Requirements and System

Requirements is crucial for clear communication and effective software development. Both
types of requirements serve different purposes and are often described in different formats,
but they are interconnected. Let's explore the differences in detail:

1. User Requirements

User Requirements define what the users of the system need or expect from it. They are
typically high-level descriptions that are expressed in natural language, focusing on the
system's goals, functionalities, and benefits from the user's perspective. These requirements
usually come from the stakeholders, including the end users, customers, or any party that will
interact with the system.

Key Characteristics of User Requirements:

 End-User Focused: They describe what the users need the system to do, often
without specifying technical details.
 High-Level: These requirements are more abstract and do not go into implementation
specifics. They provide an overview of system functionality.
 Written in Natural Language: They are typically written in plain, easy-to-
understand language so that non-technical stakeholders (e.g., business owners, users)
can easily understand the system’s needs.
 Goal-Oriented: They focus on achieving user goals or solving user problems.

Examples of User Requirements:

 The system must allow users to view their transaction history.

 The system should provide a notification for every new message received.
 The application must be available 24/7 for online transactions.

2. System Requirements

System Requirements break down the user requirements into more technical and detailed
specifications. These requirements describe the internal workings and the specific
functionalities that the system must fulfill in order to satisfy the user’s needs. System
requirements are more precise, detailed, and often include technical constraints and
specifications.

Key Characteristics of System Requirements:

 Technical Focus: These requirements focus on the technical aspects of the system,
including architecture, interface design, and data handling.
  Detailed and Specific: They are often more granular and precise than user
requirements. System requirements define how the system will meet user needs
through specific functionalities, operations, and performance metrics.
 Structured Format: System requirements are often written in a formal, structured
format (e.g., functional specifications, diagrams, models, and sometimes in a
requirement management tool).
 Measurable and Verifiable: Unlike user requirements, system requirements are
written in a way that they can be tested and verified, ensuring the system performs as
expected.

Examples of System Requirements:

 The system must be able to store up to 1 million transactions in a database with

retrieval times not exceeding 2 seconds per query.
 The software must support at least 100 concurrent users accessing the system without
performance degradation.
 The system must validate the user’s login credentials using two-factor authentication
(2FA) with an external authentication service.

Key Differences Between User Requirements and System Requirements:

Aspect User Requirements System Requirements

Detailed, technical
Nature High-level, abstract
Developers, testers, system architects, project
Non-technical stakeholders
Audience managers
(end users, business owners)
How the system will achieve those goals
What the system must achieve
Focus (technical details)
from the user’s perspective
More formal and technical, can include
Written in natural language,
Language mathematical or specific language
easy to understand
Specific, technical, and measurable
Detail Broad and general, no
Level technical details
The search function must allow searching by
The system should provide a
Example keyword, within 2 seconds, and return results
search function for users
sorted by relevance

Example Scenario:

User Requirement:

 "The user should be able to reset their password using an email link."
System Requirement:

 "The system must generate an email with a secure password reset link, which expires
after 30 minutes. The email should be sent via SMTP, and the reset process should
require the user to provide a new password that meets security standards."

Summary:

 User Requirements are high-level, general, and focused on what the users want to
achieve with the system, written in a language that is understandable to non-technical
stakeholders.
 System Requirements are specific, detailed, and technical descriptions of how the
system will fulfill the user requirements, written in a language understood by
developers and other technical staff.

Together, these two types of requirements are essential to ensure that the final system is both
functional from the user's perspective and technically feasible for the developers to build.