Requirement Analysis and Specification in Software Engineering

1. Requirement Analysis:

Definition:
Requirement analysis is the process of discovering, analyzing, validating, and documenting the needs
and requirements of the stakeholders for a software system.

Objectives:

• Understand what the user wants from the system.

• Define the system's boundaries and constraints.

• Ensure the requirements are complete, clear, and feasible.

Activities in Requirement Analysis:

• Requirements Elicitation: Gathering requirements using interviews, questionnaires,

observation, etc.

• Requirements Analysis: Examining the collected requirements to resolve conflicts, remove

ambiguities, and check feasibility.

• Requirements Validation: Ensuring the requirements are correct, complete, and meet the
users’ needs.

• Requirements Documentation: Writing clear and detailed requirements in a structured

format.

2. Requirement Specification:

Definition:
Requirement specification is the process of documenting the analyzed requirements in a clear,
precise, and organized manner. This document is known as the Software Requirements Specification
(SRS).

Types:

• Functional Requirements: What the system should do (features, behaviors).

• Non-Functional Requirements: How the system should behave (performance, usability,

reliability, etc.).

• Constraints: Limitations like legal, hardware, or regulatory constraints.

Purpose of SRS:

• Acts as a contract between the client and the development team.

• Provides a clear roadmap for design, development, testing, and maintenance.

• Helps avoid misunderstandings and project failures.

 1. Functional Requirements
• Functional requirements describe what the system should do. They define specific
functions and features, such as user login, product search, form submissions, and
payment processing. These requirements guide the core functionality by outlining
how the system should behave in response to different inputs or events
• They focus on user interactions with the system, ensuring the proper flow of data and
actions between the user interface and the backend. Functional requirements also
include business logic—like applying discounts or validating email addresses—that
the system must follow.
• Additionally, they describe the system's behavior during specific scenarios, such as
how it should react when a user submits incorrect data. These are essential for
developers to build the right features and for testers to verify that everything works as
expected.

Key Characteristics:

1. Describe system behavior in response to inputs.

2. Define workflows, system operations, and how it interacts with users or other
systems.
3. Essential for development and testing — they tell developers what to build and
testers what to test.
4. Tied to business rules and logic.

Common Types of Functional Requirements:

• User authentication: Login, logout, signup, forgot password.

• Data input/output: Form submissions, report generation.
• Data validation: Ensure email is in correct format, password length, etc.

2. Non-Functional Requirements
• Non-functional requirements define how the system should perform rather than what
it should do. They include aspects like performance, specifying that the system must
respond within 2 seconds under normal load, or reliability, stating that uptime should
be at least 99.9%.
• They also address usability, ensuring that the interface is easy to navigate and user-
friendly, especially for new users. Security is another major component, requiring
data encryption, access control, and secure login methods like two-factor
authentication.
• Maintainability and scalability are crucial too—developers should be able to easily
update the code, and the system should handle growth in users and data without
slowing down. Portability and availability are also considered, ensuring the system
works on different devices and remains accessible during the required hours.
 Category Explanation Example
Speed, response time, "The system should respond within 2
Performance
throughput seconds for 95% of queries."
Ability to grow in user "Must handle 1,000 concurrent users
Scalability
base/data volume without degradation."
Protection of data and system "Password must be hashed using SHA-256;
Security
access use 2FA for login."
System uptime and failure "System should have 99.9% uptime
Reliability
resistance annually."
Ease of fixing issues or "Code should follow naming conventions
Maintainability
upgrading and be documented."
User interface clarity and "New users should learn the system within
Usability
ease of use 30 minutes."
Ability to run on different "The application must run on both iOS and
Portability
devices/OS Android."
Time system is operational "System must be available from 6 AM to 12
Availability
and accessible AM daily."

Importance:

• A system might work functionally but fail in performance or usability if NFRs are
not defined.
• Affects user satisfaction, reputation, and long-term success.

3. User Requirements
• User requirements describe what the end users expect the system to do in simple, non-
technical language. These requirements often come from interviews, surveys, or
observations of how users interact with existing systems or prototypes.
• They focus on user goals and how the system can help achieve them. For instance, a
user may want to track their orders, reset their password, or apply a promo code at
checkout. These needs are usually expressed as user stories in Agile projects—for
example: “As a user, I want to view my transaction history so I can track my
expenses.”
• User requirements are crucial because they directly reflect what stakeholders and
customers expect. They guide the overall direction of the software, helping developers
prioritize features that deliver real value to users.
Key Characteristics:
1. Written in non-technical, user-friendly language.
2. Describe the system from the user's point of view.
3. Help bridge the gap between stakeholders and developers.
4. Typically used in early phases to understand goals.
 Formats:
• Natural language statements: "The user should be able to search for products."
• User Stories (Agile):
As a [type of user], I want [a feature] so that [a benefit].

Examples:
• "As a student, I want to track my attendance so that I can know when I need to
improve."
• "As a customer, I want to apply coupons during checkout to get discounts."
• "As an admin, I want to delete users who violate the terms."

Importance:
• Help elicit and prioritize features.
• Used to initiate discussions between clients and developers

4. System Requirements
• System requirements provide detailed technical specifications for the development
team. They are more precise than user requirements and include both functional and
non-functional aspects in a structured format, usually documented in the Software
Requirements Specification (SRS).
• They define how features will be implemented—such as using OAuth 2.0 for login or
storing files on cloud services like AWS. These requirements cover hardware
configurations, operating systems, memory limits, and integration with other systems
or APIs.
• System requirements also help ensure compatibility, scalability, and maintainability.
They are essential for architects to design the system infrastructure, for developers to
build the solution, and for testers to validate whether all expectations are met.

Two Categories:

1. Functional System Requirements

o Specific functions the system must support (derived from user stories).
2. Non-Functional System Requirements
o Detailed technical implementation of non-functional attributes.

Key Characteristics:

1. Written for developers, testers, and system architects.

2. Form the basis of system design and architecture.
3. Often documented in the Software Requirements Specification (SRS).
 Examples:

Functional:

• "The system shall store user login sessions using JWT for 30 minutes of inactivity."
• "When the user uploads a file, it shall be stored in Amazon S3."

Non-Functional:

• "System uptime shall be maintained at 99.95% per quarter."

• "All external API calls must timeout after 5 seconds."

Importance:

• Ensure all required system-level behavior is well defined.

• Allow for system testing, performance measurement, and technical planning.

2.Requirement Analysis and Gathering – Detailed Explanation

Requirement Analysis and Gathering is one of the most critical

phases in the Software Development Life Cycle (SDLC). It involves
understanding what the client needs, what the end users expect, and
what the system should do to fulfill those expectations. This stage sets
the foundation for the design, development, testing, and deployment
of the software.

Requirement Gathering

Requirement gathering is the process of collecting information from

various stakeholders—such as clients, users, business managers, and
system administrators—about what they want the system to do.

• Stakeholder Identification: The first step is to identify all

stakeholders involved in the system. This includes end users,
customers, project sponsors, domain experts, and regulatory
bodies.
• Techniques Used:
o Interviews: One-on-one meetings to understand individual
needs.
o Questionnaires/Surveys: Used when stakeholders are
many and geographically distributed.
o Workshops: Interactive group sessions to collect,
prioritize, and discuss needs.
o Observation: Studying how users currently perform their
tasks to find pain points.
o Document Analysis: Reviewing existing systems, reports,
or manuals.
• Goal: The primary goal of requirement gathering is to collect
complete, clear, and unambiguous information about the
system to be developed.

1. Feasibility Study

The Feasibility Study is the initial stage where the project team
determines whether the proposed system is technically,
economically, legally, operationally, and schedule-wise feasible.

• Technical Feasibility: Assesses if the technology, tools, and

platforms required are available and sufficient to implement the
solution.
• Economic Feasibility: Evaluates the cost-benefit ratio to ensure
the project is financially viable and offers a good return on
investment.
• Legal Feasibility: Checks for legal constraints like licensing,
compliance with data protection laws, or regulatory issues.
• Operational Feasibility: Considers whether the solution can be
integrated into existing processes and if users will accept and
use the system.
• Schedule Feasibility: Determines whether the solution can be
delivered within the given timeframe and milestones.

Outcome: A Feasibility Report that decides whether to

proceed with the project.
 2. Requirements Elicitation

Elicitation involves actively extracting requirements from

stakeholders, users, domain experts, and business representatives.

Techniques used:

• Interviews: Direct discussions to understand stakeholder needs.

• Surveys/Questionnaires: Used to gather data from a large
group efficiently.
• Workshops/Brainstorming Sessions: Interactive sessions that
bring stakeholders together to define and refine needs.
• Observation (Job Shadowing): Watching users perform their
tasks to discover hidden or unspoken needs.
• Prototyping: Creating basic UI mockups to clarify user
expectations.
• Document Analysis: Studying existing documentation, systems,
and business processes.

Outcome: A raw list of user needs, business requirements, and

technical expectations.

3. Requirements Analysis and Negotiation

After gathering, requirements are analyzed, refined, and

prioritized to ensure they are clear, feasible, and complete.

Analysis includes:

• Clarity and Consistency: Removing ambiguity, redundancy,

and conflicts.
• Feasibility Check: Ensuring technical and financial feasibility
of each requirement.
• Dependency Mapping: Identifying interdependencies between
requirements.
 Negotiation includes:

• Conflict Resolution: Resolving conflicting requirements among

stakeholders (e.g., security vs. usability).
• Prioritization: Deciding which features must be delivered first,
using models like MoSCoW (Must-have, Should-have, Could-
have, Won’t-have).
• Trade-off Analysis: Evaluating impact of time, cost, and scope
on requirement inclusion.

Outcome: A validated and prioritized list of clear, non-

conflicting requirements.

4. Requirements Specification

Requirements are then documented formally in a structured

format, typically in a Software Requirements Specification
(SRS) document.

SRS includes:

• Introduction: Purpose, scope, and definitions.

• Functional Requirements: What the system must do (e.g.,
login, report generation).
• Non-Functional Requirements: System qualities like
performance, security, and usability.
• Use Case Diagrams / DFDs / Flowcharts: Visual
representations of system behavior.
• Interface Requirements: UI/UX and integration details with
other systems.
• Constraints and Assumptions: Hardware limitations,
development platforms, etc.

Outcome: A complete, clear, and approved SRS document as a

baseline for development.
 5. Requirements Validation

In this phase, the team verifies that the documented requirements

accurately represent stakeholder needs and are suitable for
design and development.

Validation techniques:

• Reviews/Walkthroughs: Group sessions where stakeholders

review the SRS.
• Prototypes: Used to validate unclear or critical UI/UX features.
• Checklists: Used to ensure all types of requirements (functional,
non-functional) are covered.
• Acceptance Criteria Review: Ensuring each requirement has
measurable and testable acceptance conditions.

Outcome: A signed-off requirements document, ensuring

correctness and completeness.

6. Requirements Management

Requirements management ensures that requirements are tracked,

updated, and maintained throughout the software lifecycle.

Key activities:

• Version Control: Maintaining multiple versions of

requirements as they evolve.
• Traceability Matrix: Mapping requirements to design, code,
and test cases to ensure every requirement is addressed.
• Change Management: A formal process to evaluate, approve,
and implement requirement changes.
• Impact Analysis: Assessing how changes affect cost, time, and
other requirements.

Outcome: Controlled, traceable, and adaptable requirement

sets throughout the project.
UML
Unified Modeling Language (UML) is a general-purpose modeling
language. The main aim of UML is to define a standard way to
visualize the way a system has been designed. It is quite similar to
blueprints used in other fields of engineering. UML is not a
programming language, it is rather a visual language

1. What is UML?

Unified Modeling Language (UML) is a standardized visual

modeling language that is a versatile, flexible, and user-friendly
method for visualizing a system's design. Software system artifacts
can be specified, visualized, built, and documented with the use of
UML.

