Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Requirement specification (SRS)

•Download as PPT, PDF•
•

This document provides an overview of a requirements specification (SRS) for a software engineering project. It defines what an SRS is, its purpose, types of requirements it should include, its typical structure, characteristics of a good SRS, and benefits of developing an SRS. The SRS is intended to clearly define the requirements for a software product to guide its design and development.

1 of 16
Requirement Specification(SRS) • Name: Kunj Desai • Enrollment: 140950107022 • Branch: CSE–A • Semester: 6th • Year:2017
What is an SRS? • SRS is the official statement of what the system developers should implement. • SRS is a complete description of the behavior of the system to be developed. • SRS should include both a definition of user requirements and a specification of the system requirements. • The SRS fully describes what the software will do and how it will be expected to perform.
What is the purpose of an SRS? • The SRS precisely defines the software product that will be built. • SRS used to know all the requirements for the software development and thus that will help in designing the software. • It provides feedback to the customer. For example : communication between the Customer, Analyst, system developers, maintainers, ... contract between Purchaser and Supplier firm foundation for the design phase support system testing activities support project management and control controlling the evolution of the system
Users of a Requirements Document
Types of Requirements • Functional requirements: It will describe about the inputs and outputs of the designed system. • Non functional requirements: It will describe about how the system should work under certain circumstances. It is more specific then functional requirements. – Performance requirements – Interface requirements – Design constraints – Other requirements
Other Requirements • Security • Safety • Environmental • Reusability • Training
What is not included in an SRS ? Project requirements o cost, delivery schedules, staffing, reporting procedures Design solutions o partitioning of SW into modules, choosing data structures Product assurance plans o Quality Assurance procedures, Configuration Management procedures, Verification & Validation procedures
Structure of The Requirements Document • A number of large organizations, such as the US Department of Defense and the IEEE, have defined standards for requirements documents. • The most widely known standard is IEEE/ANSI 830-1998 (IEEE, 1998). • This IEEE standard suggests the following structure for requirements documents:
Requirement specification (SRS)
1.INTRODUCTION  Purpose  Describe the purpose of the SRS, not the purpose of the software being developed.  Intended audience for SRS.  Scope  Describe application of software (benefits, objectives).  Explain what software will (not) do.  Definitions/acronyms/abbreviations  Definitions of terms and abbreviations that are used in the SRS. E.g. User: The person operating and/or using the software system.  References  A complete list of all documents referenced elsewhere in the SRS.  Specify the sources from which the references can be obtained.  Overview  Brief description of rest of SRS.  How the SRS is organized
2.OVERALL DESCRIPTION  Product Perspective  If the product is independent and totally self-contained, it should be stated here.  Describe the functions of each component of the larger system or project, and identify interfaces.  Product Functions  Provide a summary of the functions that the software will perform.  Block diagrams showing the different functions and their relationships can be helpful.  User Characteristics  Describe those general characteristics of the eventual users of the product that will affect the specific requirements.  Constraints  Provide a general description of any other items that will limit the developer's options for designing the system. E.g. 1. The software system will run under Windows. 2. All code shall be written in Java.
2.OVERALL DESCRIPTION – Assumptions and Dependencies  List and description of each of the factors that affect the requirements stated in the SRS.  Apportioning Of Requirements  Identify requirements that may be delayed until future versions of the system.
Specification Principles • Separate functionality from implementation • Develop model of desired behavior of the system • Establish the context in which s/w operates • Define the environment in which system operates • Create a cognitive model • Specifications must be tolerant of incompleteness & augmentable • Content & structure of a specifications should be amenable to change
Characteristics of a good SRS • Correct : Every requirement given in SRS is a requirement of the software. • Unambiguous: Every requirement has exactly one interpretation. • Complete: Includes all functional, performance, design, external interface requirements; definition of the response of the software to all inputs. • Consistent: Internal consistency. • Ranked importance: Essential vs. desirable. • Verifiable: A requirement is verifiable if and only if there exists some finite cost effective process with which a person or machine can check that the SW meets the requirement. • Modifiable: SRS must be structured to permit effective modifications (e.g. don’t be redundant, keep requirements separate) • Traceable: Origin of each requirement is clear.
Benefits of SRS • Forces the users to consider their specific requirements carefully • Enhances communication between the Purchaser and System developers • Provides a firm foundation for the system design phase • Enables planning of validation, verification, and acceptance procedures • Enables project planning e.g. estimates of cost and time, resource scheduling • Usable during maintenance phase
SRS Review • Formal Review done by Users, Developers, Managers, Operations personnel • To verify that SRS confirms to the actual user requirements • To detect defects early and correct them. • Review typically done using checklists.

