Practical – 1

AIM: Define the Problem statement of Software development and after identifying the
requirements based on the requirement engineering tasks prepare the Software Requirement
Specification (SRS) document.

• Objectives: To learn how to define the problem statement for software development
and how to identify the requirements while performing requirements engineering
tasks and to learn what are the contents of SRS and how to write the contents in SRS.

• Theory:

o The process of collecting the software requirement from the client then
understand, evaluate and document it is called as requirement engineering.
o Requirement engineering constructs a bridge for design and construction.

Figure: Requirements Engineering Process

o The production of the requirements stage of the software development process is

Software Requirements Specifications (SRS) (also called a requirements
document). This report lays a foundation for software engineering activities and is
constructing when entire requirements are elicited and analyzed. SRS is a formal report,
which acts as a representation of software that enables the customers to review whether
it (SRS) is according to their requirements. Also, it comprises user requirements for a
system as well as detailed specifications of the system requirements.
o The SRS is a specification for a specific software product, program, or set of
applications that perform particular functions in a specific environment. It serves
several goals depending on who is writing it. First, the SRS could be written by the
 client of a system. Second, the SRS could be written by a developer of the system. The
two methods create entirely various situations and establish different purposes for the
document altogether. The first case, SRS, is used to define the needs and expectation
of the users. The second case, SRS, is written for various purposes and serves as a
contract document between customer and developer.

Characteristics of good SRS

1. Correctness
2. Completeness
3. Consistency
4. Unambiguousness
5. Ranking for importance and stability
6. Modifiability
7. Verifiability
8. Traceability
9. Design Independence
10. Testability
11. Understandable by the customer
12. The right level of abstraction

The following are the features of a good SRS document:

1. Correctness: User review is used to provide the accuracy of requirements stated

in the SRS. SRS is said to be perfect if it covers all the needs that are truly
expected from the system.
2. Completeness: The SRS is complete if, and only if, it includes the following
elements:

(1). All essential requirements, whether relating to functionality,

performance, design, constraints, attributes, or external interfaces.

(2). Definition of their responses of the software to all realizable classes of

input data in all available categories of situations.

(3). Full labels and references to all figures, tables, and diagrams in the SRS
and definitions of all terms and units of measure.

3. Consistency: The SRS is consistent if, and only if, no subset of individual
requirements described in its conflict. There are three types of possible conflict
in the SRS:

(1). The specified characteristics of real-world objects may conflicts. For

example,
(a) The format of an output report may be described in one requirement as
tabular but in another as textual.
 (b) One condition may state that all lights shall be green while another states
that all lights shall be blue.
(2). There may be a reasonable or temporal conflict between the two specified
actions. For example,
(a) One requirement may determine that the program will add two inputs, and
another determine that the program will multiply them.
(b) One condition may state that "A" must always follow "B," while other
requires that "A and B" co-occurs.
(3). Two or more requirements may define the same real-world object but use
different terms for that object. For example, a program's request for user input
may be called a "prompt" in one requirement's and a "cue" in another. The use
of standard terminology and descriptions promotes consistency.

4. Unambiguousness: SRS is unambiguous when every fixed requirement has

only one interpretation. This suggests that each element is uniquely interpreted.
In case there is a method used with multiple definitions, the requirements report
should determine the implications in the SRS so that it is clear and simple to
understand.
5. Ranking for importance and stability: The SRS is ranked for importance and
stability if each requirement in it has an identifier to indicate either the
significance or stability of that particular requirement.

Typically, all requirements are not equally important. Some prerequisites

may be essential, especially for life-critical applications, while others may be
desirable. Each element should be identified to make these differences clear and
explicit. Another way to rank requirements is to distinguish classes of items as
essential, conditional, and optional.

6. Modifiability: SRS should be made as modifiable as likely and should be

capable of quickly obtain changes to the system to some extent. Modifications
should be perfectly indexed and cross-referenced.
7. Verifiability: SRS is correct when the specified requirements can be verified
with a cost-effective system to check whether the final software meets those
requirements. The requirements are verified with the help of reviews.
8. Traceability: The SRS is traceable if the origin of each of the requirements is
clear and if it facilitates the referencing of each condition in future development
or enhancement documentation.

There are two types of Traceability:

1. Backward Traceability: This depends upon each requirement explicitly

referencing its source in earlier documents.

2. Forward Traceability: This depends upon each element in the SRS having
a unique name or reference number.
 The forward traceability of the SRS is especially crucial when the software
product enters the operation and maintenance phase. As code and design
document is modified, it is necessary to be able to ascertain the complete set of
requirements that may be concerned by those modifications.

9. Design Independence: There should be an option to select from multiple

