What does SRS stand for requirements?
|
Show
Before we begin you must know – The difference between a Requirement and a Specification
There are a plethora of terms and terminology for various documents Specification Documents like –
Requirement Documents like –
Points To Ponder
In this tutorial we will discuss the Difference between BRS and SRS in software testing:  Difference between SRS and BRS
What is a System Requirements Specification (SRS)?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 ElementsDepending 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 DriversThis 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 ModelThis 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 RequirementsThis 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 CasesThis 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 RequirementsThis 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 QualitiesThis 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 AssumptionsThis 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 CriteriaThis 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. AlternativesIn agile methodologies such as extreme programming or scrum formal, static documentation such as a software requirements specification (SRS) are usually eschewed in favor of a more lightweight documentation of the requirements, namely by means of user stories and acceptance tests. This approach requires that the customer is easily accessible to provide clarification on the requirements during development and also assumes that the team members responsible for writing the user stories with the customer will be the developers building the system. A more formal approach may be needed if the customer is inaccessible and/or a separate team of business analysts will be developing the requirements. In Rapid Application Development (RAD) methodologies such as DSDM or Unified Process (RUP, AUP) the requirements specification is often kept at a higher-level with much of the detailed requirements embodied in prototypes and mockups of the planned system. These prototypes are a more visual way to represent the requirements and help the customer more easily comprehend what is planned (and therefore provide more timely feedback). How do you write requirements in SRS?How to Write a Software Requirement Specification Document. Create an Outline. The first step in the process is to create an outline for SRS document. ... . Define the Purpose. ... . Give an Overview. ... . Describe Functional and Non-functional Requirements. ... . Add Supplemental Details. ... . Get Approval. ... . Explicit. ... . Measurable.. What is SRS explain with example?A Software Requirements Specification (SRS) is a document that describes the nature of a project, software or application. In simple words, SRS document is a manual of a project provided it is prepared before you kick-start a project/application.
...
1.2 DOCUMENT CONVENTIONS.. What is performance requirements in SRS?Performance requirements define how well the software system accomplishes certain functions under specific conditions. Examples include the software's speed of response, throughput, execution time, and storage capacity. The service levels comprising performance requirements are often based on supporting end-user tasks.
Who will prepare SRS document?The SRS document is created by a team of System Analysts (SA), a technical expert. 8. It defines, at a very high level, which includes the functional conditions of the application. It specifies at a high level where the functional and technical requirements of the application are included.
|
