IEEE 29148-2018 Standard for Requirements Engineering

IEEE 29148-2018 Standard for Requirements Engineering

By Tom Carpenter On 06/30/2023

The CWDP and CWIDP exams use this standard as the foundation for teaching and learning about requirements engineering in Wi-Fi and wireless IoT solution design processes.

In this post, I will provide a brief overview of the IEEE 29148-2018 standard for requirements engineering. The CWDP and CWIDP exams use this standard as the foundation for teaching and learning about requirements engineering in Wi-Fi and wireless IoT solution design processes. We utilize IEEE 29148-2018 Systems and Software Engineering - Life Cycle Processes - Requirements Engineering as our primary framework for both business and technical requirements. This standard and the supporting standards have been developed over a 49-year period and represent thousands of hours of collaboration, tens of thousands of hours of project experience, and many hundreds of projects among the professionals working on the committees over the years. A matured standard is far better than a single person's experience and this is the primary reason that CWNP has chosen to standardize on the 29148-2018 standard for requirements engineering across all design and integration certifications.

The standard defines three requirements engineering processes (IEEE 29148-2018 clause 6.1):

1. Business or Mission Analysis (expanded in 29148 and outlined in ISO/IEC/IEEE 15288:2015): The purpose of the Business or Mission Analysis process is to define the business or mission problem or opportunity, characterize the solution space (environment), and determine potential solution class(es) that could address a problem or take advantage of an opportunity (IEEE 29148-2018 clause 6.2.1). Outcomes include:

• The problem or opportunity space is defined. This definition may include political, economic, social, technological, environmental, and legal aspects (PESTEL). The problem or opportunity is clearly defined within the space. (The phrases problem space, opportunity space, and solution space come from the domains of marketing and product development. The problem space or opportunity space is where no product or solution exists. It is where unfulfilled needs exist, and a solution is needed. The solution space is where the system or product is coming into existence. It includes prototypes, proof-of-concept (PoC), and the actual system.)
• The solution space is characterized. The environment within which the solution will be deployed is characterized including the definition of primary stakeholders (both internal and external), the target operating environment (including known security threats in such environments, hazards, and even discovery of existing system), and the identification of candidate alternative solution classes.
• The preferred candidate alternative solution class(es) are selected. This is achieved by assessing each candidate alternative solution class based on the defined criteria when characterizing the solution space. The assessment may include expert feedback, simulation and modeling, and other procedures. After assessment, the preferred solution class or classes have been selected. (Solution classes may be defined in varying ways. One common method is to use the three classes of: operational change, system upgrade, and new system development. That is, a solution class may require only that people do work differently while another may require upgraded or new technologies.)
• Traceability of business or mission problems and opportunities and the preferred alternative solution classes is established. The establishment of traceability in this early stage is essential so that stakeholder requirements can be linked back to the business or mission requirements and eventually the system requirements can be traced back as well. A requirements management tool may be used, and identifiers may be established, that will be used in the ensuing phases.

2. Stakeholder Needs and Requirements Definition (expanded in 29148 and outlined in ISO/IEC/IEEE 15288:2015): The purpose of this process is to define the stakeholder requirements for a system that can provide the capabilities needed by users and other stakeholders in a defined environment (IEEE 29148-2018 clause 6.3.1). Outcomes include:

• Stakeholders of the system are identified. Many stakeholders were identified in process one; however, this process should begin by exploring potential new stakeholders as well.
• Required characteristics and context of use of capabilities are defined. The context of use includes the characteristics of the users, tasks and organizational, technical and physical environment. For an IoT solution, this is the environment in which the devices will operate, the organization implementing them, and the enabling systems (also called supporting systems or supporting services) that exist. Scenarios (use cases, user stories, etc.) may be developed to analyze the operation of the system in its intended environment.
• Constraints on the system are identified. These may be imposed in the business requirements, derived from enabling systems with which the IoT solution must interface, and newly discovered constraints based on stakeholder needs. They may include budgetary constraints, regulatory constraints, and technical constraints imposed by existing systems.
• Stakeholder needs are defined and translated into stakeholder requirements. With the constraints defined and needs discovered, stakeholder requirements can be created. These should include requirements that are functional- and quality-related.
• Stakeholder needs are prioritized and transformed into clearly defined stakeholder requirements. Stakeholder requirements analysis is performed to ensure the statements are constructed according to requirements engineering best practices. It is also performed to ensure they are complete as a set (comprehensive) and prioritized. Stakeholder requirements should be necessary, implementation free, unambiguous, consistent, complete, singular, feasible, traceable, verifiable, affordable, and bounded.
• Traceability of stakeholder requirements to stakeholders and their needs is established and linked to business or mission requirements.

