SyRS

Introduction

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.

Key Resources

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.

Other Resources

How to Write the System Requirements Specification for Software Development dzone

Example from Lockheed Martin (PDF) - associated ConOps (PDF)

Example Outline with More Information

"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

Example Outline

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