More Related Content

Requirement specification (SRS)

  • 1. Requirement Specification(SRS) • Name: Kunj Desai • Enrollment: 140950107022 • Branch: CSE–A • Semester: 6th • Year:2017
  • 2. What is an SRS? • SRS is the official statement of what the system developers should implement. • SRS is a complete description of the behavior of the system to be developed. • SRS should include both a definition of user requirements and a specification of the system requirements. • The SRS fully describes what the software will do and how it will be expected to perform.
  • 3. What is the purpose of an SRS? • The SRS precisely defines the software product that will be built. • SRS used to know all the requirements for the software development and thus that will help in designing the software. • It provides feedback to the customer. For example : communication between the Customer, Analyst, system developers, maintainers, ... contract between Purchaser and Supplier firm foundation for the design phase support system testing activities support project management and control controlling the evolution of the system
  • 4. Users of a Requirements Document
  • 5. Types of Requirements • Functional requirements: It will describe about the inputs and outputs of the designed system. • Non functional requirements: It will describe about how the system should work under certain circumstances. It is more specific then functional requirements. – Performance requirements – Interface requirements – Design constraints – Other requirements
  • 6. Other Requirements • Security • Safety • Environmental • Reusability • Training
  • 7. What is not included in an SRS ? Project requirements o cost, delivery schedules, staffing, reporting procedures Design solutions o partitioning of SW into modules, choosing data structures Product assurance plans o Quality Assurance procedures, Configuration Management procedures, Verification & Validation procedures
  • 8. Structure of The Requirements Document • A number of large organizations, such as the US Department of Defense and the IEEE, have defined standards for requirements documents. • The most widely known standard is IEEE/ANSI 830-1998 (IEEE, 1998). • This IEEE standard suggests the following structure for requirements documents:
  • 10. 1.INTRODUCTION  Purpose  Describe the purpose of the SRS, not the purpose of the software being developed.  Intended audience for SRS.  Scope  Describe application of software (benefits, objectives).  Explain what software will (not) do.  Definitions/acronyms/abbreviations  Definitions of terms and abbreviations that are used in the SRS. E.g. User: The person operating and/or using the software system.  References  A complete list of all documents referenced elsewhere in the SRS.  Specify the sources from which the references can be obtained.  Overview  Brief description of rest of SRS.  How the SRS is organized
  • 11. 2.OVERALL DESCRIPTION  Product Perspective  If the product is independent and totally self-contained, it should be stated here.  Describe the functions of each component of the larger system or project, and identify interfaces.  Product Functions  Provide a summary of the functions that the software will perform.  Block diagrams showing the different functions and their relationships can be helpful.  User Characteristics  Describe those general characteristics of the eventual users of the product that will affect the specific requirements.  Constraints  Provide a general description of any other items that will limit the developer's options for designing the system. E.g. 1. The software system will run under Windows. 2. All code shall be written in Java.
  • 12. 2.OVERALL DESCRIPTION – Assumptions and Dependencies  List and description of each of the factors that affect the requirements stated in the SRS.  Apportioning Of Requirements  Identify requirements that may be delayed until future versions of the system.
  • 13. Specification Principles • Separate functionality from implementation • Develop model of desired behavior of the system • Establish the context in which s/w operates • Define the environment in which system operates • Create a cognitive model • Specifications must be tolerant of incompleteness & augmentable • Content & structure of a specifications should be amenable to change
  • 14. Characteristics of a good SRS • Correct : Every requirement given in SRS is a requirement of the software. • Unambiguous: Every requirement has exactly one interpretation. • Complete: Includes all functional, performance, design, external interface requirements; definition of the response of the software to all inputs. • Consistent: Internal consistency. • Ranked importance: Essential vs. desirable. • Verifiable: A requirement is verifiable if and only if there exists some finite cost effective process with which a person or machine can check that the SW meets the requirement. • Modifiable: SRS must be structured to permit effective modifications (e.g. don’t be redundant, keep requirements separate) • Traceable: Origin of each requirement is clear.
  • 15. Benefits of SRS • Forces the users to consider their specific requirements carefully • Enhances communication between the Purchaser and System developers • Provides a firm foundation for the system design phase • Enables planning of validation, verification, and acceptance procedures • Enables project planning e.g. estimates of cost and time, resource scheduling • Usable during maintenance phase
  • 16. SRS Review • Formal Review done by Users, Developers, Managers, Operations personnel • To verify that SRS confirms to the actual user requirements • To detect defects early and correct them. • Review typically done using checklists.