Writing requirements using must, shall, should statement qualifiers can significantly help you manage and deliver a system that is compliant, fully functional, and maybe even include some nice-to-haves.

Characteristics of a Good Requirement:

Apparatus used to conduct the required process or test.


But first let’s review what characterizes a good requirement statement. The Institute of Electrical and Electronics Engineers (IEEE) recommends these 8 characteristics (source: IEEE Recommended Practice for Software Requirements Specifications, 1998):

  • Correct
  • Unambiguous
  • Complete
  • Consistent
  • Ranked for importance and/or stability
  • Verifiable
  • Modifiable
  • Traceable

A quick Internet search will result in many other reputable sources having very similar recommendations. But there is something that has proven to be very useful in addition to the above, especially Life Science companies who are highly regulated.

Leveraging Must as a Regulatory Requirement

The recommendation here is to write your requirements using either Must, Shall, or Should statement qualifiers. Define each as follows:

  • MUST: A regulatory requirement that is non-negotiable. System must deliver upon this requirement otherwise the system cannot be released to production.
  • SHALL: A business requirement that is required, but authorized decision makers can negotiate these requirements based upon adverse impact to the business if not delivered. In other words, this is a risk based decision.  System shall deliver upon this requirement unless the business decides otherwise.
  • SHOULD: A nice-to-have that is not required. System should deliver this requirement, but it is not necessary.

Adhering to must, shall, should requirement statements will result in the ability to read any requirement, at any time, and immediately understand its rank for importance and/or stability (refer to characteristic #5 above). Furthermore, it’s easy to identify required rigor when it comes to testing. During audits or inspections, you’ll be able to easily identify requirements that are a regulatory requirement versus those that are nice-to-have.

There’s even another benefit that may not be obvious. The word “must” translates forward and backward in most languages and the meaning is not lost. Other words such as “shall” and “should” loose their meaning when translated forward and backward. This becomes more important with multi-national organizations or systems that span geographies.

“Must” translates forward and backward without losing its meaning

Leverage Technology to Manage at a Requirement Level

Advances in technology now allow us to manage requirements at the requirement level as opposed to managing at a requirement document level. For example, the ValGenesis Validation Lifecycle Management System (VLMS) allows requirements be managed in a library of requirements. This expedites requirement management document development and delivers consistency because requirements can be assessed once and used by multiple systems. Consider 21 CFR Part 11 requirements; they’re consistent across all computerized systems where Electronic Records and Electronic Signatures (ER/ES) apply. Why not use the same requirements for all systems?

The Bottom Line

Developing requirements that adhere to good requirement statement characteristics, and using must, shall, should requirement statement qualifiers helps ensure overall project success. Leveraging technology will even further improve efficiency and effectiveness.

About the Author

cloud-sun Steve Thompson is Senior Manager of Professional Services and is responsible for managing ValGenesis’s Implementation & Professional Services in the West Coast Region of the United States. Steve has over 20 years of GxP experience in Life Sciences (including Medical Device), is a Parenteral Drug Association (PDA) certified Auditor, has held managerial positions at various levels within Information Technology (IT) and Quality Assurance (QA) for major organizations, is a published author and has presented at several conferences and industry associations. Steve has a B.S. in Computer Information Systems from DeVry University, City of Industry, California.
Regulatory Requirements Requirement Mangement Requirement Process Software Requirements Traceability matrix Validation Requirements

Leave a Comment

Your email address will not be published. Required fields are marked *