Importance of Requirements
The Project Management Institute (PMI) cites a failure by enterprise organisations to establish a requirements baseline at an early stage of the project and a failure to consider the user in requirements, as two of the seven most common causes of project failure .
Despite this, many projects still suffer from poor requirements and the very thought of having to tackle requirements is often enough to set the eyes rolling of even seasoned project owners. Spending the time to define the “what we want to do” and not the “how we want to do it” in design & problem solving is hugely beneficial to all stakeholders involved.
Requirements aren’t always easy
Requirements capture & analysis is often seen as a purely paperwork exercise, being requested by the regulators. These early phases of work are often overlooked, and often not given the consideration they deserve. It is often the case that people underestimate the value that conversations generated through the development of requirements can create. “Requirements” themselves aren’t a single check list, document or check box to be filled in. They are a multi-disciplinary set of statements that define the product or system you are developing at multiple levels of detail.
They need to be managed, maintained and evolve within the project as your understanding and knowledge develops. It can be thought of as essentially capturing the “essence” of a particular problem, along with the user’s needs and applying critical and technical thinking to produce a solution that can satisfy those needs. This takes time upstream in the innovation stages of development and requires probing of key questions to elicit the key attributes and quantify the problem. This applies to multiple disciplines and can help to provide synergy between human factors, engineering and industrial design. The challenge is often convincing the main stakeholders in a project to invest the time upstream on this work.
Depending on the complexity of the project, there may be multiple levels to the requirements, from the user level, product level, system level and then the lower module level and detailed specification requirements. The latter items often originate from the former, and the details will evolve over time. New requirements often get generated in the process, through discovery, exploration, analysis, prototyping and testing, as new questions get raised as the project progresses. Whilst requirements for a complex system can take significant time to get right, it’s not the case that this level of detail is needed for every single project. It can often be just as valuable to document the requirements on 1 page of A4, particularly at a very early stage of feasibility.
What are the benefits?
The real tangible benefits are often overlooked when exploring and analysing requirements. In having discussions and thought processes about what user’s really want up front, before any solutions are explored, product requirements naturally fall into place. It is often hard to get away from the “illusion of progress” by creating “looks like, works like” prototypes with limited time and budget. Sweeping assumptions are often made about available solutions, and real innovation opportunities can be missed. Early “form factor” PCB’s and assemblies are often produced, along with software that can “be fixed later on”. Performance is often “TBC” and the design starts early. This is the expensive and often painful route, where multiple iterations are required, and the system is difficult to test.
It’s more efficient to have brainstorming of user and functional requirements, and then, if needed, determine how you will answer the unknowns. Technology demonstrator prototypes can be used to figure out the key attributes of an idea. This then feeds into the detailed specification and provides an easier path to implementation. Verification and validation becomes simpler as your requirements form the basis of your verification plan. Allowing a test-driven development approach to be followed at an early stage, helps to reduce risk and make hand-over and third party review a lot more straightforward. If something can be better quantified, and the constraints understood, e.g. the accuracy and precision required, finding the right solution is easier and there will be no surprises. Retrospective test and requirements analysis, is prone to creating issues down the line.
Everyone knows that the cost of change increases over the period of a development cycle. To offset this, it is anticipated that the risk should reduce as the project develops, having better defined requirements and thus test methods will help to alleviate these costs by identifying risks early.
It is not always easy to get a team to work together and move in the same direction, good requirements provide a common language. Getting more team members from different disciplines and backgrounds also fosters better collaboration and team morale. This then harbours a strong team spirit and gives project stakeholders more ownership in the process, providing a smoother path to success.
The other major benefit is of course to provide a smoother path to regulatory approval, highlighted by the FDA stating that ‘development of a solid foundation of requirements is the single most important design control activity’. Regulatory constraints are valid requirements to introduce in the upstream work, as these can have a major impact on the path taken in development. For example, in BS EN ISO 13485:2016, Section 7.2, customer related processes are defined, such as the definition & review of requirements for delivery and post-delivery, as well as identifying any additional ones that arise in the process.
This is not a linear process and there are feedback loops in the process, and some form of so called “solutioning” up front. In the age of easily accessible software and hardware and more connected devices, it is even more important than ever to have a solid grounding in regulatory compliance in a development program.
What constitutes good requirements
Good requirements are essentially descriptions of what a system needs to “do” for users. They are not the same as the specification, but the specification includes the requirements.
They are clear statements that:
1. Show the users’ needs were understood within a set of constraints
2. Allow technical performance to be achieved at a system level to satisfy user’s needs
3. Ensure regulatory requirements are met
4. Are traceable and testable
5. Clear, concise and unambiguous
It is best described as the “What” is needed and not the “How” is implemented, and ultimately at the highest level is a common language that can communicate the description of a system between stakeholders of different disciplines and backgrounds.
Requirements should be driven by user’s needs, within any constraints, and not necessarily by developer’s opinions. However, it is worth bearing in mind that highlighting feasible technologies & solutions early on, given a timescale and budget, is no bad thing and can drive other constraints, such as cost. It is important to not think of a solution to begin with (e.g. a specific type of sensor, or device) and work backwards to the specification or the fundamental question being asked. What matters at the end of the day is a “black box” that works as expected.
Writing good requirements isn’t always easy but developing them early on is well worth the effort. It may require more of a cultural change, rather than purely introducing new process, but there are numerous benefits as discussed.
By following some simple steps, the process can be easy:
• Introduce multiple team members early in the discussions of a brief or concept & provide them responsibility and a stake in the design.
• Explore and identify key attributes that can describe the required functionality; these could be quantifiable parameters.
• Develop analysis, simulation and performance-based technology demonstrator rigs to probe these parameters and identify the limitations. Test methods can then be developed to validate suitable solutions.
• Maintain the requirements documentation at all levels. The further down a level you go, the more detail is required until ultimately you end up at the technical specifications.
• Avoid ambiguity, “TBD” and similar statements!