What is an SRS?
By definition, an SRS is a deliverable that describes all data, functional and behavioral requirements, all constraints, and all validation requirements for software. An SRS is a documented understanding of the system requirements and dependencies as stated by the customer at that point in time. The artifact contains only functional and non-functional requirements - it does not offer design suggestions, possible technology solutions, or any information other than that which the development team will need to understand the customer's system requirements. The SRS is not a design document or a technical solution guide - those artifacts are generated based on the information available in the SRS.
An SRS may take the form of an actual document, or it can exist as a collection of requirements organized within a software requirements tools, such as Caliber, Doors, Requisite Pro, Mercury Quality Center. In general, all tools allow you to generate an SRS document should you desire to review the requirements in that format. Lastly, an SRS is a living document. Requirements may change over time, and the document or tool will need to be updated to reflect those changes.
Gathering information in a tool like those mentioned above allows test cases to be more easily tied directly to requirements, provides the ability to quickly change / update requirements without requiring the release of another document, and provides for easier reuse of requirements between projects.
What are the Goals of an SRS?
Provide feedback to the customer.
The SRS serves as a written verification that the IT organization understands the desires of the customer. Once the requirements have been captured in a tool or document, they should be shared with the customer so that the customer can help make corrections or modifications, and sign off on the requirements for the solution. The SRS is in essence an insurance policy that ensures the customer gets what they want, and that the development team has a clear understanding of the goals and expectation.
Separate the project into manageable parts
Requirements are hierarchical by nature, and as such provide insight into functionality and component separation, and provide guidelines into what the user expects as it relates to performance (how fast), load (how much), and usage times (how often). An SRS specifies all of these things in clear a concise language that makes it clear what the user expects and the potential relationships between those expectations.
Serves as input to the design and technology specifications.
The SRS is not a design document or technology specification. However, due to the explicit and precise language that is required for an SRS, the development team gains the input that they need to specify the technical details of the project in other technical artifacts. If the requirements are not clear and concise, the customer will generally not get what they expect and rework will ensue. Anything that is not explicitly stated will more than likely not be accounted for in design or development.
Serves as a way to check the accuracy and quality of the project
Every design artifact, component, configuration change, and test case should map to a requirement or collection of requirements. As such, the test cases can be used to confirm or deny that the customer's exact requirements have been met prior to entering production.
What information is included in an SRS?
The following serves as a guideline of the types of information that should be contained in an SRS. Every individual requirement should receive a unique SRS ID number (requirements tools will generate this for you). It is important to know that each of these written requirements may be augmented by generating Use Cases which help to visually describe and flesh out a requirement or collection of requirements. Use cases may be generated in any number of tools, including Visio and either pasted as an attachment to a requirement within Mercury or pasted into an SRS document (if one is generated by hand).
- Interfaces
- GUI Interfaces
- APIs
- Integrations
*Menu Systems
* Communications Interfaces (does it work with the phone system, fax?)
- Functional Capabilities
- What does the product do?
- Does it depend on other requirements?
- Does it interact with other requirements?
- Performance Levels
- Acceptable response time
- Load requirements
- Safety
- Does this product have any safety considerations?
- Reliability
- SLA
- Does it require DR?
- What is the impact if the system is down?
- Security/Privacy
- Who can use the product?
- What roles are required?
- Who can have access to the data?
- Are there any project staff limitations?
- Quality
- Are there any quality criteria (one error allowed in X number of transactions) - This provides additional detail with regards to how thorough, or to what level, testing needs to be.
- Constraints and Limitations
- Standards compliance
- Cost limitations
- Use of existing assets
An SRS Template
When setting up a project in Mercury Quality Center or in creating an SRS document by hand, the following represents a template that may be used:
| 1. Introduction |
| 1.1 Purpose |
| 1.2 Document conventions |
| 1.3 Intended audience |
| 1.4 Additional information |
| 1.5 Contact information/SRS team members |
| 1.6 References |
| 2. Overall Description |
| 2.1 Product perspective |
| 2.2 Product functions |
| 2.3 User classes and characteristics |
| 2.4 Operating environment |
| 2.5 User environment |
| 2.6 Design/implementation constraints |
| 2.7 Assumptions and dependencies |
| 3. External Interface Requirements |
| 3.1 User interfaces |
| 3.2 Hardware interfaces |
| 3.3 Software interfaces |
| 3.4 Communication protocols and interfaces |
| 4. System Features |
| 4.1 System feature A |
| 4.1.1 Description and priority |
| 4.1.2 Action/result |
| 4.1.3 Functional requirements |
| 4.2 System feature B |
| 5. Other Nonfunctional Requirements |
| 5.1 Performance requirements |
| 5.2 Safety requirements |
| 5.3 Security requirements |
| 5.4 Software quality attributes |
| 5.5 Project documentation |
| 5.6 User documentation |
SRS Review Checklist
| Question | Yes | No |
|---|---|---|
| Does the SRS provide a brief overview of the product defined by this process? | ||
| Does the SRS provide an overview of the business organization? | ||
| Does the SRS describe the general product functionality? | ||
| Does the SRS describe the relationship of this product with other products? | ||
| Does the SRS describe the users? | ||
| Does the SRS provide detailed performance goals? | ||
| Does the SRS provide detailed load expectations? | ||
| Does the SRS describe the functional requirements explicitly and in enough detail to understand the requirement fully? | ||
| If not, provide details on which requirements do not meet this criteria | ||
| Does the SRS provide a requirement prioritization? | ||
| Does the SRS adequately describe the required GUIs|? | ||
| Does the SRS adequately describe required APIs? | ||
| Does the SRS adequately describe menus and menu items? | ||
| Does the SRS adequately describe required integrations? | ||
| Does the SRS adequately describe required communication interfaces? | ||
| Does SRS specify any non-functional attributes? | ||
| Does the SRS discuss security issues? | ||
| Does the SRS discuss reliability issues? | ||
When does an SRS / Requirements Review Happen, and Who is Involved?
A requirements review occurs at least once in a project, and every time that requirements change after the initial review (change management). This means that if the project is broken into iterations, a requirements review will occur during every iteration through the life of the project.
The Requirements Review will include customers or a customer representative, the IT team responsible for delivering the project, Infrastructure, Architecture, DBAs, DB Architects, and Subject Matter Experts.
The rules and roles are the same for this review as for every other type of review.