3. System [System/Software] Requirements Definition (expanded in 29148 and outlined in ISO/IEC/IEEE 15288:2015): The purpose of this process is to transform the stakeholder, user-oriented view of desired capabilities into a technical view of a solution that meets the operational needs of the user. The system requirements define, from the supplier's perspective, the characteristics, and functional and performance requirements the system must possess to satisfy stakeholder requirements. These requirements should not imply a specific implementation (vendor, protocol, etc.), unless constrained to do so by a higher-level requirement or constraint. Outcomes include:

• The system description, including functions and boundaries, is defined.
• System requirements (functional, non-functional, interface, etc.) and design constraints are defined.
• System requirements are analyzed to ensure proper construction and traceability to stakeholder and business or mission requirements and constraints.

Figure 1 illustrates the scope of requirements and requirement processes and inputs.

Figure 1: Requirements Scope

The specifications that come from the requirements processes depend on the scope of the requirements. The lowest levels, system element or software requirements, are constrained by the stakeholder needs in business operations and the organizational environment as well as external influences.

29148-2018 defines Requirement Engineering in clause 5.2 as, an interdisciplinary function that mediates between the domains of the acquirer and supplier or developer 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, verifying (including verification methods and strategy), validating, communicating, documenting and managing requirements. The primary result of requirements engineering is sets of requirements, each set:

• being with reference to a defined system, software or service;
• enabling an agreed understanding between stakeholders (e.g., acquirers, users, customers, operators, suppliers);
• having been validated against real-world needs;
• able to be implemented; and
• providing a reference for verifying designs and solutions.

The above description of requirements engineering is our overall framework for creation of requirements. Figure 2 illustrates the interdisciplinary nature of the process and that which each party brings to the table.

The acquirer is the stakeholder that acquires or procures a product or service from a supplier. It is the individual or group within the organization with the desire and authority to request and approve the development of a solution, in this case, a wireless IoT solution. The supplier is the organization, group, or individual that enters into an agreement with the acquirer to supply the product or service.

Both the acquirer and other intra-organizational and inter-organizational stakeholders must work together with the supplier to implement effective requirements engineering. The acquirer and other stakeholders bring vertical expertise to the process. By vertical expertise, we are referencing the business sector or group of similar organizations with similar customers or group members for whom the acquiring organization operates, such as government, manufacturing, oil & gas, retail, hospitality, healthcare, entertainment, etc. The supplier brings technical expertise to the process, which, in the case of wireless IoT solutions, means an understanding of the IoT solution architectures, protocols, applications, and data processing.

While the acquirer domain provides the stakeholders, the supplier domain provides the technical professionals. The stakeholders have knowledge of the existing environment, including constraints and needs as well as future goals and objectives. The technical professionals have knowledge of IoT solutions, and the tools, planning, soft skills, and systems required for their implementation.

Understanding the levels of requirements and the interdisciplinary nature of requirements engineering will help you advance your abilities significantly. You cannot generate requirements alone in a vacuum. It will take teamwork, communication skills, and technical knowledge combined to create an effective set of requirements. We teach this process in detail in the CWDP, CWIDP, and CWIIP learning materials to ensure that you understand the process as it relates to wireless design and integration design.

Figure 2: Interdisciplinary Requirements Engineering for IoT Solutions

Tagged with: cwnp, cwdp, cwidp, iot, requirements engineering, ieee standard, wi-fi, wi-fi design

Blog Disclaimer: The opinions expressed within these blog posts are solely the author’s and do not reflect the opinions and beliefs of the Certitrek, CWNP or its affiliates.