rnbhushan

 Profile Answers by rnbhushan 

• Jan 10th, 2007

 

 

BRS: BRS contains the basic requirements of customer that are to be developed as software, project cost, schedule, target dates.

 

SRS: SRS is implemented form of BRS. SRS is often referred as parent document of project  management document such as design specifications,statmnets of works ,software architecture specifications, testing and validation plans and documentation plans.The basic issues of SRS is what is the functionality(what is the s/w supposed to do)what are the external interfaces (how does the software interact with the user, other hardware, and other system software)performance(What is the speed of application ,recovery time ,response time, availability of various software functions)attributes(what is the portability, security, correctness etc )design constraints (OS environments.implemnation of languages, database integrity and resource limits)

 

SRS contains the functional and non functional requirements only.

 

FRS: FRS document provides the more detailed and described form of SRS.It contains the technical information and data needed to design the application. FRS define the what are software functionality will be and how to implement

Sly Gryphon

• May 17th, 2007

 

The term Software Requirements Specification (SRS) can be given a very exact and well defined meaning -- that of a document as outlined in IEEE Standard 830.

A standard SRS addresses functionality, interfaces (user, hardware and other systems), performance, other attributes (e.g. portability, security) and any design constraints (e.g. particular language or platform). [Section 4.1]

A standard SRS should not go beyond specifying requirements, in particular it should not include any design or implementation details, e.g. specific screen design, although the user interface section may include logical formats or layouts. [Section 4.2]

A good SRS should have the characteristics of: correct, unambiguous, complete, consistent, ranked for importance, verifiable, modifiable, traceable. [Section 4.3]

An SRS should be jointly prepared by the customer and supplier (of the software). [Section 4.4]

The SRS should only contain product requirements, not project requirements, i.e. it should not contain costs, schedules, development methods, acceptance procedures, etc. [Section 4.8]

In contrast the terms functional requirement/functional specification are defined in the IEEE Sandard 610.12 Glossary. As defined in the standard functional requirements are only one subset of the overall requirements, i.e. a functional specification often simply refers to one part of the requirements specification (SRS).

I don't think business requirements specification is a defined standard term, but from the descriptions is probably similar to the official meaning of SRS.

In practice, many people use different terms to mean many different things, but if you want an official definition of SRS I suggest sticking with the description in IEEE Standard 830.

kurtz182

 Profile Answers by kurtz182 Questions by kurtz182

• Dec 9th, 2009

 

A Business Requirements Document (BRD) describes what the required business achievements should be and means to measure the quality of those achievements. It typcially expresses the broad outcomes the business requires rather than specific functions the system may perform.  Specific design elements are usually outside the scope of this document.

A Functional Specification Document (FSD) in software development is the documentation that describes the requested behavior of an engineering system. The documentation typically describes what is needed by the system user as well as requested properties of inputs and outputs.

A Software Requirements Specification (SRS) is a description of an organization's understanding of customers or a potential client's system requirements and dependencies. It's initial purpose is to ensure that the provider understands the customers' or client's requirements prior to any actual design or development.  The SRS states in precise and explicit language all functions and capabilities as well as the constraints by which the software system must abide.  It functions as a blueprint for completing a project with as little cost growth as possible.  It is often referred to as the "parent" document because all subsequent project-related documents such as design specifications, statements of work, software architecture specifications, testing and validation plans are derived from it.