- Software Requirements Template .doc
- Software Requirements Specification Template Excel
- Simple Software Requirements Template
What are Software Requirements Specifications?
- It provides feedback to the customer. An SRS is the customer’s assurance that the development organization understands the issues or problems to be solved and the software behavior necessary to address those problems. Therefore, the SRS should be written in natural language (versus a formal language, explained later in this article), in an unambiguous manner that may also include charts, tables, data flow diagrams, decision tables, and so on.
- It decomposes the problem into component parts. The simple act of writing down software requirements in a well-designed format organizes information, places borders around the problem, solidifies ideas, and helps break down the problem into its component parts in an orderly fashion.
- It serves as an input to the design specification. As mentioned previously, the SRS serves as the parent document to subsequent documents, such as the software design specification and statement of work. Therefore, the SRS must contain sufficient detail in the functional system requirements so that a design solution can be devised. It serves as a product validation check. The SRS also
- It serves as the parent document for testing and validation strategies that will be applied to the requirements for verification.
Why Should Technical Writers be Involved with Software Requirements Specifications?
- Technical writers are skilled information gatherers, ideal for eliciting and articulating customer requirements. The presence of a technical writer on the requirements-gathering team helps balance the type and amount of information extracted from customers, which can help improve the software requirements specifications.
- Technical writers can better assess and plan documentation projects and better meet customer document needs. Working on SRSs provides technical writers with an opportunity for learning about customer needs firsthand–early in the product development process.
- Technical writers know how to determine the questions that are of concern to the user or customer regarding ease of use and usability. Technical writers can then take that knowledge and apply it not only to the specification and documentation development, but also to user interface development, to help ensure the UI (User Interface) models the customer requirements.
- Technical writers, involved early and often in the process, can become an information resource throughout the process, rather than an information gatherer at the end of the process.
What Kind of Information Should an SRS Include?
- Interfaces
- Functional Capabilities
- Performance Levels
- Data Structures/Elements
- Safety
- Reliability
- Security/Privacy
- Quality
- Constraints and Limitations
- A template
- A method for identifying requirements and linking sources
- Business operation rules
- A traceability matrix
Begin with an SRS Template
provide sample templates and related information.)
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 6. Other Requirements Appendix A: Terminology/Glossary/Definitions list Appendix B: To be determined |
1. Scope | 1.1 Identification.Identify the system and the software to which this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).1.2 System overview.State the purpose of the system or subsystem to which this document applies.1.3 Document overview.Summarize the purpose and contents of this document.This document comprises six sections:
Describe any security or privacy considerations associated with its use. |
2. Referenced Documents | 2.1 Project documents. Identify the project management system documents here.2.2 Other documents.2.3 Precedence.2.4 Source of documents. |
3. Requirements | This section shall be divided into paragraphs to specify the Computer Software Configuration Item (CSCI) requirements, that is, those characteristics of the CSCI that are conditions for its acceptance. CSCI requirements are software requirements generated to satisfy the system requirements allocated to this CSCI. Each requirement shall be assigned a project-unique identifier to support testing and traceability and shall be stated in such a way that an objective test can be defined for it.3.1 Required states and modes.3.2 CSCI capability requirements.3.3 CSCI external interface requirements.3.4 CSCI internal interface requirements.3.5 CSCI internal data requirements.3.6 Adaptation requirements.3.7 Safety requirements.3.8 Security and privacy requirements.3.9 CSCI environment requirements.3.10 Computer resource requirements.3.11 Software quality factors.3.12 Design and implementation constraints.3.13 Personnel requirements. 3.14 Training-related requirements. 3.15 Logistics-related requirements. 3.16 Other requirements. 3.17 Packaging requirements. 3.18 Precedence and criticality requirements. |
4. Qualification Provisions | To be determined. |
5. Requirements Traceability | To be determined. |
6. Notes | This section contains information of a general or explanatory nature that may be helpful, but is not mandatory.6.1 Intended use. This Software Requirements specification shall…6.2 Definitions used in this document.Insert here an alphabetic list of definitions and their source if different from the declared sources specified in the “Documentation standard.”6.3 Abbreviations used in this document. Insert here an alphabetic list of the abbreviations and acronyms if not identified in the declared sources specified in the “Documentation Standard.”6.4 Changes from previous issue. Will be “not applicable” for the initial issue.Revisions shall identify the method used to identify changes from the previous issue. |
Identify and Link Requirements with Sources
helps assure project stakeholders that frivolous or spurious requirements are kept out of the specification.
ID No. | Paragraph No. | Requirement | Business Rule Source |
17 | 5.1.4.1 | Understand/communicate using SMTP protocol | IEEE STD xx-xxxx |
18 | 5.1.4.1 | Understand/communicate using POP protocol | IEEE STD xx-xxxx |
19 | 5.1.4.1 | Understand/communicate using IMAP protocol | IEEE STD xx-xxxx |
20 | 5.1.4.2 | Open at same rate as OE | Use Case Doc 4.5.4 |
Establish Business Rules for Contingencies and Responsibilities
Establish a Requirements Traceability Matrix
What Should I Know about Writing an SRS?
SRS Quality Characteristic | What It Means |
Complete | SRS defines precisely all the go-live situations that will be encountered and the system’s capability to successfully address them. |
Consistent | SRS capability functions and performance levels are compatible, and the required quality features (security, reliability, etc.) do not negate those capability functions. For example, the only electric hedge trimmer that is safe is one that is stored in a box and not connected to any electrical cords or outlets. |
Accurate | SRS precisely defines the system’s capability in a real-world environment, as well as how it interfaces and interacts with it. This aspect of requirements is a significant problem area for many SRSs. |
Modifiable | The logical, hierarchical structure of the SRS should facilitate any necessary modifications (grouping related issues together and separating them from unrelated issues makes the SRS easier to modify). |
Ranked | Individual requirements of an SRS are hierarchically arranged according to stability, security, perceived ease/difficulty of implementation, or other parameter that helps in the design of that and subsequent documents. |
Testable | An SRS must be stated in such a manner that unambiguous assessment criteria (pass/fail or some quantitative measure) can be derived from the SRS itself. |
Traceable | Each requirement in an SRS must be uniquely identified to a source (use case, government requirement, industry standard, etc.) |
Unambiguous | SRS must contain requirements statements that can be interpreted in one way only. This is another area that creates significant problems for SRS development because of the use of natural language. |
Valid | A valid SRS is one in which all parties and project participants can understand, analyze, accept, or approve it. This is one of the main reasons SRSs are written using natural language. |
Verifiable | A verifiable SRS is consistent from one level of abstraction to another. Most attributes of a specification are subjective and a conclusive assessment of quality requires a technical review by domain experts. Using indicators of strength and weakness provide some evidence that preferred attributes are or are not present. |
Imperatives: Words and phrases that command the presence of some feature, function, or deliverable. They are listed below in decreasing order of strength. | |||
Shall | Used to dictate the provision of a functional capability. | ||
Must or must not | Most often used to establish performance requirement or constraints. | ||
Is required to | Used as an imperative in SRS statements when written in passive voice. | ||
Are applicable | Used to include, by reference, standards, or other documentation as an addition to the requirement being specified. | ||
Responsible for | Used as an imperative in SRSs that are written for systems with pre-defined architectures. | ||
Will | Used to cite things that the operational or development environment is to provide to the capability being specified. For example, The vehicle’s exhaust system will power the ABC widget. | ||
Should | Not used often as an imperative in SRS statements; however, when used, the SRS statement always reads weak. Avoid using Should in your SRSs. | ||
Continuances: Phrases that follow an imperative and introduce the specification of requirements at a lower level. There is a correlation with the frequency of use of continuances and SRS organization and structure, up to a point. Excessive use of continuances often indicates a very complex, detailed SRS. The continuances below are listed in decreasing order of use within NASA SRSs. Use continuancesin your SRSs, but balance the frequency with the appropriate level of detail called for in the SRS.1. Below:2. As follows:3. Following:4. Listed:5. In particular:6. Support: | |||
Directives: Categories of words and phrases that indicate illustrative information within the SRS. A high ratio of total number of directives to total text line count appears to correlate with how precisely requirements are specified within the SRS. The directives below are listed in decreasing order of occurrence within NASA SRSs. Incorporate the use of directivesin your SRSs.1. Figure2. Table3. For example4. Note | |||
Options: A category of words that provide latitude in satisfying the SRS statements that contain them. This category of words loosens the SRS, reduces the client’s control over the final product, and allows for possible cost and schedule risks. You should avoid using them in your SRS. The optionsbelow are listed in the order they are found most often in NASA SRSs.1. Can2. May3. Optionally | |||
Weak phrases: A category of clauses that can create uncertainty and multiple/subjective interpretation. The total number of weak phrases found in an SRS indicates the relative ambiguity and incompleteness of an SRS. The weak phrases below are listed alphabetically. | |||
adequate | be able to | easy | provide for |
as a minimum | be capable of | effective | timely |
as applicable | but not limited to | if possible | tbd |
as appropriate | capability of | if practical | |
at a minimum | capability to | normal | |
Size: Used to indicate the sizeof the SRS document, and is the total number of the following:1. Lines of text2. Number of imperatives3. Subjects of SRS statements4. Paragraphs | |||
Text Structure: Related to the number of statement identifiers found at each hierarchical level of the SRS and indicate the document’s organization, consistency, and level of detail. The most detailed NASA SRSs were nine levels deep. High-level SRSs were rarely more than four levels deep. SRSs deemed well organized and a consistent level of detail had text structures resembling pyramids (few level 1 headings but each lower level having more numbered statements than the level above it). Hour-glass-shaped text structures (many level 1 headings, few a mid-levels, and many at lower levels) usually contain a greater amount of introductory and administrative information. Diamond-shaped text structures (pyramid shape followed by decreasing statement counts at levels below the pyramid) indicated that subjects introduced at higher levels were addressed at various levels of detail. | |||
Specification Depth: The number of imperatives found at each of the SRS levels of text structure. These numbers include the count of lower level list items that are introduced at a higher level by an imperative and followed by a continuance. The numbers provide some insight into how much of the Requirements document was included in the SRS, and can indicate how concise the SRS is in specifying the requirements. | |||
Readability Statistics: Measurements of how easily an adult can read and understand the requirements document. Four readability statistics are used (calculated by Microsoft Word). While readability statistics provide a relative quantitative measure, don’t sacrifice sufficient technical depth in your SRS for a number.1. Flesch Reading Ease index2. Flesch-Kincaid Grade Level index3. Coleman-Liau Grade Level index4. Bormuth Grade Level index |
Conclusion
Additional Resources
Resources for Model TemplatesAs previously noted, you should first look for SRS documents developed by your company. Not only are these documents readily available to you, but also they’re likely for products that are similar to the product you’re developing an SRS for. Additional resources include:
|
The Right Tool for the Job
If you're looking for a 'one size, fits all' requirement gathering template, this probably isn't the resource or you. But if you have some basic, complicated or somewhere in-between, project needs that need to be met — keep reading.
No one should be satisfied with cost overruns, endless miscommunication, or client/vendor embarrassment. From software development to movie producing. . .all of the above issues fall in the territory of project management. However, too many companies accept the status quo of project responsibility. Sometimes a company will have 15 different authors of one requirements gathering template. Not when you have a clear basis to work from. This is where the following templates come in.
Yes, the information will be substantially different — and your template will probably resemble nothing of the following. Yet, having a solid platform to work from is paramount for solid project managers.
Software Requirements Template .doc
Take a look at the following templates and see if they'll work for you. The documents range from simple (for basic projects) to complicated (for, well. . .in depth projects). Enjoy.
1. Simple Project Requirements Template
This requirements gathering template (see download link below) is used by many technology services to kick off and properly manage the initial and continuing work flow of managers and employees. Let's break things down to see what kind of features it offers:
- Assigned roles and responsibilities. As you see in the image, Page 3 jumps right into things by assigning roles and responsibilities from the beginning. There's nothing more important in project management then getting started on the right foot. This is one reason why a document of this caliber should be drafted by one author. That's not to recommend a lack of proper review and feedback. However, don't try and assign authority by committee when dealing with requirements gathering templates.
- Rated and organized priorities. Pages 5-10 are where the meat is. Requirements. Page 5 lists the official requirements priority key:
- High: The application cannot function properly without this requirement.
- Medium: The efficiency of the application would be greatly improved by this requirement.
- Low: This feature would be nice to have; it may consist of cosmetic changes, non-critical inquiries, or other
non-critical updates.
- Requirements flexibility. Pages 6-10 list specific requirements to the project: rated high, medium or low of course. Keep in mind most of the requirements are rated high and medium. Do notice one thing: they aren't listed from high to medium. . .yes, the majority of 'high' requirements are at the top – but there is a 'medium' thrown in towards the bottom. In terms of organization, the project manager should decide whether category or rating is more important. Plenty of space is available to list the requirements in detail. This template lists the order #, description and priority. Remember, this is a template. More features can be added or omitted.
Link to Template: Download here. On the download screen, please choose the SC_VINE_PRD.doc file.
Image credit(s): Appriss, https://www.appriss.com
2. Intermediate Project Requirement sTemplate
All software project developers should immediately skip to this section. The reason why this requirements gathering template is listed as 'intermediate' is primarily because of the detailed documentation and functions. As always, you can take this template, blend it up, re-organize and completely make it your own.