design alternatives for the final system. More specifically, the SRS should not
contain any implementation details.
10. Testability: An SRS should be written in such a method that it is simple to
generate test cases and test plans from the report.
11. Understandable by the customer: An end user may be an expert in his/her
explicit domain but might not be trained in computer science. Hence, the
purpose of formal notations and symbols should be avoided too as much extent
as possible. The language should be kept simple and clear.
12. The right level of abstraction: If the SRS is written for the requirements stage,
the details should be explained explicitly. Whereas, for a feasibility study, fewer
analysis can be used. Hence, the level of abstraction modifies according to the
objective of the SRS.

Properties of a good SRS document

The essential properties of a good SRS document are the following:

Concise: The SRS report should be concise and at the same time, unambiguous,
consistent, and complete. Verbose and irrelevant descriptions decrease readability and
also increase error possibilities.

Structured: It should be well-structured. A well-structured document is simple to

understand and modify. In practice, the SRS document undergoes several revisions to
cope up with the user requirements. Often, user requirements evolve over a period of
time. Therefore, to make the modifications to the SRS document easy, it is vital to make
the report well-structured.

Black-box view: It should only define what the system should do and refrain from
stating how to do these. This means that the SRS document should define the external
behavior of the system and not discuss the implementation issues. The SRS report
should view the system to be developed as a black box and should define the externally
visible behavior of the system. For this reason, the SRS report is also known as the
black-box specification of a system.

Conceptual integrity: It should show conceptual integrity so that the reader can merely
understand it. Response to undesired events: It should characterize acceptable
responses to unwanted events. These are called system responses to exceptional
conditions.
 Verifiable: All requirements of the system, as documented in the SRS document,
should be correct. This means that it should be possible to decide whether or not
requirements have been met in an implementation.

• Background / Preparation:

Requirement engineering consists of seven different tasks as follows:

1. Inception

• Inception is a task where the requirement engineering asks a set of questions to

establish a software process.
• In this task, it understands the problem and evaluates with the proper solution.
• It collaborates with the relationship between the customer and the developer.
• The developer and customer decide the overall scope and the nature of the
question

2. Elicitation

Elicitation means to find the requirements from anybody.

The requirements are difficult because the following problems occur in
elicitation.
Problem of scope: The customer gives the unnecessary technical detail rather
than clarity of the overall system objective.
Problem of understanding: Poor understanding between the customer and the
developer regarding various aspect of the project like capability, limitation of
the computing environment.
Problem of volatility: In this problem, the requirements change from time to
time and it is difficult while developing the project
3. Elaboration

In this task, the information taken from user during inception and elaboration
and are expanded and refined in elaboration.

Its main task is developing pure model of software using functions, feature and
constraints of a software.

4. Negotiation

In negotiation task, a software engineer decides the how will the project be
achieved with limited business resources.

To create rough guesses of development and access the impact of the

requirements on the project cost and delivery time.
 5. Specification

In this task, the requirement engineer constructs a final work product.

The work product is in the form of software requirement specification.

In this task, formalize the requirement of the proposed software such as

informative, functional and behavioral.

The requirements are formalize in both graphical and textual formats.

6. Validation

The work product is built as an output of the requirement engineering and that
is accessed for the quality through a validation step.

The formal technical reviews from the software engineer, customer and other
stakeholders helps for the primary requirements validation mechanism.

7. Requirement management

It is a set of activities that help the project team to identify, control and track the
requirements and changes can be made to the requirements at any time of the
ongoing project.

These tasks start with the identification and assign a unique identifier to each of
the requirements.

After finalizing the requirement traceability table is developed.

• In order to form a good SRS, here you will see some points which can be used and
should be considered to form a structure of good SRS. These are as follows :
1. Introduction
▪ (i) Purpose of this document
▪ (ii) Scope of this document
▪ (iii) Overview
2. General description
3. Functional Requirements
4. Interface Requirements
5. Performance Requirements
6. Design Constraints
7. Non-Functional Attributes
8. Preliminary Schedule and Budget
9. Appendices
• Tools / Material Needed:
1. Hardware: Development Workstations:
• CPU: Intel Core i5 or AMD Ryzen 5 (or higher)
• RAM: 8 GB (minimum), 16 GB (recommended)
• Storage: 256 GB SSD (minimum), for fast access to development tools and
files
• Network: Stable internet connection for accessing repositories and remote
servers
2. Server Hardware:
• CPU: Multi-core processor (Intel Xeon or AMD EPYC)
• RAM: 16 GB to 32 GB (depending on user load)
• Storage: SSD or NVMe with 1 TB (to store application files and logs)
• Network: High-speed internet connection with redundancy options

