Many projects fail due to missing or incorrect understanding or decomposition of user or stakeholder requirements. According to Hussain [1], approximately 22% of software projects fail due to incomplete or changing requirements. Writing good requirements is not merely a task and should be given a significant priority in both effort and schedule as they set the required performance of the product, are essential to mitigate risk and set objective goals to measure against.
The following are guidelines for creating good requirements:
- Capture the required function and performance- Describe what the device must do and how well it must do it. Avoid negative (what it shouldn’t do) requirements as much as possible since they are difficult to verify and inherently narrow.
- Identify Needs vs Wants- It is very beneficial to rank the desire for certain requirements since some requirements are more important than others. Everyone wants a Ferrari at low cost with a fast delivery time, but tradeoffs are always forced to happen. It’s better to determine where there is wiggle room up front than to spend time redesigning to achieve an acceptable tradeoff.
- Avoid “Solutioning”- The requirement needs to specify what the device needs to do and not “how” it does it. Being implementation specific only reduces the opportunity for the design engineers to achieve a good balance between competing requirements. Sometimes this is not obvious. Note there are some instances where implementation details may be justified as follows:
- Specific risk controls- during risk analysis, specific mitigation measures may be identified. The reason to make these requirements is that they will be inherently verified with the other system or subsystem requirements. It is still advisable to keep as implementation free as possible.
- Pre-existing product in field- if there is an interaction that the device will have to ensure in the field, e.g., fitting widely available syringes.
- Ensure Verifiable Language (for System Req or lower level). – The verbiage needs to be concise and explicitly define the requirement. There needs to be an objective method to verify the requirement. It should mean the same thing to anyone who reads it what the definition of success is. Some key words [2] that raise red flags in requirements include: “relevant,” “some,” “any,” easily,” “quickly,” “intuitive,” “readily,” “approximately,” “clearly,” “effective,” “like,” “latest,” “support,” “efficient,” “user friendly,” “fast,” and of course “include but not limited to”!
- The requirement should also be able to be verified with a single test. Multiple tests per requirement can lead to a “partial pass” of the requirement. There is risk of a “pass” of the first test being interpreted as the entire requirement passing before all testing is complete.
- Embrace standards – Consider all the standards that the regulatory bodies of your intended markets will be looking for evidence of meeting. Standards can also be a great resource to avoid reinventing the wheel for what is verifiable and verification methods.
- Include risk analysis input early- Preliminary hazard assessments are essential to identify aspects of the concept (prior to design) that can greatly improve safety early. The strongest risk controls are those that eliminate the source of potential hazards.
- Explore all use cases and usability- Include assessments with all identified user types and review their needs are being addressed. Identify opportunities for misuse and include mitigations as design inputs.
- Don’t forget about the company’s needs. Translate the business/stakeholder needs into system requirements. It is much better to have these formal goals set with the business leaders early in the project than to hope for commercial viability.
- What good is a device that meets all performance requirements, but the business can’t financially justify making or servicing? Specify COG’s limit based on estimated annual production volume…
- Serviceability/reliability: even if behind a panel, a requirement for a data output port for service can reduce the downtime for customers.
- Differentiate Project vs Product- Avoid the temptation to specify items related to the development project itself. For example, a requirement that states “a minimum of 3 devices shall be used in formative assessment” isn’t a system requirement.
- Include Peripherals-Consider up front in the design input phase the items that go along with the device. Is there a cart that the device needs to interface with or be provided with? The IFU may have requirements to be available in a certain media format or language.
- Identify all interfaces-
- User to device- This is commonly a screen, buttons, lights, speaker/buzzer and ports. Is the user wearing gloves, sterile, holding other things? Maybe a foot pedal makes more sense than a touchscreen action.
- Device to device- Are all the ports that are needed specified? If the port needs to interface with existing equipment at the customer site, then requirements will ensure compatibility.
- Ambient environment to device- Some examples are: electromagnetic interference, vehicle vibration during shipping, temperature, humidity and pressure that the device is exposed to in transit and needs to operate within.
- Avoid Unnecessary Requirements- Periodically review the requirements set and ask what would happen if they weren’t a requirement at all? Maintaining traceability between the requirements levels can aid with this. If there is a software requirement for something but no system need for it, why is it a software requirement? If the success or risk of the device would not be impacted, they are candidates for removal. Every requirement has a cost to review, test, trace and maintain and needs to add some value.
- Perform Reviews of Design Inputs- The feedback from all stakeholders should be gathered during formal reviews of the requirements. Feedback should be addressed with definable action items that impact requirements. Informal review and feedback should occur regularly to improve project efficiency.
- Document requirements with versions- Track progress and ensure that stakeholders are reviewing the latest version of the set of requirements.
This article is written by J. Herrig, Design Solutions Inc
www.design-solutions.com
References
- Hussain, Azham & Mkpojiogu, Emmanuel & Kamal, Fazillah. (2016). The Role of Requirements in the Success or Failure of Software Projects. EJ Econjournals. 6. 6-7. https://www.researchgate.net/publication/308972993_The_Role_of_Requirements_in_the_Success_or_Failure_of_Software_Projects
- Guide for Writing Requirements Summary Sheet
Document No.: INCOSE-TP-2010-006-02
Version/Revision: 2
Date: July 1, 2015