Class/Section:BSCS-6

 Is there any difference between "system requirments

specification" and  "software requirment specification" if any
describe in detail..  Is there any difference between "system
requirments specification" and  "software requirment
specification" if any describe in detail.
Difference between software requirement specification and system
requirement specification:
A software requirements specification (SRS) includes in-depth descriptions of the software that
will be developed.

A system requirements specification (SRS) collects information on the requirements for a

system.

“Software” and “system” are sometimes used interchangeably as SRS. But, a software
requirement specification provides greater detail than a system requirements specification.

Software Requirement specification

A software requirements specification (SRS) is a comprehensive description of the intended
purpose and environment for software under development. The SRS fully describes what the
software will do and how it will be expected to perform.

An SRS minimizes the time and effort required by developers to achieve desired goals and also
minimizes the development cost. A good SRS defines how an application will interact with
system hardware, other programs and human users in a wide variety of real-world situations.
Parameters such as operating speed, response time, availability, portability,
maintainability, footprint, security and speed of recovery from adverse events are evaluated.
Methods of defining an SRS are described by the IEEE (Institute of Electrical and Electronics
Engineers) specification 830-1998.

A software requirements specification (SRS) is a document that describes what the software will
do and how it will be expected to perform. It also describes the functionality the product needs
to fulfill all stakeholders (business, users) needs.

A typical SRS includes:

 A purpose
 An overall description
 Specific requirements
The best SRS documents define how the software will interact when embedded in hardware
— or when connected to other software. Good SRS documents also account for real-life users.

System Requirements Specification:

A System Requirements Specification (SRS) (also known as a Software Requirements

Specification) is a document or set of documentation that describes the features and behavior
of a system or software application. It includes a variety of elements (see below) that attempts
to define the intended functionality required by the customer to satisfy their different users.
In addition to specifying how the system should behave, the specification also defines at a high-
level the main business processes that will be supported, what simplifying assumptions have
been made and what key performance parameters will need to be met by the system.

Main Elements:
Depending on the methodology employed (agile vs waterfall) the level of formality and detail in
the SRS will vary, but in general an SRS should include a description of the functional
requirements, system requirements, technical requirements, constraints, assumptions and
acceptance criteria. Each of these is described in more detail below:

 Business Drivers

 Business Model

 Functional and System Requirements

 Business and System Use Cases

 Technical Requirements

 System Qualities

 Constraints and Assumptions

 Acceptance Criteria

Business Drivers
This section describes the reasons why the customer is looking to build the system. The
rationale for the new system is important as it will guide the decisions made by the business
analysts, system architects and developers. Another compelling reason for documenting the
business rationale behind the system is that the customer may change personnel during the
project. Documentation which clearly identifies the business reasons for the system will help
sustain support for a project if the original sponsor moves on.
The drivers may include both problems (reasons why the current systems/processes are not
sufficient) and opportunities (new business models that the system will make available).
Usually a combination of problems and opportunities are needed to provide motivation for a
new system.
Business Model
This section describes the underlying business model of the customer that the system will need
to support. This includes such items as the organizational context, current-state and future-
state diagrams, business context, key business functions and process flow diagrams. This
section is usually created during the functional analysis phase.
Functional and System Requirements
This section usually consists of a hierarchical organization of requirements, with the
business/functional requirements at the highest-level and the detailed system requirements
listed as their child items.
Generally, the requirements are written as statements such as "System needs the ability to do
x" with supporting detail and information included as necessary.
Business and System Use Cases
This section usually consists of a UML use case diagram that illustrates the main external
entities that will be interacting with the system together with the different use cases
(objectives) that they will need to carry out. For each use-case there will be formal definition of
the steps that need to be carried out to perform the business objective, together with any
necessary pre-conditions and post-conditions.
The business use cases are usually derived from the functional requirements and the system
use cases are usually derived from the system requirements.
The use cases steps can also be represented as a flowchart diagram:
Technical Requirements
This section is used to list any of the "non-functional" requirements that essentially embody the
technical environment that the product needs to operate in, and include the technical
constraints that it needs to operate under. These technical requirements are critical in
determining how the higher-level functional requirements will get decomposed into the more
specific system requirements.
System Qualities
This section is used to describe the "non-functional" requirements that define the "quality" of
the system. These items are often known as the "-ilities" because most of them end in "ility".
They included such items as: reliability, availability, serviceability, security, scalability,
maintainability.
Unlike the functional requirements (which are usually narrative in form), the system qualities
usually consist of tables of specific metrics that the system must meet to be accepted.
Constraints and Assumptions
This section will outline any design constraints that have been imposed on the design of the
system by the customer, thereby removing certain options from being considered by the
developers. Also, this section will contain any assumptions that have been made by the
requirements engineering team when gathering and analyzing the requirements. If any of the
assumptions are found to be false, the system requirements specification would need to be re-
evaluated to make sure that the documented requirements are still valid.
Acceptance Criteria
This section will describe the criteria by which the customer will "sign-off" on the final system.
Depending on the methodology, this may happen at the end of the testing and quality
assurance phase, or in an agile methodology, at the end of each iteration.
The criteria will usually refer to the need to complete all user acceptance tests and the
rectification of all defects/bugs that meet a pre-determined priority or severity threshold.

Enlist the basic purpose of SRS document, what to keep in mind while writing
the document.

Purpose of an SRS:

An SRS forms the basis of an organization’s entire project. It sets out the framework that all the
development teams will follow. It provides critical information to all the teams, including
development, operations, quality assurance (QA) and maintenance, ensuring the teams are in
agreement.

Using the SRS helps an enterprise confirm that the requirements are fulfilled and helps business
leaders make decisions about the lifecycle of their product, such as when to retire a feature. 
In addition, writing an SRS can help developers reduce the time and effort necessary to meet
their goals as well as save money on the cost of development.

If an SRS is written well, it will serve the following purposes:

Feedback to the Customer

The software requirement specification assures the project management stakeholders and
client that the development team has really understood the business requirements
documentation properly. This also provides confidence that the team will develop the
functionality which has been detailed.

Breaking the Requirements Down

The Software Requirement Specification is documented in such a way that it breaks the
deliverables into smaller components. The information is organized in such a way that the
developers will not only understand the boundaries within which they need to work, but also
what functionality needs to be developed and in what order.

These two points are particularly important in the process of software development. If your
development team do not understand that there are certain constraints on their work, as for
example the code must be tightly written so that it will compile and run quickly, then you will
run into problems later on when the code might deliver the functionality required, but no one
will ever see it because it takes so long to load!

Understanding what order the functionalityy will be developed in means that the developers
have the "big picture" view of the development. This gives them an opportunity to plan ahead
which saves both project time and cost.

Facilitating other Documentation

The SRS forms the basis for a load of other important documents such as the Software Design
Specification.

Product Validation
It basically helps in validating with the client that the product which is being delivered, meets
what they asked for.

what to keep in mind while writing the document

In today’s business world, you should apply proven ways to identify the client’s wants and
needs. Some techniques may be highly beneficial in one project but may not be as productive in
the other one or for some tech providers. Here we provide some vital requirement gathering
techniques you can utilize. Let’s take a closer look below:
 Brainstorming. Helps to identify all possible solutions to challenges. Any ideas are
welcomed, and all participants are encouraged to develop a rich array of creative solutions.
 Document Analysis. Applied to identify the requirements by analyzing the existing
documents - business plans, contractual agreements,logical data models, current process flows
before organizing or scheduling an interview with stakeholders.
 Interface Analysis. Includes the user interface, interfaces with external applications and
interfaces with external hardware devices to determine the boundaries and identify future
functionality/features.
 Interview. Utilized to communicate with persons engaged or subject matter experts to
gather requirements for the future project. The questions should be prepared beforehand or
asked spontaneously; responses should be recorded or written down as well.
 Prototyping. Applied to build an initial version of the solution that may not have all the
functionality but serves as a proof of concept for idea verification/further analysis.
 Mind Mapping. Represents ideas and their branches hierarchically, and helps to
visualize the relationship among all components of the system.
 Focus Group. Involves synergistic discussion among people who are representative of
the users or customers regarding to the functionality, features and other aspects of the
 product/system. You should collect feedback about opportunities, key features, needs, and so
on to define the requirements or to validate the already elicited ones.
 Requirements Workshop. Brings a larger group on a common platform to discuss and
reach agreements by defining cross-functional requirements for the future product/system in a
fast way.

Refrences:
https://searchsoftwarequality.techtarget.com/definition/software-requirements-specification

https://www.perforce.com/blog/alm/how-write-software-requirements-specification-srs-
document

https://www.inflectra.com/ideas/topic/requirements-definition.aspx

https://www.perforce.com/blog/alm/how-write-software-requirements-specification-srs-
document

https://ddi-dev.com/blog/programming/how-to-write-software-requirement-specification-for-
your-project/