o Software :
3. Development Tools:
• Integrated Development Environment (IDE): VS Code, JetBrains, or Sublime
Text
• Version Control: Git and GitHub/GitLab/Bitbucket for managing source code
• Frontend Framework: React.js, Vue.js, or Angular
• Backend Framework: Node.js (Express), Django, or Ruby on Rails
• Database Management System (DBMS): MySQL, PostgreSQL, or MongoDB
• Testing Tools: Jest, Mocha, Selenium for automated testing
• Package Managers: npm (Node.js), pip (Python)
4. Production Environment:
• Web Server: Apache, Nginx, or Microsoft IIS
• Database Server: MySQL or PostgreSQL
• Operating System: Linux (Ubuntu, CentOS) or Windows Server for server
hosting

• Software Requirement Specification (SRS) Format as name suggests, is complete

specification and description of requirements of software that needs to be fulfilled for
successful development of software system. These requirements can be functional as
well as non-functional depending upon type of requirement. The interaction between
different customers and contractor is done because its necessary to fully understand
needs of customers.
 • Given below is SRS for Collabe HUB:
INTRODUCTION

Purpose
Collab Hub is designed to connect students with other students and faculty by offering
a centralized platform for discovering, organizing, and participating in large-scale events like
hackathons. It helps users stay informed about ongoing campus activities while enabling team
collaboration, individual or team registration, and providing seamless communication
through Q&A sections and event notifications.

Scope
Collab Hub is a centralized platform where faculty members can post event
information, and students can discover, register, and interact with these events. It supports
individual or team registration and includes a Q&A section for inquiries. The platform serves
users from various institutions, enhancing event visibility and participation while providing
seamless communication through notifications and collaboration features.

Overview
Collab Hub is a web platform connecting students and faculty by enabling event
discovery, registration, and collaboration. Faculty can post event details, while students can
register individually or in teams. The platform includes a Q&A section and provides
notifications for event updates

General description :
Collab Hub is a web-based platform designed to streamline event organization and
participation across universities and colleges. It enables faculty to post event details such as
hackathons, seminars, and workshops, and allows students to browse, search, and register for
these events. Students can register individually or as teams, and faculty can manage participant
registrations. Additionally, the platform provides a Q&A section for event-related queries and
sends notifications to keep users updated. It supports user roles like students, faculty, and
administrators, ensuring smooth coordination and communication across campuses

Functional Requirements:
➢ Student Functionalities:
• Event Discovery: Students can browse, search, and filter events based on criteria such
as date, event type, and location.
• Event Registration: Students can register for events individually or in teams.
Registration details are tracked in the user's profile.
 • Q&A Section: Students can post questions related to events and respond to queries in
the Q&A section.
• Notifications: Students receive notifications about event updates, including registration
confirmation, event changes, and cancellations.
• Profile Management: Students can manage and update their personal information,
including username, email, and academic details.
• Team Formation: Students can form or join teams for collaborative events like
hackathons.

➢ Faculty Functionalities:
• Event Creation: Faculty members can post event details, including title, description,
date, location, and registration options.
• Manage Event Registrations: Faculty can track and manage student registrations,
approve or deny participation, and communicate with participants.
• Edit/Delete Events: Faculty members can modify or remove events they have created.

➢ Administrator Functionalities:
• User Management: Administrators can manage user accounts, roles, and permissions,
including adding or removing users.
• System Monitoring: Administrators oversee platform performance, manage database
operations, and ensure event accuracy.
• Event Moderation: Admins approve and moderate event listings to ensure content
quality and relevance

Interface Requirements:
➢ User Interface (UI):
• Login/Sign Up Pages: Simple and intuitive login and registration pages for students,
faculty, and administrators with options for password recovery.
• Event Discovery Page: A user-friendly interface displaying events in a list or calendar
view with search and filter options based on event type, date, and location.
• Event Registration Page: A clear registration form for individual or team-based event
participation, displaying registration status and event details.
• Q&A Section: An easy-to-navigate interface where users can ask and answer questions,
categorized by event or topic.
• Profile Management: An interface that allows users to update their personal information
and track their registered events.
• Notification System: In-app notifications or emails to inform users about event updates,
registration status, or event cancellations.
➢ Hardware Interfaces:
• Server Requirements:
o Multi-core CPU with at least 16 GB RAM and SSD storage for handling user
requests, event data, and registrations.
 o High-speed network connection to ensure smooth user experience and real-time