• We use UML diagrams to show the behavior and structure of a

system.

• UML helps software engineers, businessmen, and system

2. Why do we need UML?

We need UML (Unified Modeling Language) to visually represent

and communicate complex system designs, facilitating better
understanding and collaboration among stakeholders. Below is
why we need UML:

• Complex applications need collaboration and planning from

multiple teams and hence require a clear and concise way to
communicate amongst them.
• Businessmen do not understand code. So UML becomes
essential to communicate with non-programmers about essential
requirements, functionalities, and processes of the system.

• A lot of time is saved down the line when teams can visualize
processes, user interactions, and the static structure of the
system.

3. Types of UML Diagrams

UML is linked with object-oriented design and analysis. UML

makes use of elements and forms associations between them to
form diagrams. Diagrams in UML can be broadly classified as:

4. Structural UML Diagrams

Structural UML diagrams are visual representations that depict the

static aspects of a system, including its classes, objects,
components, and their relationships, providing a clear view of the
system's architecture. Structural UML diagrams include the
following types:

4.1. Class Diagram

The most widely use UML diagram is the class diagram. It is the
building block of all object oriented software systems. We use
class diagrams to depict the static structure of a system by showing
system's classes, their methods and attributes. Class diagrams also
help us identify relationship between different classes or object

Class Diagram

4.2. Composite Structure Diagram

We use composite structure diagrams to represent the internal

structure of a class and its interaction points with other parts of the
system.

• A composite structure diagram represents relationship between

parts and their configuration which determine how the classifier
(class, a component, or a deployment node) behaves.

• They represent internal structure of a structured classifier

making the use of parts, ports, and connectors.
• We can also model collaborations using composite structure
diagrams.

• They are similar to class diagrams except they represent

individual parts in detail as compared to the entire class.

4.3. Object Diagram

An Object Diagram can be referred to as a screenshot of the

instances in a system and the relationship that exists between them.
Since object diagrams depict behaviour when objects have been
instantiated, we are able to study the behaviour of the system at a
particular instant.

• An object diagram is similar to a class diagram except it shows

the instances of classes in the system.

• We depict actual classifiers and their relationships making the

use of class diagrams.

• On the other hand, an Object Diagram represents specific

instances of classes and relationships between them at a point of
time.
Object Diagram

4.4. Component Diagram

Component diagrams are used to represent how the physical

components in a system have been organized. We use them for
modelling implementation details.

• Component Diagrams depict the structural relationship between

software system elements and help us in understanding if
functional requirements have been covered by planned
development.

• Component Diagrams become essential to use when we design

and build complex systems.

• Interfaces are used by components of the system to

communicate with each other.

Component Diagram

4.5. Deployment Diagram

Deployment Diagrams are used to represent system hardware and
its software. It tells us what hardware components exist and what
software components run on them.

• We illustrate system architecture as distribution of software

artifacts over distributed targets.

• An artifact is the information that is generated by system

software.

• They are primarily used when a software is being used,

distributed or deployed over multiple machines with different
configurations.

4.6. Package Diagram

We use Package Diagrams to depict how packages and their

elements have been organized. A package diagram simply shows
us the dependencies between different packages and internal
composition of packages.

• Packages help us to organise UML diagrams into meaningful

groups and make the diagram easy to understand.

• They are primarily used to organise class and use case diagrams.
Package Diagram

5. Behavioral UML Diagrams

Behavioral UML diagrams are visual representations that depict

the dynamic aspects of a system, illustrating how objects interact
and behave over time in response to events.

5.1. State Machine Diagrams

A state diagram is used to represent the condition of the system or

part of the system at finite instances of time. It’s a behavioral
diagram and it represents the behavior using finite state transitions.

• State diagrams are also referred to as State machines and State-

chart Diagrams

• These terms are often used interchangeably. So simply, a state

diagram is used to model the dynamic behavior of a class in
response to time and changing external stimuli.
State Machine Diagram

5.2. Activity Diagrams

We use Activity Diagrams to illustrate the flow of control in a

system. We can also use an activity diagram to refer to the steps
involved in the execution of a use case.

