SyRS
System Requirements Specification
(sometimes combined with the StRS (29148 8.3.1 Note 1) or BRS (Note 2))
System Requirements Specification
(sometimes combined with the StRS (29148 8.3.1 Note 1) or BRS (Note 2))
From SWEBOK Ch. 1 Section 5.2
Developers of systems with substantial software and nonsoftware components—a modern airliner, for example—often separate the description of system requirements from the description of software requirements. In this view, system requirements are specified, the software requirements are derived from the system requirements, and then the requirements for the software components are specified. Strictly speaking, system requirements specification is a systems engineering activity and falls outside the scope of this Guide.
From 29148:2011 Section 8.3
The System Requirements Specification (SyRS) identifies the technical specifications for the selected system-of-interest and usability for the envisaged human-system interaction. It defines the high-level system requirements from the domain perspective, along with background information about the overall objectives for the system, its target environment and a statement of the constraints, assumptions and non-functional requirements. It may include conceptual models designed to illustrate the system context, usage scenarios, the principal domain entities, data, information and workflows.
The purpose of the SyRS is to provide a description of what the system should do, in terms of the system's interactions or interfaces with its external environment. The SyRS should completely describe all inputs, outputs, and required relationships between inputs and outputs. A SyRS has traditionally been viewed as a document that communicates the requirements of the acquirer to the technical community who will specify and build the system. The collection of requirements that constitutes the specification and its representation acts as the bridge between the two groups and needs to be understandable by both the acquirer and the technical community. One of the most difficult tasks in the creation of a system is that of communicating to all of the subgroups within both groups, especially in one document. This type of communication generally requires different formalisms and languages.
This International Standard suggests a distinction between this structured collection of information and the way in which it is presented to its various audiences. The presentation of the SyRS should take a form that is appropriate for its intended use. This can be a paper document, models, prototypes, other non-paper document representations, or any combination. All of these representations can be derived from this one SyRS to meet the needs of a specific audience. However, care should be taken to ensure that each of these presentations is traceable to a common source of system requirements information. The audience should be made aware that this structured collection of information remains the one definitive source for resolving ambiguities in the particular presentation chosen.
This International Standard also makes a clear distinction between the system requirements (what the system shall do) contained in the SyRS and process requirements (how to construct the system) that should be contained in contract documents such as a Statement of Work.
The SyRS presents the results of the definition of need, the system operational concept, and the system requirements analysis tasks. As such, it is a description of what the system's acquirers expect it to do for them, the system's expected environment, the system's usage profile, performance parameters, expected quality and effectiveness, and verification activities.
Required Reading
System Requirements sebokwiki
29148:2011 Sections 6, 8.3 and 9.4
15288:2015 6.4.3 System requirements definition process
MITRE Systems Engineering Guide: Analyzing and Defining Requirements - pages 314-318.
How to Write the System Requirements Specification for Software Development dzone
Example from Lockheed Martin (PDF) - associated ConOps (PDF)
"The specific requirements section of a SyRS should be organized such that a consensus of the stakeholders agrees that the organization method aids understanding of the requirements. There is no one optimal organization for all projects."
1. Introduction
Identify who made the document, whom it was made for, the date, version, etc.
1.1 System purpose
Define the reason(s) for which the system is being developed or modified.
Address business value.
1.2 System scope
Define the scope of the system under consideration by
a) Identifying the system to be produced by name.
b) Referring to and stating the results of the earlier finalized needs analysis, in the form of a brief but clear expression of the user's problem(s). It explains what the system will and will not do to satisfy those needs.
c) Describing the application of the system being specified. As a portion of this, it should describe all relevant top level benefits, objectives, and goals as precisely as possible.
What does it do and not do?
1.3 System overview
This can just be a heading for the sections below or contain a brief introduction.
1.3.1 System context
Describe at a general level the major elements of the system, to include human elements, and how they interact. The system overview includes appropriate diagrams and narrative to provide the context of the system, defining all significant interfaces crossing the system's boundaries.
Good place for context diagram.
1.3.2 System functions
Describe major system capabilities, conditions and constraints.
1.3.3 User characteristics
Identify each type of user/operator/maintainer of the system (by function, location, type of device), the number in each group, and the nature of their use of the system.
NOTE: Where appropriate, the user characteristics of the SyRS and SRS should be consistent.
Good place for Use Cases and Use Case Diagram.
1.4 Definitions
Provide a list of terms and abbreviations that are used in a specific way within your document and their meaning, similar to the definitions section in the IEEE Standard. Add to this list as you continue developing the SyRS.
2. References
Similar to a Works Cited. Identify where you got the information that you used to make the SyRS, such as a link to the business mission statement. Add to this section as you develop the SyRS. Can just be a list. Should reference ConOps.
3. System requirements
This can just be a heading for the sections below or brief introduction such as "This section provides the high-level requirements for the Core System, i.e. "What the system shall do". They are organized by the types of requirements and are related to the Needs identified in the ConOps." (from Lockheed example)
3.1 Functional requirements
Define functional requirements applicable to system operation.
The most important section.
Identify actionable behaviors. Describe qualitatively the system functions or tasks to be performed in operation. (sebokwiki)
Use resources on Requirements Specification and Documentation page
3.2 Usability requirements
Define usability (quality in use) requirements. Usability requirements and objectives for the system include measurable effectiveness, efficiency, and satisfaction criteria in specific contexts of use.
From usabilityfirst: An interface should be easy to learn how to use and easy to remember how to use. The latter pertains especially to devices that require infrequent use. Users should not be required to consult a manual each time they need to use a kitchen blender for instance. Bank ATMs and web-based forms, which may be used by anyone, should be simple to use the first time around without instructions.
Usability Requirements for an interface design should support the following from the perspective of its primary users:
Efficiency of use: goals are easy to accomplish quickly and with few or no user errors
Intuitiveness: the interface is easy to learn and navigate; buttons, headings, and help/error messages are simple to understand
Low perceived workload: the interface appears easy to use, rather than intimidating, demanding and frustrating
11 Examples of Usability Requirements - For example, the requirement that 95% of customers rate a tool as fun to use.
3.3 Performance requirements
Define the critical performance conditions and their associated capabilities by including such considerations as
a) Dynamic actions or changes that occur (e.g., rates, velocities, movements, and noise levels).
b) Quantitative criteria covering endurance capabilities of the equipment required to meet the user needs under stipulated environmental and other conditions, including minimum total life expectancy. Indicate required operational session duration and planned utilization rate.
c) Performance requirements for the operational phases and modes.
Define quantitatively the extent, or how well, and under what conditions a function or task is to be performed (e.g. rates, velocities). These are quantitative requirements of system performance and are verifiable individually. Note that there may be more than one performance requirement associated with a single function, functional requirement, or task. (sebokwiki)
How to write Performance Requirements with Example
3.4 System interfaces
Specify requirements for interfaces among system elements and with external entities. Interfaces among system elements should include interfaces with the human element. Interfaces with external entities should include other systems.
Define any interdependencies or constraints associated with the interfaces (e.g., communication protocols, special devices, standards, fixed formats). Each interface may represent a bidirectional flow of information.
A graphic representation of the interfaces can be used when appropriate for the sake of clarity.
Define how the system is required to interact or to exchange material, energy, or information with external systems (external interface), or how system elements within the system, including human elements, interact with each other (internal interface). Interface requirements include physical connections (physical interfaces) with external systems or internal system elements supporting interactions or exchanges. (sebokwiki)
Interfaces may have been identified in the StRS section 4.1 and in the Context Diagram.
From Everything you wanted to know about interfaces, but were afraid to ask - Requirements Experts
“[System 1] shall [interact] with [System 2] [as defined in or having the characteristics shown in] [the document that defines the interface].” “[System 2] shall [interact] with [System 1] [as defined in or having the characteristics shown in] [the document that defines the interface].”
3.5 System operations
Heading
3.5.1 Human system integration requirements
Reference applicable documents and specify any special or unique requirements, e.g., constraints on allocation of functions to personnel and communications and personnel/equipment interactions.
Define any specific areas, stations, or equipment that would require concentrated human engineering attention due to the sensitivity of the operation or criticality of the task (i.e., those areas where the effects of human error would be particularly serious).
NOTE ISO 18529, Ergonomics — Ergonomics of human-system interaction — Human-centred lifecycle process descriptions, contains a formalized model that can be used in the specification, assessment and improvement of the human-centered processes in system development and operation.
Human Systems Integration Requirements Pocket Guide Air Force
3.5.2 Maintainability
Specify the quantitative maintainability requirements that apply to maintenance in the planned maintenance and support environment. Examples are as follows:
a) Time (e.g., mean and maximum downtime, reaction time, turnaround time, mean and maximum times to repair, mean time between maintenance actions)
b) Rate (e.g., maintenance staff hours per specific maintenance action, operational ready rate, maintenance time per operating hour, frequency of preventative maintenance)
c) Maintenance complexity (e.g., number of people and skill levels, variety of support equipment, removing/replacing/repairing components)
d) Maintenance action indices (e.g., maintenance costs per operating hour, staff hours per overhaul)
e) Accessibility to components within systems and to parts within components
Reference StRS section 5 and OpsCon Section (A.2) 5.6.
From Requirements Quest:
DEFINITION: Maintainability is the ease with which faults in a software system can be found and fixed.
ELICITATION: Maintainability requirements address the user concern for how easy it is to upkeep and repair the system. When eliciting maintainability requirements, consider aspects such as maintenance performance metrics, maintenance support features, system maintenance features, system complexity, development process, maintenance process cycle, and possible problems.
EXAMPLE: [Mean preventative maintenance time] The mean preventative maintenance time on applying routine plug-in updates to the RQ Website shall be less than 30 minutes every 2 weeks.
3.5.3 Reliability
Specify the system reliability requirements in quantitative terms, including the conditions under which the reliability requirements are to be met. This may also include the reliability apportionment model to support allocation of reliability values assigned to system functions for their share in achieving desired system reliability.
3.6 System modes and states
If the system can exist in various modes or states define these and, as appropriate, use diagrams.
NOTE The mode of a system refers to a collection of states.
3.7 Physical characteristics
Heading
3.7.1 Physical requirements
Include constraints on weight, volume and dimension. Include the construction characteristics of where the system will be installed, requirements for materials to be used in the item or service covered by this specification, and requirements covering nameplates and system markings, interchangeability of equipment, and workmanship.
Define constraints on weight, volume, and dimension applicable to the system elements that compose the system. (sebokwiki)
3.7.2 Adaptability requirements
Define requirements for growth, expansion, capability, and contraction. For example, if the system will require future network bandwidth, the applicable hardware should be specified with extra card slots to accommodate new network cards as demand increases.
Define potential extension, growth, or scalability during the life of the system. (sebokwiki)
3.8 Environmental conditions
Include environmental conditions to be encountered by the system. The following areas should be addressed: natural environment (e.g., wind, rain, temperature, flora, fauna, fungus, mold, sand, salt spray, dust, radiation, chemical, and immersion); induced environment (e.g., motion, shock, noise, electromagnetic, thermal); electromagnetic signal environment; self-induced environment (e.g., motion, shock, noise, electromagnetic, thermal); threat; and cooperative environment. Consideration should also be given to legal/regulatory, political, economic, social, and business environment.
3.9 System security
Define the system security requirements related to both the facility that houses the system and operational security requirements of the system itself. One example of security requirements might be to specify the security and privacy requirements, including access limitations to the system, such as existence of log-on procedures and passwords, and of data protection and recovery methods. This could include the factors that would protect the system from accidental or malicious access, use, modification, destruction, or disclosure.
Especially in safety-critical embedded systems this might incorporate a distributed log or history of data sets, the assignment of certain functions to different single systems, or the restriction of communications between some areas of the system.
3.10 Information management
Define the requirements for the system's management of information that it receives, generates, or exports. Examples include types and amounts of information the system is required to receive and store, any proprietary or other protections levied on the information the system deals with, and what backup and archiving requirements exist for the information.
3.11 Policies and regulations
Detail any relevant organizational policies that will affect the operation or performance of the system as well as any relevant external regulatory requirements, or constraints imposed by normal business practices. Examples of requirements include multilingual support, labour policies, protection of personnel information, and reports to a regulatory agency.
Specify health and safety criteria, including those basic to the design of the system, with respect to equipment characteristics, methods of operation, and environmental influences such as toxic systems and electromagnetic radiation.
3.12 System life cycle sustainment
Outline quality activities, such as review, and measurement collection and analysis, to help realize a quality system. Life cycle sustainment also includes provision of facilities needed to provide operational- and depotlevel support, spares, sourcing and supply, provisioning, technical documentation and data, support-personnel training, initial cadre training and initial contractor-logistics support.
3.13 Packaging, handling, shipping and transportation
Define requirements imposed on the system to ensure that it can be packaged, handled, shipped and transported within its intended operational context.
4. Verification
Provide the verification approaches and methods planned to qualify the system or system element. The information items for verification are recommended to be given in a parallel manner with the information items in Section 3.
https://www.sebokwiki.org/wiki/System_Verification
Identify how you plan to prove that the requirements listed in section 3 were met.
You can make a table like page 45 on the Lockheed example. See four fundamental methods of requirement verification.
What is developed for this section will be used in the traceability matrix.
5. Appendices
5.1 Assumptions and dependencies
List any assumptions and dependencies applicable to the system requirements that should be taken into account in the allocation and derivation of lower-level system requirements.
5.2 Acronyms and abbreviations
From 29148:2011 8.3.2
1. Introduction
1.1 System purpose
1.2 System scope
1.3 System overview
1.3.1 System context
1.3.2 System functions
1.3.3 User characteristics
1.4 Definitions
2. References
3. System requirements
3.1 Functional requirements
3.2 Usability requirements
3.3 Performance requirements
3.4 System interface
3.5 System operations
3.6 System modes and states
3.7 Physical characteristics
3.8 Environmental conditions
3.9 System security
3.10 Information management
3.11 Policies and regulations
3.12 System life cycle sustainment
3.13 Packaging, handling, shipping and transportation
4. Verification
(parallel to subsections in Section 3)
5. Appendices
Assumptions and dependencies
Acronyms and abbreviations