updates.
• Client-Side Hardware:
o Students and faculty should have devices with a modern processor (e.g., Intel i3
or equivalent), 4 GB RAM, and sufficient storage to handle the web application
in standard browsers.
➢ Software Interfaces:
• Web Browsers: Supports modern web browsers like Google Chrome, Mozilla Firefox,
Safari, and Microsoft Edge, with compatibility for the latest versions.
• Operating Systems: Compatibility with Windows, macOS, Linux, iOS, and Android for
a responsive, cross-platform user experience.
• Database Management: Interfaces with relational databases like MySQL or
PostgreSQL for storing and managing event and user data.
➢ Communication Interfaces:
• HTTP/HTTPS Protocols: Secure communication using HTTPS to ensure data integrity
and privacy during transactions.
• Email/Push Notifications: Integration with email systems to notify users about
important updates, reminders, or event-related messages

Performance Requirements:
➢ Page Load Time:
• Pages should load within 3 seconds for 90% of users on standard broadband
connections to ensure a smooth user experience.
➢ Response Time for User Actions:
• User interactions such as form submissions (e.g., event registration) and page
navigation should complete within 2 seconds under typical load conditions.
➢ Concurrent Users:
• The platform must support up to 10,000 concurrent users without significant
performance degradation or slowing down.
➢ Database Query Performance:
• Queries for common operations like searching for events, updating profiles, and
viewing event registrations should execute within 1 second.
➢ System Throughput:
• The system should handle at least 500 transactions per minute, including actions like
event registration and feedback submission.
➢ Load Testing:
• The platform should manage up to 20,000 virtual users performing standard activities
simultaneously while maintaining performance benchmarks.
➢ Latency:
• The client-server interactions should maintain a latency of less than 100 milliseconds
for smooth communication.
Design Constraints:
• Browser Compatibility: Must function across modern browsers (Chrome, Firefox,
Safari, Edge) and their versions.
• Internet Dependency: Requires a stable internet connection; offline functionality not
supported.
• Database Constraints: Needs to manage large volumes of data with efficient query
management for concurrent access.
• Scalability: Designed to scale with increasing users and events without service
disruption.
• Mobile Responsiveness: Optimized for mobile devices, ensuring smooth functionality
on various screen sizes.
• Security Standards: Adhere to security best practices (HTTPS, strong authentication)
while managing performance overhead.
• Accessibility: Comply with WCAG standards for usability by individuals with
disabilities, affecting design choices.
• Data Privacy: Ensure compliance with regulations (e.g., GDPR) for secure handling of
personal information

Non-Functional Attributes:
• Performance:
Supports high concurrency with fast response times; optimized database queries.
• Scalability:
Easily accommodates growth in users and events without performance loss.
• Reliability:
High availability and minimal downtime; robust backup and accurate information
delivery.
• Security:
Strong data protection measures; compliance with data privacy regulations (e.g.,
GDPR).
• Usability:
Intuitive UI for all users; accessible help resources for navigation.
• Accessibility:
Compliance with WCAG standards for users with disabilities; inclusive design.
• Interoperability:
Compatible with modern web browsers; potential integration with educational tools.
• Maintainability:
Well-documented codebase for easy updates; robust testing framework.
• Data Integrity:
Ensures accurate data management; regular audits to prevent loss or corruption.
• Response Time:
Aims for quick load times (under 3 seconds); timely notifications for users.
Appendices:
Appendix : Glossary of Terms

• UI/UX: User Interface/User Experience, focusing on the design and usability of the
platform.
• Concurrent Users: Users accessing the platform simultaneously.
• GDPR: General Data Protection Regulation, a data privacy law in the EU.
• WCAG: Web Content Accessibility Guidelines, standards for web accessibility.

Quiz:
1. Which are properties of good SRS?
ANS: A good Software Requirements Specification (SRS) document is clear, complete, and
consistent. It should be testable, traceable, and feasible, with a defined process for change
control. Visual aids can enhance understanding, and formal approval is essential.

2. What is functional and non-functional requirement?

ANS: Functional requirements define the specific functions and behaviors of a system, while
non-functional requirements specify system attributes like performance, security, and usability.

3. are different requirement engineering tasks?

ANS: Requirement engineering tasks include elicitation (gathering requirements), analysis,
specification, validation, and management. These activities ensure that the system meets its
intended purpose, aligning with stakeholder needs and expectations.

Suggested Reference:
1. Lecture on "System Analysis and Design", NPTEL
2. When Telepathy Won’t Do: Requirements Engineering Key Practices
3. Requirements Analysis: Process of requirements gathering and requirement definition
4. IEEE Recommended Practice for Software Requirements Specifications
5. Requirements Trace-ability and Use Cases
 Rubric wise marks obtained:
Rubrics 1 2 3 4 5 Total
Marks Complete Complete Complete Complete Complete
implementation implementation implementation implementation implementation
as asked as asked as asked as asked as asked
Problem Problem Problem Problem
analysis analysis analysis analysis
Development Development Development
of the Solution of the Solution of the Solution
Concept Concept
Clarity & Clarity &
understanding understanding
Correct answer
to all questions

Signature of Faculty: