Requirements in the product development lifecycle

While every electronic product is unique and will have its own requirements, most product requirements can fall under the broad categories below:

• Functional Requirements: Qualitative descriptions of the system’s functions or tasks to be performed during operation.
• Performance Requirements: Define quantitatively the extent, or how well and under what conditions a function is to be performed (for example, rates, velocities, etc.). There may be more than one performance requirement associated with a single functional requirement.
• Interface requirements: Define how the system will interact with external systems (i.e., exchange of materials, energy, or information), or how elements within the system interact with each other. Interface requirements often include physical connections.
• Environmental requirements: Define the environmental conditions that the system will meet and must withstand in its various operational conditions. This can include ambient operating temperature ranges, non-operating storage temperature ranges, and humidity ranges for example.
• Mechanical Requirements: Define the enclosure-related requirements such as ingress protection requirements, dimensions, material properties, etc.
• Regulatory Requirements: Define the relevant regulations and standards that will apply to a product. These are often specific to the type of product and the market it will be sold in. See our comprehensive blog post for more information regarding regulatory requirements.

Defining and reviewing requirements before starting a project ensures that stakeholders and designers are on the same page, it reduces risk and leads to a smooth development process. When it comes to projects being executed by a design service provider, it is important to identify the system-level requirements in addition to the scope of work. Scope and requirements go hand in hand towards creating a common ground and understanding between the client and service provider.

There are many ways to tackle a problem. So, a product requirement set that is too vague creates a risk. The real problem that needs to be solved may not be clear. This can lead to inaccurate estimates of the effort, cost, and timeline of a project. Worse, the desired project outcomes and deliverables may not be realized. A requirement set can act as a baseline of agreement between the stakeholders and designers, giving direction to the designers to properly estimate the cost and timeline of the project. It also serves to ensure that clients will be getting what they actually expected from the project.

Scope and requirements should identify the stakeholders, define the problem, outline the activities and work that are in scope, the outcomes and outputs of that work, identify what is not in scope, any dependencies, regulatory requirements, and the assumptions that are being made. Of course, it should also include the requirements of the system.

Well-written requirements are essential to a project’s success. Defining technical requirements transforms stakeholder expectations into a clear definition of the problem. They should describe the system’s inputs and outputs, constraints, and interactions with operators and other systems.

Requirements should be defined as “shall” statements which are complete sentences with a single “shall” per statement. Simply put, a requirement shall not include “and” or “or” in its statement.

There is no formula for writing a requirement, but well-written requirements generally include the following key characteristics.

• Necessary: They state only what is necessary for achieving the stakeholder’s vision within the regulatory constraints. If a requirement can be removed or is met by another requirement, then it is not needed.
• Implementation Independent: A requirement states what is needed, not how the requirement will be met. Expressing a requirement in implementation terms may squander opportunities to find other better implementations, or it may fail to identify the actual problem that is to be solved.
• Clear: Unambiguously states what is to be achieved using simple language. The requirement should be subject to one and only one interpretation.
• Complete: The requirement is fully stated in one place with no missing information. The statement is complete in and of itself, without depending on other statements.
• Singular: A requirement addresses a single traceable element. Sentences including the words “and” or “or” should be reviewed to see if they can be broken down into atomic requirements.
• Feasible: All requirements should make technical sense and be possible to achieve. Inherently unachievable requirements, such as 100% reliability, can lead to needlessly expensive solutions.
• Verifiable: A requirement must be verifiable or testable. Otherwise, there is no way to tell if it has been satisfied.
• Correct: A requirement statement is a correct expression of the stakeholder expectation.

In addition to the characteristics above, here are some considerations of things to avoid.

• Avoid subjective content: Adjectives or statements such as “faster” or “user-friendly” are vague and subjective. This can make a requirement impossible to verify.
• Avoid using the passive voice: Requirements should be written using the active voice. Otherwise, it may be unclear who/what should perform the action, which can make verification difficult.
  For example: “The identity of the Client shall be confirmed” (This does not identify who or what is responsible for confirming the identity). A better requirement would be: The Player Management system shall confirm the identity of the Client. (Note that the “Player Management”, “identity”, “confirm” and “Client” can be defined in a glossary to avoid misinterpretations of these terms.)
• Avoid imprecise quantifiers: Requirements should be quantified precisely. Avoid vague quantifiers such as: “some”, “several”, “many”, “nearly”, “close to”, “adequate”, “reasonable”. Additionally, quantities must have units and should indicate the acceptable value range or tolerances.
• Avoid using too many ‘TBDs’: ‘To Be Determined’ enables vagueness which can result in risk, especially since they can impact the estimated budget and schedule.

Poorly written requirements do not lend themselves to easy verification, can confuse the design process, and can lead to differing interpretations causing misunderstanding between stakeholders and designers. None of these are beneficial to a project.

Below are some common risk factors of poorly captured or poorly written requirements:

A set of requirements is the common element that ties all product development activities together. Once requirements are identified and documented, the set of requirements that fully describes the system should have the following characteristics:

• Complete: The set of requirements stands alone such that it describes the necessary capabilities, characteristics, constraints, and quality factors to meet the system/product needs without needing other information.
• Consistent: The set of requirements contains individual statements that are unique, do not conflict, and are not redundant. Once shared with multiple people, the requirement statement numbers should not be changed or reused to avoid confusion.
• Feasible: The requirement set can be realized within the constraint of the project constraints. Constraints include cost, schedule, technical limitations, and regulatory constraints.
• Comprehensible: The set of requirements is clear as to what is expected by the system and its relation to any other system of which it may be a part.
• Able to be validated: It must be possible for the set of requirements to be verifiable such that it can be proven that the system meets the needs set by the requirements.

Product development is dynamic. Needs can change. Given the importance of the requirements to the design process, a requirements document is not something that you set and forget. It is a living document that will be used throughout the life of a project and will impact everything from stakeholder expectations, design direction, testing plans, delivery, and production.

Requirements must be traceable to be managed throughout a project. Traceability is the tracking of requirements throughout the product development lifecycle. It is essential to include a Requirements Document version number and a Document History section that will keep track of all changes made to the document. The history section documents the life of a requirement and makes it possible to trace the origin of every change made to it. It is usually the task of the project manager to manage and keep track of requirements throughout the lifetime of the project. Effective management of the requirements generally ensures the following activities are executed:

• Requirements are documented; designers and stakeholders are on the same page.
• Regulatory requirements are understood by all parties.
• A process exists to trace requirements.
• Requirement changes are controlled, analyzed for impact, documented, and approved through a prescribed process to ensure all parties are aware, and that changes are propagated to all affected items.
• Verify that the system/product meets the requirements. The technical team should determine test conditions and acceptance criteria during design to enable test planning.
• Post-release analysis. If there is to be a next generation of the product, data from the initial release should be considered when planning the next generation

Getting requirements right at the beginning of a hardware design project is critical because they run through the whole project. They are an indicator that points toward the future. Any small deviation could point to a completely different direction.

They are the string that ties everything together from initial stakeholder needs and expectations to detailed design decisions, development, integration, testing, and final release. This does not mean that stakeholders should not be involved throughout the whole project. Regular communication and check-ins at each major step of development are important. And the requirements can offer the right framework to drive that communication.

Many have seen the illustration below. Taking the care to define and manage a set of well-written requirements will help to avoid the undesirable situation of a user not getting what they need.