SWTM012General Requirements Specification Template13September 2017
GENERAL REQUIREMENTS SPECIFICATION TEMPLATE
For
Project Name
______
Program ManagerDate:
______
Project ManagerDate:
______
Lead EngineerDate:
Copyright © 1995 – 2001 Atlantic Systems Guild
This document may be used, modified or copied for internal use, provided this copyright is acknowledged. This is intended to form the basis of your requirements specification. It may not be sold, or used for commercial gain or other purposes without prior written permission.General Requirements Specification Template Guide
TABLE OF CONTENTS
Concept of Operations
1.0 The Purpose of the Product
1.1 The user problem or background of the project effort
1.1.1 Content
1.1.2 Motivation
1.1.3 Considerations
1.2 Goals of the project
1.2.1 Content
1.2.2 Motivation
1.2.3 Considerations
1.2.4 Examples
1.2.5 Fit Criterion
2.0 Clients, customers and other stakeholders
2.1 The client
2.1.1 Content
2.1.2 Motivation
2.1.3 Considerations
2.2 The customer
2.2.1 Content
2.2.2 Motivation
2.3 Other stakeholders
2.3.1 Content
2.3.2 Motivation
3.0 Users of the product
3.1 The users of the product
3.1.1 Content
3.1.2 Motivation
3.1.3 Considerations
3.1.4 Examples
3.2 Assign priorities to users
3.2.1 Content
3.2.2 Motivation
3.3 User participation
3.3.1 Content
3.3.2 Motivation
4.0 Mandated constraints
4.1 Constraints on the requirements and the eventual design of the product
4.1.1 Content
4.1.2 Motivation
4.1.3 Examples
4.1.4 Considerations
4.2 Commercial off-the-shelf packages
4.2.1 Content
4.2.2 Motivation
4.2.3 Examples
4.2.4 Considerations
4.3 Deadlines and other key time-related events
4.3.1 Content
4.3.2 Motivation
4.3.3 Examples
4.3.4 Considerations
4.4 Financial budget for the system
4.4.1 Content
4.4.2 Motivation
4.4.3 Considerations
5.0 Naming conventions and definitions
5.1 Definitions of all terms, including acronyms, used in the project
5.1.1 Content
5.1.2 Motivation
5.1.3 Examples
5.1.4 Considerations
6.0 The scope of the work
6.1 The context of the work
6.1.1 Content
6.1.2 Motivation
6.1.3 Example
6.1.4 Considerations
6.2 Work partitioning
6.2.1 Content
6.2.2 Motivation
6.2.3 Example
6.2.4 Considerations
7.0 The scope of the product
7.1 Product boundary
8.0 Relevant facts and assumptions
8.1 External factors that have an effect on the product, but are not mandated requirements constraints
8.1.1 Content
8.1.2 Motivation
8.1.3 Examples
8.2 Assumptions that the development team is making about the project
8.2.1 Content
8.2.2 Motivation
8.2.3 Examples
8.2.4 Considerations
9.0 Operational requirements
9.1 Expected physical environment for the end users
9.1.1 Content
9.1.2 Motivation
9.1.3 Examples
10.0 New problems
10.1 Problems this product could cause in the current environment
10.1.1 Content
10.1.2 Motivation
10.1.3 Examples
10.1.4 Considerations
10.2 Requirements for changes in other installed systems
10.2.1 Content
10.2.2 Motivation
10.3 Existing users that may be adversely affected by the new product
10.3.1 Content
10.3.2 Motivation
10.4 Limitations that exist in the anticipated implementation environment that may inhibit the new system
10.4.1 Content
10.4.2 Motivation
10.4.3 Examples
10.4.4 Considerations
10.5 Other problems created by the new product
10.5.1 Content
10.5.2 Motivation
10.5.3 Considerations
11.0 Cutover
11.1 Special requirements to get the existing data and procedures to work for the new product
11.1.1 Content
11.1.2 Motivation
11.1.3 Considerations
11.2 Data that has to be modified or translated for the new product
11.2.1 Content
11.2.2 Motivation
11.2.3 Fit Criterion
11.2.4 Considerations
System/Subsystem Specifications
12.0 Expected technological environment
12.1 Content
12.2 Motivation
12.3 Considerations
Software Requirements Specifications
Functional and Data Requirements
13.0 Use case list
13.1 Motivation
13.2 Example
14.0 Functional requirements
14.1 Content
14.2 Motivation
14.3 Example
14.4 Fit Criterion
14.5 Considerations
15.0 Data requirements
15.1 Content
15.2 Motivation
15.3 Example 1
15.4 Example 2
15.5 Fit Criterion
15.6 Considerations
Non-Functional Requirements for Security, Interoperability, Supportability, Sustainability and Usability (SISSU)
16.0 Security requirements
16.1 Special security issues
16.1.1 Content
16.1.2 Motivation
16.1.3 Examples
16.1.4 Fit Criterion
16.1.5 Considerations
16.2 File integrity requirements
16.2.1 Content
16.2.2 Motivation
16.2.3 Examples
16.2.4 Considerations
16.3 Audit requirements
16.3.1 Content
16.3.2 Motivation
16.3.3 Considerations
17.0 Interoperability requirements
17.1 Partner applications
17.1.1 Content
17.1.2 Motivation
17.1.3 Considerations
17.1.4 Examples
17.1.5 Fit Criterion
18.0 Supportability requirements
18.1 Supportability
18.1.1 Content
18.1.2 Motivation
18.1.3 Considerations
19.0 Sustainability requirements
19.1 Maintainability and portability requirements
19.2 Ease of maintenance
19.2.1 Content
19.2.2 Motivation
19.2.3 Examples
19.2.4 Considerations
19.3 Special conditions that apply to the maintenance of this product
19.3.1 Content
19.3.2 Motivation
19.3.3 Examples
19.3.4 Fit Criterion
19.3.5 Considerations
19.4 Portability requirements
19.4.1 Content
19.4.2 Motivation
19.4.3 Examples
19.4.4 Fit Criterion
19.4.5 Considerations
20.0 Usability requirements
20.1 Ease of use
20.1.1 Content
20.1.2 Motivation
20.1.3 Examples
20.1.4 Fit Criterion
20.1.5 Considerations
20.2 Ease of learning
20.2.1 Content
20.2.2 Motivation
20.2.3 Examples
20.2.4 Fit Criterion
20.2.5 Considerations
Other Non-Functional Requirements
21.0 Mandates
21.1 Standards that must be enforced
21.1.1 Content
21.1.2 Motivation
21.1.3 Example
21.1.4 Fit Criterion
21.1.5 Considerations
21.2 Operational Safety, Suitability and Effectiveness (OSS&E)
21.2.1 Content
21.2.2 Motivation
21.2.3 Examples
21.2.4 Fit Criterion
21.3 Defense Information Assurance Certification and Accreditation Process (DIACAP)
21.4 Global Combat Support System (GCSS)
21.4.1 Content
21.4.2 Motivation
21.4.3 Examples
21.4.4 Fit Criterion
21.4.5 Considerations
22.0 Look and feel requirements
22.1 The interface
22.1.1 Content
22.1.2 Motivation
22.1.3 Examples
22.1.4 Considerations
22.2 The style of the product
22.2.1 Content
22.2.2 Motivation
22.2.3 Considerations
23.0 Performance requirements
23.1 Speed requirements
23.1.1 Content
23.1.2 Motivation
23.1.3 Examples
23.1.4 Fit Criterion
23.1.5 Considerations
23.2 Precision requirements
23.2.1 Content
23.2.2 Motivation
23.2.3 Examples
23.2.4 Fit Criterion
23.2.5 Considerations
23.3 Reliability and availability requirements
23.3.1 Content
23.3.2 Motivation
23.3.3 Examples
23.3.4 Fit Criterion
23.3.5 Considerations
23.4 Capacity requirements
23.4.1 Content
23.4.2 Motivation
23.4.3 Examples
23.4.4 Fit Criterion
23.5 Scalability requirements
23.5.1 Content
23.5.2 Motivation
23.5.3 Examples
24.0 Safety critical requirements
24.1 Content
24.2 Motivation
24.3 Examples
24.4 Fit Criterion
24.5 Considerations
25.0 Cultural and political requirements
25.1 Special factors about the product that would make it unacceptable for some political reason
25.1.1 Content
25.1.2 Motivation
25.1.3 Examples
25.1.4 Considerations
26.0 Legal requirements
26.1 Legal issues that affect the product
26.1.1 Content
26.1.2 Motivation
26.1.3 Examples
26.1.4 Fit Criterion
26.1.5 Considerations
Requirements Implementation Deficiencies
27.0 Requirements that were not implemented correctly
27.1 Content
27.2 Motivation
27.3 Considerations
Requirements Related Considerations
28.0 Open issues
28.1 Issues that have been raised and do not yet have a conclusion
28.1.1 Content
28.1.2 Motivation
28.1.3 Examples
28.1.4 Considerations
29.0 Off-the-shelf solutions
29.1 Existing components that may be used for this product
29.1.1 Content
29.1.2 Motivation
29.2 Artifacts that could be copied and modified for this product
29.2.1 Content
29.2.2 Motivation
29.2.3 Examples
29.2.4 Considerations
30.0 User documentation and training
30.1 The plan for building the user documentation
30.1.1 Content
30.1.2 Motivation
30.1.3 Considerations
31.0 Future requirements
31.1 Requirements for future versions of the product
31.1.1 Content
31.1.2 Motivation
31.1.3 Considerations
32.0 Ideas for solutions
32.1 Approaches for responding to the requirements
32.1.1 Content
32.1.2 Motivation
32.1.3 Considerations
1
SWTM012General Requirements Specification Template13September 2017
Concept of Operations
1.0 The Purpose of the Product
1.1 The user problem or background of the project effort
1.1.1 Content
The content contains a short description of the work context and the situation that triggered the development effort. It should also describe the work that the user is currently doing and wants to do with the delivered product. This description should also include any operational policies or constraints that apply to the current situation. The description may be extrapolated and/or referenced from the “As-Is” and “To-Be” Department of Defense Architecture Framework (DoDAF) architectures.
1.1.2 Motivation
Without this statement, the project lacks justification and direction.
1.1.3 Considerations
You should consider whether or not the user problem is serious, and whether and why it needs to be solved. This section corresponds to Current System or Situation section of theConcept of Operations Template, and if that document is complete, this section may reference the completed document.
1.2 Goals of the project
1.2.1 Content
What is the purpose of the product? What is the real reason that the product is being developed?
1.2.2 Motivation
There is a real danger of this purpose getting lost along the way. As the development effort heats up, and the customer and developers discover more and more what is possible, it may well be that the system as it is being constructed wanders away from the original goals. This is a bad thing unless there is some deliberate act by the client to change the goals. It may be necessary to appoint a person to be “custodian of the goals”, but it is probably sufficient to make the goals public, and periodically remind the developers of it. It should be mandatory to acknowledge the goals at every review session.
1.2.3 Considerations
This section corresponds to Summary of Advantages section of theConcept of Operations Template, and if that document is complete, this section may reference the completed document. However, the fit criterion should still be completed.
1.2.4 Examples
a. “We want to give immediate and complete response to customers ordering our goods over the telephone.”
b. “We want to be able to forecast the weather.”
1.2.5 Fit Criterion
The fit criterion is an objective measure that will enable testing to determine if the goal has been met by the product.
2.0 Clients, customers and other stakeholders
2.1 The client
2.1.1 Content
This item must give the name of the client. It is permissible to have several names, but more than three negates the point. The client is the organization paying for the development and is owner of the delivered system.
2.1.2 Motivation
The client has the final acceptance of the system, and thus must be satisfied with the system as delivered. Where the system is being developed for in-house consumption, the same person may fill the roles of the client and the customer.
2.1.3 Considerations
If you cannot find a name for your client, then perhaps you should not be building the product.
2.2 The customer
2.2.1 Content
The content is the name ofthe organization that funds the client and has the operational requirements for the product. In the case of in-house development, the roles of the client and the customer are often played by the same organization. In the case of the development of a DoD product there may be several organizations playing the role of customer. In the case of a product that is being developed for international use, there might be a different customer (or customer profile) in each country.
2.2.2 Motivation
The customer role is ultimately responsible for deciding whether to fund the client to build the product. The product must be built to satisfy the aims of the customers while conforming to the constraints of the client.
2.3 Other stakeholders
2.3.1 Content
The roles and (if possible) names of other people and organizations that are affected by the product or whose input is needed in order to build the product. Examples of stakeholders include:
--Users (detailed in section Users of the Product)
--Sponsor
--Testers
--Business Analysts
--Technology experts
--System Designers
--Marketing
--Legal experts
--Domain experts
--Usability experts
--Representatives of external associations
Identify the following for each type of stakeholder:
--Stakeholder identification (some combination of role or job title, person name, organization name),
--Knowledge needed by the project,
-- Necessary degree of involvement for that stakeholder and knowledge combination,
-- Degree of influence for that stakeholder and knowledge combination,
--Agreement on how to address conflict between stakeholders who have an interest in thesame area
2.3.2 Motivation
Failure to recognize stakeholders’ results in missing requirements.
3.0 Users of the product
3.1 The users of the product
3.1.1 Content
The content is a list of the potential users of the product. For each category of user, provide the following information:
a. User name – This is most likely to be the name of a user group (e.g., supply clerks, road engineers and aircraft maintenance engineers).
b. User role – Summarizes the users' responsibilities.
c. Subject matter experience – Summarizes the users' knowledge of the business.
d. Rate the subject matter experience as novice, journeyman or master.
e. Technological experience – this describes the users' experience with relevant technology. Rate the technological experience as novice, journeyman or master.
f. Other user characteristics – Describe any characteristics of the users that have an effect on the requirements and eventual design of the product. Describe things like:
(1) Physical abilities or disabilities
(2) Intellectual abilities or disabilities
(3) Attitude to job
(4) Attitude to technology
(5) Education
(6) Linguistic skills
(7) Age group
(8) Experience in field
3.1.2 Motivation
Users are human beings who interface with the product in some way. The role of the client is to pay for the development of the product and the role of the customer is to buy the product. The role of the user is to use the product to do work. You use the characteristics of the users to define the usability requirements for the product.
3.1.3 Considerations
This section corresponds to Description of the New or Modified System sectionof theConcept of Operations Template. If that document is complete, this section may reference it.
3.1.4 Examples
Users can come from wide, and sometimes unexpected, sources. Consider the possibility of your users being clerical staff, shop workers, managers, highly trained operators, general public, casual users, inexperienced users, military, civilian, test engineers, foreigners, lawyers, remote users, people using the system over the telephone or internet connection, emergency workers, and so on.
3.2 Assign priorities to users
3.2.1 Content
Attach a priority rating to each category of user to indicate their importance and precedence. Prioritize the users into the following groups:
a. Key users. These are critical to the continued success of the product. Give greater importance to requirements generated by this category of user.
b. Secondary users. They will use the product, but their opinion of it has no effect on its long-term success. Where there is a conflict between secondary users' requirements and those of key users, the key users take precedence.
c. Unimportant users. This category of user is given the lowest priority. It includes infrequent, unauthorized and unskilled users, and people who misuse the product.
d. Percentage of this type of user – this is intended to assess the amount of consideration given to this category of user.
3.2.2 Motivation
If some users are considered more important to the product or the organization, this should be stated because it should affect the way that you design the product. For instance, you need to know if there is a large customer who has specifically asked for the product; if they do not get what they want the results could be a significant loss of business. Some users may be listed as having no impact on the product. This means that the users will make use of the product, but have no stake in it. In other words, these users will not complain, nor will they contribute. Any special requirements from these users will have a lower priority.
3.3 User participation
3.3.1 Content
Where appropriate attach to the category of user, a statement of the participation that you think will be necessary to provide the requirements. Describe the contribution that you expect this user to provide – business knowledge, interface prototyping, usability requirements etc. If possible, assess the minimum amount of time that this user must spend for you to be able to determine the complete requirements.
3.3.2 Motivation
Many projects fail through lack of user participation, sometimes this is because the required degree of participation was not made clear. When people have to make a choice between getting their everyday work done and working on a new project, the everyday work takes priority. This requirement makes it clear from the outset that specified user resources must be allocated to the project.
4.0 Mandated constraints
4.1 Constraints on the requirements and the eventual design of the product
4.1.1 Content
This specifies constraints on the way that the problem must be solved. You can think of these as mandated solutions. Carefully describe the mandated technology, include the appropriate version numbers, and a measurement of how you will test compliance. If possible, you should also explain the reason for using the technology.
4.1.2 Motivation
Your client, customer or user may have design preferences, which, if not met, will make your solution unacceptable.
4.1.3 Examples
a. The product must use the current 2-way radio system to communicate with the drivers in their trucks.
b. The product must use the Windows NT operating system.
c. The product must be a hand-held device.
4.1.4 Considerations
We want to define the boundaries within which we can solve the problem. Anyone who has experience or exposure to a piece of technology tends to see requirements in terms of that technology. This tendency leads people to impose solution constraints for the wrong reason and these untrue constraintscan easily creep into a specification. If you impose untrue constraints the possibility is that you do not have the creative freedom to arrive at the best solution to the problem. The solution constraints should only be those that are absolutely non-negotiable. In other words, however you solve this problem you must use this particular technology. Any other solution would be unacceptable.
4.2 Commercial off-the-shelf packages
4.2.1 Content
This describes applications that must be used to implement some of the requirements for the product.
4.2.2 Motivation
To identify and describe existing commercial products that must be incorporated into the eventual product. The characteristics, behavior and interfaces of the package are design constraints.
4.2.3 Examples
Including written descriptions, models or references to vendor’s specifications can complete this section.
4.2.4 Considerations
The use of a specific package has been mandated. When gathering requirements you may discover requirements that are in serious conflict with the behavior and characteristics of the package. Keep in mind that the use of the package was mandated before the full extent of the requirements was known. In light of your discoveries you must consider whether the package is a viable choice when all the requirements are known. If the use of the package is not negotiable, the conflicting requirements will have to be discarded.
4.3 Deadlines and other key time-related events
4.3.1 Content
Any known deadlines or windows of opportunity should be stated here.
4.3.2 Motivation
To identify critical times and dates that have an effect on product requirements. If the deadline is short, the requirements must be kept to whatever isachievable within the time allowed.
4.3.3 Examples
a. To meet scheduled software releases.
b. There may be other parts of the business or other software products that are dependent on this product.
c. Scheduled changes to the organization that will use your product. For example, the organization may be implementing a new system and your product is needed before implementation can commence.