Creating an Engineering Requirements Management Plan

Identifying and establishing a set of requirements at the starting point of any project is crucial to achieving success. This article, in a simple manner, aims to introduce you to the creation of a requirements management plan in engineering projects through some basic concepts and the use of Altium 365 Requirements & Systems Portal.

This blog is intended for engineers, professionals, project managers, product managers, and anyone who needs to understand how to create a requirements management plan.

What Is a Requirement?

While obvious, it is worth reflecting on the issue 'what is a requirement?' A requirement, according to the dictionary, is 'a necessary circumstance or condition for something.' In the engineering world, requirements are a way of communicating between users or clients and the developers of a project. Sometimes, especially in large projects, this is one of the few possible ways users can tell developers what they want.

Example of a requirement in an automotive project:

'Users shall be able to travel automatically at predefined speeds by means of Cruise control.'

Why Are Requirements So Important?

It is said that: "poor requirements definition and management can cost you a fortune and lead to failure in project execution."

The definition of requirements is so important that they generally form the basis of contracts between clients and suppliers. What is defined in the requirements shall be considered in the project and may be required by the client, however, what does not appear in the definition of the requirements shall not be required in the delivery phase of the project.

Therefore, if we are responsible for writing the requirements, we should:

• Find out exactly the needs of the customer.
• Create a document with a clear structure and well-organized requirements.
• Set up a meeting with the client to verify both parties have written interests (contract).
• Ensure the adopted solution is faithful to the requirements as the project progresses.
• Verify and test compliance with requirements.

This group of actions is known as the requirements management plan. It is very important to have a manager or management team in the organization that identifies, defines, and traces the requirements through the life of the project.

How Should a Requirement Be Written?

Writing a requirement is not as simple and trivial as it may seem. It is a document that must meet a certain amount of criteria. Therefore, a requirement must:

• Be clear, precise, and specific: it must clearly and exactly describe what is needed.
• Be concise: use as few words as possible.
• Use simple language: avoid confusing the reader with technical terms or complicated words.

Example of a well-written requirement:

• All components (SMD and thru-hole) must be placed on the TOP face.

Example of a poorly written requirement:

• SMD components must all be placed on the same side, and it must be ensured that the solder of the thru-hole components is on the opposite side to the solder of the SMD components.

In the example above, the well-written requirement is concise and perfectly defines without ambiguity what is required, while the poorly written requirement has too much text, which does not contribute to anything, confuses the reader and is imprecise (it does not define on which side the components should be placed).

The requirements are always mandatory and, therefore, should be written using 'shall.' When requirements are preferences or wishes (not obligatory) 'should' can be used to define it or even 'may' when it is a suggestion or given permission.

Basic Rules For Defining a Requirement

In addition to the above, when we define a requirement, it must follow some basic rules:

• It must have a unique ID.
• It should be understood by itself without additional information.
• It must be consistent with the rest of the requirements.
• It must always be up to date (version control).
• It must be feasible (avoid impossible requirements).
• Its implementation must be verified through inspection, demonstration, or testing.

Identification of Requirements

Each requirement defined must have a unique ID so that it can be referred to during the requirements definition and review, as well as at any time during the project execution phase. An example of requirements identification is shown using Altium 365 Requirements and Systems Portal.

What Types of Requirements Exist, and How Are They Classified?

There are primarily two types of requirements:

• Functional Requirements: These define the functionality of the system.
• Non-Functional Requirements: These impose constraints or limitations on the solution (environmental, reliability, electromagnetic compatibility, safety, applicable regulations, cost requirements, timelines, etc.).

The combination of these functional and non-functional requirements constitutes what is known as the system specification. In the system specification, requirements are grouped according to the following levels:

• Initial or customer requirements
• System requirements
• Subsystem requirements

Initial or customer requirements are those that are directly provided by the client or user before the project begins. They are crucial, as they capture the client's needs and thus serve as the starting point for creating our requirements matrix. Subsequently, the system specification organizes the requirements based on the level of detail pertinent to each part of the project. In this manner, we have system requirements, which apply to the complete system, and subsystem requirements, which apply only to specific parts of the system. Let's illustrate this with an example.

Let's suppose that we are developing a project where a new smartwatch is going to be created. The system requirements, therefore, are those that apply to the set (see the examples below):

• REQ-01: Shall be designed for adult users.
• REQ-02: Shall display all information on the screen.
• REQ-03: Shall be rechargeable.
• REQ-04: Shall have buttons or other mechanisms for user navigation through the menus.

Once the system requirements have been defined, the remaining requirements are split into different subsystems.

Following the example of the smartwatch development project, examples of subsystems include:

• Subsystem 1 – Strap
• Subsystem 2 – Display
• Subsystem 3 – Power
• Subsystem 4 – Communications
• Subsystem 5 – User Interface

Therefore, the definition of subsystem requirements could be as follows:

• STRAP-01: Recyclable materials shall be used.
• STRAP-02: Shall be able to be fixed magnetically.
• DISPLAY-01: The display shall be 2 inches.
• DISPLAY-02: The resolution shall be 368 x 448 pixels.
• POWER-01: Shall be powered by a rechargeable battery.
• POWER-02: Battery life shall be at least 48 hours.
• COMMS-01: Shall be capable of Bluetooth communication.
• COMMS-02: Shall be capable of Wi-Fi communication.
• UI-01: Shall have a side button in the form of a dial for menu navigation.

This structured organization of requirements allows for easier definition, tracking, and management. 

Requirements Traceability

In a requirements management plan, requirements traceability is essential; this means tracking or observing the evolution of requirement implementation throughout the project.

Continuing with the smartwatch project example, once the product schematics are designed, engineers and managers must hold as many meetings as necessary to verify that the designed solution meets the defined requirements before moving on to the next step, in this case, the PCB layout.

Requirements and Systems Portal aids in this task, as it provides visibility of the requirements defined directly in Altium 365. This means that managers and engineers can now trace requirements in the design in real-time, via a web browser, allowing them to add comments, assign tasks to team members, and provide real-time visibility of changes in requirements to design engineers, thereby completely transforming the traditional design and review paradigm.

How Are Requirements Managed?

There are various ways to manage requirements. Companies with fewer financial resources and independent professionals often use simple and inexpensive tools like version-controlled spreadsheets, while larger companies typically utilize specialized software for requirements management such as DOORS, Valispace, Confluence, ReqView, among others. Altium has acquired Valispace and now integrates the requirements management tool into Altium 365 ecosystem through Requirements and Systems Portal.

Requirements Management Plan Procedure

Based on the previous sections, we could define the requirements management plan as the set of actions through which the company defines, manages, verifies, and validates the needs or requirements of stakeholders throughout the project's execution, from conception to commercialization. The following image illustrates a flowchart of a standard requirements management plan.

Conclusions

The Importance of Having a Requirements Management Plan

Every engineering project must have a requirements management plan that ensures the development team fully understands the client's needs and all system and subsystem requirements.

Know How to Write, Define, and Identify a Requirement Correctly

Basic rules must be followed for writing and defining requirements. Similarly, it is essential to understand the types of requirements that exist and how to classify them correctly, as well as to comprehend what requirements traceability is.

Requirements Traceability

Requirements have been written to be met, therefore, observing and tracking them during project execution is very important, since the sooner a deviation or non-compliance is detected, the less impact it will have on the project.

Use Appropriate Software

Use Requirements and Systems Portal to maximize its potential in conjunction with Altium 365. This allows for much closer interaction between requirements engineering and development engineering, reducing the likelihood of project deviations and shortening development times.

Start using modern and AI-powered requirements management today!