• We model sequential and concurrent activities using activity

diagrams. So, we basically depict workflows visually using an
activity diagram.

• An activity diagram focuses on condition of flow and the

sequence in which it happens.

• We describe or depict what causes a particular event using an

activity diagram.
Activity Diagram

5.3. Use Case Diagrams

Use Case Diagrams are used to depict the functionality of a system

or a part of a system. They are widely used to illustrate the
functional requirements of the system and its interaction with
external agents(actors).

• A use case is basically a diagram representing different

scenarios where the system can be used.

• A use case diagram gives us a high level view of what the

system or a part of the system does without going into
implementation details. '

5.4. Sequence Diagram

A sequence diagram simply depicts interaction between objects in

a sequential order i.e. the order in which these interactions take
place.

• We can also use the terms event diagrams or event scenarios to

refer to a sequence diagram.
• Sequence diagrams describe how and in what order the objects
in a system function.

• These diagrams are widely used by businessmen and software

developers to document and understand requirements for new
and existing systems.

Sequence Diagram

6. Object-Oriented Concepts Used in UML Diagrams

Examples of object-oriented concepts in UML diagrams include

classes, objects, inheritance, abstraction, encapsulation, and
polymorphism. These concepts improve modularity and clarity by
offering an orderly way to show complex systems.

• Class: An object's structure and behavior are defined by its

class, which serves as a blueprint.

• Objects: We may divide complex systems into smaller, more

manageable components by using objects. Because of its
modularity, we can concentrate on easily understood
components and develop the system gradually.

• Inheritance: Child classes can inherit the characteristics and

functions of their parent classes.
• Abstraction: The main characteristics of a system or object are
highlighted in UML abstraction, while extraneous details are
ignored. Stakeholder communication and understanding are
improved by this simplification.

• Encapsulation: Encapsulation is the process of integrating data

and restricting external access in order to maintain the integrity
of the data.

• Polymorphism: Flexibility in their use is made possible by

polymorphism, the capacity of functions or entities to take on
multiple forms.

8. Steps to create UML Diagrams

Creating Unified Modeling Language (UML) diagrams involves a

systematic process that typically includes the following steps:

• Step 1: Identify the Purpose:

o Decide on the objective for which the UML diagram is
being made. Among the many applications for the many
types of UML diagrams are requirements collection,
system architecture development, and class relationship
documentation.

• Step 2: Identify Elements and Relationships:

 o Choose which crucial elements—classes, objects, use
cases, etc.—should be included in the diagram, along with
their relationships.

• Step 3: Select the Appropriate UML Diagram Type:

o Select the type of UML diagram that best suits your
modeling requirements. Class diagrams, use case
diagrams, sequence diagrams, activity diagrams, and more
are examples of common forms.

• Step 4: Create a Rough Sketch:

o A basic sketch on paper or a whiteboard can be useful
before utilizing a UML modeling tool. This can assist you
in seeing how the elements are arranged and related to one
another.

• Step 5: Choose a UML Modeling Tool:

o Choose a UML modeling tool based on your needs.
Numerous offline and online applications are available
with features for making and modifying UML diagrams.

• Step 6: Create the Diagram:

o Create a new project or diagram using the UML modeling
tool of your choice. Start by adding components to the
diagram, such as actors, classes, and use cases, and then
link them together with the proper relationships, such as
dependencies and associations.

• Step 7: Define Element Properties:

o Give each diagram element the appropriate qualities and
attributes. Use case specifics, class characteristics and
methods, and any other information unique to the diagram
type may be included.

• Step 8: Add Annotations and Comments:

o By using annotations, remarks, and clarifying notes, you
can improve the diagram's readability.

• Step 9: Validate and Review:

 o Check the diagram for completeness and accuracy. Make
that the elements, limitations, and linkages appropriately
depict the system or process that is intended.

• Step 10: Refine and Iterate:

o Refine the diagram based on feedback and additional
insights. UML diagrams are often created iteratively as the
understanding of the system evolves.

Note: Remember that the specific steps may vary based on the