REQUIREMENT GATHERING :
Definition
Requirement Gathering is the process of collecting information about the customer's needs
and expectations for the software system.
Activities
Identify stakeholders (customers, users, managers).
Conduct interviews and meetings.
Use questionnaires and surveys.
Observe the existing system.
Study existing documents and reports.
Conduct brainstorming sessions.
Gather functional and non-functional requirements.
Output
A list of customer requirements.
Initial understanding of the problem.
REQUIREMENT ANALYSIS :
Definition
Requirement Analysis is the process of examining, refining, and organizing the gathered
requirements to ensure they are complete, correct, feasible, and consistent.
Activities
Understand the problem domain.
Identify functional and non-functional requirements.
Remove ambiguities and duplicate requirements.
Detect conflicts among requirements.
Prioritize requirements.
Check feasibility and constraints.
Model the system using tools such as DFDs, Use Cases, and ER Diagrams.
Prepare the Software Requirements Specification (SRS).
Output
Validated and organized requirements.
Software Requirements Specification (SRS).
VALUE OF A GOOD SRS (SOFTWARE REQUIREMENTS SPECIFICATION) :
A Software Requirements Specification (SRS) is a document that clearly defines the
requirements of a software system. It acts as a communication bridge between the client,
developer, and users. It establishes a common understanding of what the software should do
and serves as the basis for agreement between the client and the developer. Since many
software errors originate during the requirements phase, a high-quality SRS helps produce
high-quality software. It also reduces development cost by identifying requirement errors
early, avoiding expensive changes during later stages of development.
Important Points
1. Bridges the Communication Gap
o Clients know their business needs but not software development.
o Developers know software but may not understand the client's domain.
o SRS provides a common understanding between both parties.
2. Basis for Agreement
o Clearly defines what the software should do.
o Serves as an agreement (often part of a legal contract) between the client and
the developer.
3. Reference for Validation
o Used to verify whether the completed software meets all specified
requirements.
o Helps both the client and developer confirm that the project is completed
correctly.
4. Improves Software Quality
o Errors in requirements lead to errors in the final software.
o A well-written SRS is essential for developing high-quality software.
5. Reduces Development Cost
o Detecting and fixing requirement errors early is much cheaper than fixing
them later.
o A good SRS minimizes rework, saving both time and cost.
REQUIREMENT PROCESS :
Definition
The Requirement Process is the sequence of activities performed during the requirements
phase to produce a high-quality Software Requirements Specification (SRS).
Steps in the Requirement Process
1. Problem (Requirement) Analysis
Begins with a high-level problem statement.
Understands the client's needs, business environment, system behavior, inputs,
outputs, and constraints.
Analyst meets clients and end users to gather, clarify, and verify requirements.
The main goal is to understand what the software should do.
2. Requirements Specification
Converts the analyzed requirements into a well-structured SRS document.
Organizes requirements clearly.
Removes ambiguities and redundancies.
Uses appropriate specification languages and tools.
3. Requirements Validation
Checks whether the SRS is:
o Complete
o Correct
o Consistent
o Meets customer needs
Produces the validated SRS.
REQUIREMENTS SPECIFICATION (RS) :
Definition
Requirements Specification (RS) is the process of converting the knowledge obtained during
requirement analysis into a clear, complete, and well-organized Software Requirements
Specification (SRS) document. It describes what the software should do without explaining
how it will be implemented.
Key Points
Converts analyzed requirements into a structured SRS document.
Clearly specifies all functional and non-functional requirements.
Organizes requirements to remove ambiguities and redundancies.
Includes user interface requirements, error handling, performance requirements,
design constraints, standards compliance, and recovery requirements.
Uses appropriate specification languages, notations, and tools.
Provides a clear reference for designers, developers, testers, and customers.
Produces the final SRS, which serves as the basis for software development.
DESIRABLE CHARACTERISTICS OF AN SRS :
Definition
A good Software Requirements Specification (SRS) should possess certain qualities to
ensure that it clearly and accurately describes the software requirements.
Characteristics of a Good SRS
1. Correct
Every requirement in the SRS should represent the actual needs of the customer.
No incorrect or unnecessary requirements should be included.
2. Complete
The SRS should specify all functional and non-functional requirements.
It should describe the software's response to every possible input and situation.
Missing requirements can lead to costly changes later.
3. Unambiguous
Every requirement should have only one interpretation.
Clear and precise language should be used to avoid confusion.
4. Verifiable
Every requirement should be testable.
There should be a cost-effective method to verify whether the software satisfies each
requirement.
5. Consistent
Requirements should not conflict with each other.
The same terminology should be used throughout the document.
6. Ranked for Importance and/or Stability
Each requirement should be prioritized based on its importance.
Stability indicates how likely a requirement is to change in the future.
Helps in planning iterative or agile development.
COMPONENTS OF AN SRS :
An SRS (Software Requirements Specification) should specify the following four main
components:
1. Functionality
Describes what the system should do.
Specifies the relationship between inputs and outputs.
Includes:
o Input data and its source
o Valid input ranges
o Processing operations
o Output generation
o Error handling and abnormal situations
Covers the system's behavior for all valid and invalid inputs.
2. Performance Requirements
Describes the performance constraints of the software.
Static Requirements
Number of users supported
Number of terminals
Number and size of files
Capacity requirements
Dynamic Requirements
Response time
Throughput (operations per unit time)
Performance under normal and peak loads
Performance requirements should be measurable and verifiable.
3. Design Constraints
These are restrictions that affect the software design.
Examples include:
Standards compliance
Hardware limitations
Reliability and fault tolerance
Security requirements
Recovery requirements
These constraints guide developers during system design.
4. External Interfaces
Describes how the software interacts with other entities.
Includes:
User interfaces (screens, menus, commands)
Hardware interfaces
Software interfaces
Communication interfaces
All interfaces should be clearly specified.
GENERAL STRUCTURE OF AN SRS (IEEE FORMAT) :
The IEEE recommends the following general structure for an SRS:
1. Introduction
Purpose
Scope
Definitions, Acronyms, and Abbreviations
References
Overview
2. Overall Description
Product Perspective
Product Functions
User Characteristics
General Constraints
Assumptions and Dependencies
3. Specific Requirements/Detailed Requirements
External Interface Requirements
Functional Requirements
Performance Requirements
Design Constraints
Attributes
Other Requirements
Easy Mnemonic
Components of SRS: FPDI
F – Functionality
P – Performance
D – Design Constraints
I – Interfaces
IEEE SRS Structure: IOS
I – Introduction
O – Overall Description
S – Specific Requirements
FUNCTIONAL SPECIFICATION WITH USE CASES :
Definition
Functional Specification with Use Cases is a method of specifying the functional
requirements of a software system by describing the interaction between users (actors) and
the system to achieve specific goals. Use cases focus on what the system should do, not how
it is implemented.
Key Concepts
1. Actor
An actor is a person or another system that interacts with the software to achieve a
goal.
Actors represent different types of users or external systems.
2. Primary Actor
The primary actor is the main user who initiates a use case to achieve a goal.
The success of the use case is mainly intended to satisfy this actor's goal.
3. Scenario
A scenario is a sequence of actions performed by the actor and the system to achieve
a specific goal.
Each step represents an action by the actor or the system.
4. Main Success Scenario
Describes the normal flow when everything works successfully.
All steps are completed without any errors.
5. Extension (Exception) Scenario
Describes what happens when an error or exceptional condition occurs.
Specifies how the system handles failures or abnormal situations.
Important Points
Use cases describe the external behavior of the system.
They help in requirements analysis as well as requirements specification.
They focus on user interactions rather than internal system design.
A use case is a collection of main success and extension (exception) scenarios.
Use cases mainly capture functional requirements.
Other requirements such as performance and design constraints must still be
included separately in the SRS.
Advantages of Use Cases
Easy to understand for both users and developers.
Clearly describes system functionality.
Focuses on user goals and system behavior.
Helps in requirement gathering and validation.
Avoids unnecessary design details during the requirements phase.
Data Flow Diagram (DFD)
Definition
A Data Flow Diagram (DFD) is a graphical representation of how data flows through a
system. It shows how input data is transformed into output through different processes. It is
mainly used during requirement analysis.
Content
A DFD represents the flow of data within a system.
It views the system as a function that transforms inputs into outputs.
Data passes through a series of processes (bubbles) before becoming the final output.
A process performs the transformation of data.
Data flows are represented by arrows showing the movement of data.
A source/sink (rectangle) represents an external entity that provides or receives data.
External files and data stores can also be represented in the DFD.
Leveled DFD
Large systems are represented using leveled DFDs.
The Context Diagram is the highest-level DFD, showing the entire system as a single
process.
Each process can be refined into lower-level DFDs until it becomes simple enough to
understand.
DATA DICTIONARY :(include in data flow diagram concept)
Definition
A Data Dictionary is a centralized repository that defines and describes all the data elements,
data flows, data stores, and data structures used in a Data Flow Diagram (DFD). It provides a
precise description of the data so that everyone involved in the project has a common
understanding.
Purpose
Defines the exact structure of each data flow in a DFD.
Removes ambiguity in data definitions.
Helps analysts, designers, and developers understand the meaning of data.
Ensures consistency throughout the software development process.
Contents of a Data Dictionary
A data dictionary generally contains:
Data Name – Name of the data element or data flow.
Description – Meaning or purpose of the data.
Data Structure – Components that make up the data.
Data Type – Integer, String, Date, etc.
Length/Size – Maximum size of the data.
Valid Values – Allowed range or values.
Source – Where the data originates.
Destination – Where the data is used or stored.
Notation Used
The data dictionary uses a notation similar to regular expressions to define data structures:
+ (Sequence/Composition): Combines data elements.
o Example: Student = Student_ID + Name + Department
| (Selection / OR): One of the alternatives.
o Example: Gender = Male | Female
*** (Repetition):** Indicates repeated occurrence.
o Example: Subjects = Subject* (one or more subjects)
These symbols define the structure of data precisely.
Example
Data Name Structure
Student Student_ID + Name + Department
Employee Emp_ID + Name + Salary
Address House_No + Street + City + PIN
Payment Cash | Card | UPI
Entity Relationship Diagram (ER Diagram)
Definition
An Entity Relationship (ER) Diagram is a graphical model used to represent the data
structure of a system. It shows entities, their attributes, and the relationships between them.
It is mainly used in database design.
Content
Entity
An entity is a real-world object or concept that stores information.
Entities are represented by rectangles.
Each entity is similar to a table in a database.
Attribute
An attribute describes the properties of an entity.
Attributes are represented by ellipses (ovals) attached to the entity.
Relationship
A relationship connects two entities.
It shows how entities are associated with each other.
Relationships can also exist between instances of the same entity.
Cardinality (Types of Relationships)
One-to-One (1:1): One entity is related to exactly one entity.
One-to-Many (1:N): One entity is related to many entities.
Many-to-One (N:1): Many entities are related to one entity.
Many-to-Many (M:N): Many entities are related to many entities.
Database Mapping
Each entity becomes a table in the database.
Relationships determine the foreign keys needed between tables.