Intended audience: Anyone implementing best practice Requirement Management.
ISO/IEC/IEEE29148:2011 contains provisions for the processes and products related to the engineering of requirements for systems and software products and services throughout the life cycle. It defines the construct of a good requirement, provides attributes and characteristics of requirements, and discusses the iterative and recursive application of requirements processes throughout the life cycle.
Click image to enlarge
Information items applicable to the engineering of requirements and their content are defined. The content of ISO/IEC/IEEE 29148:2011 can be added to the existing set of requirements-related life cycle processes defined by ISO/IEC 12207 or ISO/IEC 15288, or can be used independently.
This International Standard
- specifies the required processes that are to be implemented for the engineering of requirements for systems and software products (including services) throughout the life cycle,
- gives guidelines for applying the requirements and requirements-related processes described in ISO/IEC 12207:2008 (IEEE Std 12207-2008) and ISO/IEC 15288:2008 (IEEE Std 15288-2008),
- specifies the required information items that are to be produced through the implementation of the requirements processes,
- specifies the required contents of the required information items, and
- gives guidelines for the format of the required and related information items.
This International Standard is applicable to
- those who use or plan to use ISO/IEC 15288 and ISO/IEC 12207 on projects dealing with man-made systems, software-intensive systems, software and hardware products, and services related to those systems and products, regardless of project scope, product(s), methodology, size or complexity,
- anyone performing requirements engineering activities to aid in ensuring that their application of the requirements engineering processes conforms to ISO/IEC 15288:2008 (IEEE Std 15288-2008) and/or ISO/IEC 12207:2008 (IEEE Std 12207-2008),
- those who use or plan to use ISO/IEC/IEEE 15289:2011 on projects dealing with man-made systems, software-intensive systems, software and hardware products, and services related to those systems and products, regardless of project scope, product(s), methodology, size or complexity, and
- anyone performing requirements engineering activities to aid in ensuring that the information items developed during the application of requirements engineering processes conform to ISO/IEC/IEEE 15289:2011.
Requirements engineering is an interdisciplinary function that mediates between the domains of the acquirer and supplier to establish and maintain the requirements to be met by the system, software or service of interest. Requirements engineering is concerned with discovering, eliciting, developing, analyzing, determining verification methods, validating, communicating, documenting, and managing requirements.
The result of requirements engineering is a hierarchy of requirements that: enables an agreed understanding between stakeholders (e.g., acquirers, users, customers, operators, suppliers) is validated against real-world needs, can be implemented provides a basis of verifying designs and accepting solutions. The hierarchy of requirements may be represented in one or more requirements specifications
The stakeholder requirements specification (StRS), the system requirements specification (SyRS) and the software requirements specification (SRS) are intended to represent different sets of requirement information items.
The specifications correspond to the requirements in the diagram below as follows: StRS - Stakeholder Requirement (business management level and business operational level); SyRS - System Requirements; and SRS - Software Requirements. These information items can be applied to multiple specifications (instances) iteratively or recursively.
An example of a sequence of requirements processes and specifications is illustrated below.
EXAMPLE 1 The SyRS can be used for a system or a system element. The SyRS can also be used to specify software requirements.
EXAMPLE 2 The SRS can be used for lower level software requirements for software specific elements of a system or system element.
The Concept of Operation (ConOps) and the System Operational Concept (OpsCon) are useful in eliciting requirements from various stakeholders in an organization and as a practical means to communicate and share the organization's intentions.
The ConOps, at the organization level, addresses the leadership's intended way of operating the organization. It may refer to the use of one or more systems as 'black boxes'.
The OpsCon addresses the specific system-of-interest from the user's view point.
Information items represented in the StRS, SyRS, SRS, ConOps, and OpsCon documents are interdependent. The development of these items requires interaction and cooperation, particularly in relation to the business processes, organizational practice, and options for technical solutions. Different types of systems may have parallel documentation for the various requirements they contain. However, in general, they will start with an StRS and an SyRS, and include the software specifications as well as those for hardware and interfaces.
Typical Use Cases
Here is a typical, but not exhaustive, list of roles and associated use cases that would interact with this solution.
|Internal / Project team||
These apps and templates are used for the solution.
- Select an existing, or create a new project
- Click on the Solution Store, and select the IEEE Templates you require
- Once you have the templates, follow the how to guide.
Here is a screenshot of the SyRS Specification template:
Click image to enlarge
Questions or Comments?
Respond to this post if you want to comment on the template or ask the author a question.