Software Requirements Specification. Gather Software Requirements.
What are the advantages of a software requirements specification? What is it for and how is it created?
In a software requirements specification, the customer forms the desired requirements for the system under development without getting into the technical implementation.
There are no regulations for the structure and content of the software requirements specification. Generally, at least three chapters are needed: An introduction, a product description and a description of the requirements.
What Is a Software Requirements Specification?
A software requirements specification is a document that describes requirements for a software product, program or set of programs. Requirements in the software requirements specification are expressed in normal language and are not concerned with technical implementation. That’s what the design documents are for. In software development, the software requirements specification represents the results of the requirements analysis and describes the requirements of the software under development. Though it is traditionally created as a document, it can also be created in different forms, for example – a very simple one – in spoken form.
Advantages of a Software Requirements Specification
Software requirements specifications are a method of clearer communication: Correctly formed, they provide a comprehensible description of the customer and their desires. This way you start with an abstract idea of the specific professional domain where the customer is active. Improvements later in the project that delay completion or cause more expenses can be avoided. Apart from this, important framework for development can be specified which creates a clear picture of the goal and (contractual) obligations that you can include over the course of the project.
ISO/IEC/IEEE 29148:2011 definition of a software requirements specification:
A software requirements specification is a “structured collection of the requirements (functions, performance, design constraints, and attributes) of the software and its external interfaces”.
Difference between a Software Requirements Specification and a System Requirements Specification
The IEEE standard makes a distinction between those two documents.
Features of a Software Requirements Specification (SRS)
- Defines requirements for a software product, program or set of programs
- Usually 1 document for every program
- Does not decide on the architecture
Features of a System Requirements Specification (SysRS)
- Defines requirements for the whole system (hardware, software, mechanical)
- Usually 1 document
- Does not decide on the architecture
- Specifies performance
How Do You Create a Software Requirements Specification?
There are suggestions for the structure of the software requirements specification, but no strict rules. In international software development, the IEEE standard’s suggestion is frequently used. Adaptations to the document template are possible and even necessary.
How To Create a Specification Quickly and Easily.
Do the test. Requirements Engineering with objectiF RPM or objectiF RM »
Content and Structure of a Software Requirements Specification
The following structure corresponds to the IEEE 29148:2011 standard. This same structure is found frequently online with small changes, for example, on Wikipedia.
1. Introduction
- Purpose (Document)
- Scope (Product)
- Product overview
- Product perspective (product’s relation to other products, for example, through block diagrams)
- Product features (summary of features that the product offers)
- User features (description of the product’s target group)
- Limitations (hardware, legal regulations)
- Definitions
2. References (List of documents referenced in the SRS)
3. Specific requirements
- External interfaces (product inputs and tasks)
- Features (features to be able to process inputs and tasks)
- Usability requirements
- Performance requirements
- Logical database requirements (Logical requirements for how information should be saved in the database, like information type)
- Design limitations
- Software system attributes (Reliability, availability, security, product maintenance)
- Supporting information (Example dates, description, which problems does the project solve)
4. Verification
- (Structured like “Specific requirements”)
5. Attachments
- Assumptions and dependencies (operating system)
- Abbreviations
Who Writes the Software Requirements Specification?
Traditionally, you should differentiate between the contractor and the customer in the software requirements specification. So the document is then the customer’s responsibility. For example, it might be an authority that has created a software requirements specification for a call for bids. Often the customer does not know exactly what they need at the beginning. Or their ideas are far too abstract to write down in the document. So it has generally proven useful to create the software requirements specification in cooperation with the contractor.
Requirements are the heart of the software requirements specification, so they should not just be slapped together. As implied in the structure, you should at least differentiate between functional and non-functional requirements in the software requirements specification document.
Document Requirements Correctly
Additionally, each requirement needs a unique acronym or an ID to be identifiable. The priority, connectivity or stability should be entered with the description.
Generally, more than just text is needed to record desired system features. Diagrams like requirement and use case diagrams are also used to visualize the relationships to other elements like test cases or block diagrams. These work results should be recorded in the software requirements specification so to increase the understanding of the context. Because you are working with a range of different elements, using a tool for requirements engineering and requirements management is very helpful. That way you can generate software requirements specification documents from your project contents immediately.
Learn more about requirements engineering with a tool here »
Does the Software Requirements Specification Fit in with Agile Development?
Software requirements specifications are known from classical project management: There, you work in phases, create the entire document at the beginning of the project and develop a software product based on it. Sounds simple, but it has grave disadvantages: at the beginning of a project, all the requirements are not yet known, and these often result from existing system components or architecture. Apart from this, changes will occur throughout the project because, for instance, the goals of the customers or stakeholders are always changing.
Agile projects, on the other hand, proceed iteratively to determine requirements. That means that you process requirements in an interplay with development instead of creating detailed requirements specifications from the get-go. So is a software requirements specification useful for agile development?
Absolutely. Because an initial, documented plan creates security for your clients and contractors. The expected expenses and workload have to be estimated, so software requirements specifications also have a place in agile project management. The initial detail is transformed: First, you just specify the requirements for the first release in a software requirements specification, develop the first prototype of based on it and derive more requirements from this first prototype. The software requirements specification grows from release to release and changes over the course of the project, and always provides an explicit reference point in the case of misunderstandings or disagreements.
Knowledge to go
All about requirements and agile development with tool
How you create a software requirements specification with objectiF RM or objectiF RPM
objectiF RPM and objectiF RPM provide a Word template for the software requirements specification that you can use without any changes or adapt to your needs. To work with the default Word template, you just have to create a new document based on this template and generate the content with one click.
You want to adapt the template? No problem! You can edit the template’s layout directly in Word. For instance, you can define a new color scheme there or decide on a new structure for the content of individual chapters. To edit the structure of the whole document, you only need to drag and drop the individual chapters.
