Requirement Gathering Techniques

Requirement Gathering is the process of collecting information from customers, users, and other stakeholders to understand what the software system should do.

Major Requirement Gathering Techniques

Interviews

Developers ask questions directly to customers or users.

Helps understand their needs, problems, and expectations.

Example: Interviewing teachers to identify requirements for a college management system.

Questionnaires / Surveys

A set of questions is given to many users.

Useful when information needs to be collected from a large number of people.

Example: Asking students what features they expect in a learning application.

Observation

The analyst observes users while they perform their normal work.

Helps identify requirements that users may forget to mention.

Example: Observing how a librarian manages book records.

Workshops

Customers, users, developers, and analysts meet together to discuss requirements.

Helps identify and resolve requirements quickly.

Example: A workshop with teachers and administrators to decide features of a college ERP system.

Document Analysis

Existing documents, forms, reports, manuals, and records are studied.

Useful when replacing or improving an existing system.

Example: Studying existing admission forms before developing an admission management system.

Prototyping

A simple model or prototype of the software is created.

Users can see it and suggest changes.

Example: Creating a sample screen of a mobile banking application before developing the complete system.

Brainstorming

Team members freely suggest ideas and requirements.

Helps generate many possible requirements.

Example: Developers and users brainstorming features for a new shopping application.

Focus Groups

A small group of selected users discusses their needs and opinions.

Useful for understanding user expectations and preferences.

Quick Summary

Technique	Main Purpose
Interview	Directly ask users
Questionnaire	Collect information from many users
Observation	Watch users perform their work
Workshop	Group discussion
Document Analysis	Study existing documents
Prototyping	Get feedback using a model
Brainstorming	Generate new ideas
Focus Group	Understand user opinions

 

Software Requirement Specification (SRS)

Software Requirement Specification (SRS) is a formal document that describes all the requirements of a software system. It explains what the system should do, how it should perform, and what constraints it must follow.

In simple words, SRS acts as a blueprint for software development.

Example

Suppose we are developing a College Management System. The SRS may specify:

1.                      Students can register and log in.

2.                      Teachers can enter attendance.

3.                      Students can view their attendance.

4.                      The system should respond quickly.

5.                      Only authorized users can access student records.

6.                      The system should be available during college working hours.

Main Contents of SRS

1. Introduction

Provides basic information about the software.

It contains the complete requirements of the software, including its functional requirements, non-functional requirements, interfaces, constraints, and expected behavior.

It acts as an agreement between the customer and the development team.

 

It includes:

a.                       Purpose of the system

b.                      Scope of the project

c.                        Definitions and abbreviations

d.                      Overview of the document

 

a. The main purpose of an SRS is to provide a clear and complete description of the software requirements.

b. Scope of the project: The College Management System (CMS) is designed to computerize and simplify the major administrative and academic activities of a college. Example

a.                       Student Management:

b.                      Faculty Management:

c.                        Admission Management:

d.                      Attendance Management:

e.                       Course and Subject Management:

f.  Examination Management:

 

It helps:

• Customers explain what they need.
• Developers understand what they have to build.
• Testers determine what needs to be tested.
• Project managers estimate time and cost.
• Organizations maintain proper documentation.

Example

Suppose a college wants a Student Management System.

The SRS may specify that the system should allow:

• Student registration
• Attendance management
• Fee management
• Examination management
• Result generation
• Report generation

2. Overall Description

Gives a general description of the system.

It includes:

a.                       Product perspective (the ability to think about problems and decisions in a reasonable way without exaggerating them)

b.                      Product functions

c.                        User characteristics

d.                      Assumptions and dependencies

e.                       System constraints

3. Functional Requirements

Describe what the system should do.

Example:

The system shall allow users to log in.

The system shall generate student reports.

The system shall allow administrators to add or remove users.

4. Non-Functional Requirements

Describe how well the system should perform.

Examples:

Performance – System should respond quickly.

Security – Only authorized users should access confidential data.

Reliability – System should work consistently.

Availability – System should be accessible when required.

Usability – System should be easy to use.

Maintainability – System should be easy to modify.

5. External Interface Requirements

Describes how the software interacts with external components.

Examples:

User interface

Hardware interfaces

Software interfaces

Communication/network interfaces

6. Constraints

Specify limitations that must be followed.

Example:

The system must use a particular database.

The software must run on a specified operating system.

The project must follow organizational or legal requirements.

7. Assumptions and Dependencies

Describes conditions assumed to be true and external factors on which the system depends.

Characteristics of a Good SRS

A good SRS should be:

Correct – Contains accurate requirements.

Complete – Includes all necessary requirements.

Unambiguous – Each requirement has only one clear meaning.

Consistent – Requirements do not contradict each other.(No opposing rules)

Verifiable – Requirements can be tested.

Feasible – Requirements can realistically be implemented.

Traceable – Each requirement can be tracked throughout development.

Modifiable – Changes can be made easily.

Importance of SRS

1.                      Provides a clear understanding of the project.

2.                      Acts as a communication document between customers and developers.

3.                      Helps developers design and develop the system.

4.                      Provides a basis for testing.

5.                      Reduces misunderstandings.

6.                      Helps estimate cost and development time.

7.                      Makes future maintenance easier.

Feasibility Study-

A Feasibility Study is an analysis carried out to determine whether the proposed College Management System is practical, achievable, and beneficial for the college. It helps identify the technical, economic, operational, and other requirements before starting development.

1. Technical Feasibility

The system can be developed using commonly available technologies such as HTML, CSS, JavaScript, PHP/Python/Java, and MySQL. The required computers, database systems, and network facilities are generally available in a college environment. Therefore, the project is technically feasible.

2. Economic Feasibility

The system reduces expenses associated with paper-based records, manual data entry, and administrative work. Since the project can be developed using open-source software and existing infrastructure, the development and maintenance costs can be kept low. Therefore, it is economically feasible.

3. Operational Feasibility

The system will be easy for administrators, faculty, and students to use. It can simplify activities such as student management, attendance, examination, fees, and report generation. Proper training can help users operate the system effectively

Conclusion

The feasibility study indicates that the College Management System is technically, economically, operationally, and practically feasible. The proposed system can reduce manual work, improve data accuracy, save time, and provide faster access to college