We Know What We Want! Why Write Requirements?

You’re buying a new spectrometer in the end-of-year slush-fund spend. Use it or lose it. No time to write requirements? Just spend, baby, spend! Will this be a case of repenting at leisure?

What is the point of writing requirements? It might come as a surprise, but the main purpose of a requirements specification is not regulatory paperwork, but to provide business benefits for any laboratory. It is the most important document that defines the intended use and ensures investment protection: picking the right system for the job while meeting regulatory requirements. It is not possible to validate software and to qualify equipment without clear predetermined and well-structured software requirements.¹ Pharmaceutical Inspection Convention/Pharmaceutical Inspection Cooperation Scheme (PIC/S) PI-011 section 4.3 states it is essential for the regulated user to define a requirement specification prior to selection.²

Yet, writing and reviewing requirements often get the least amount of attention, care, and time. Even worse, it might be copied from a vendor specification (for example, a user manual), regulations, pharmacopeial general chapters, or an older document version without adequate modification or thought. This results in untestable and/or unverifiable requirements (that may be solution or design statements), or standards copying (such as: must adhere to 21 CFR 11³ or Good Automated Manufacturing Practices [GAMP] 5 SE⁴), and results in a static document, not reviewed by the proper stakeholders or kept up-to-date.

Requirements are the initial, foundational document that precedes the selection, purchase, validation, data integrity, system governance, and life cycle management of the spectrometer system or any other computerized system and its data. The requirements document is a living document that should be continually reviewed and updated to reflect the current system.^5,6

At the start of a validation project, there should be at least two versions of the requirements:

• The first version captures the generic requirements that allow for proper system selection.
• The second version is tailored to the selected system, including the name and version number, and follows the training and prototyping of the new system.
• A third version may be required to correct the errors and misunderstandings of the second version!

The extent and detail of the defined requirements should be proportionate to the risk, complexity, and novelty of a system,^4,7 as well as the needs and complexity of the to-be-supported process(es). Requirements typically fall into two complementary categories, as shown in Figure 1:

• Functional requirements: Define what the system must do to support business processes, e.g., acquire data, instrument control, wavelength range, accuracy, precision, and so forth.
• Non-functional requirements: Define the conditions under which the system must operate and may be verified through a variety of mechanisms. For example, standard operating procedures (SOPs), qualification documents, configuration specifications, service agreements, environmental conditions, temperature, humidity, power, etc., and/or other objective evidence.

This is consistent with General Principles of Software Validation (GPSV) section 3.1.1: “A requirement can be any need or expectation for a system.”¹

Well-formed system requirements serve the specific purpose of translating business and regulatory expectations into clear, definitive, and testable or verifiable requirements. This enables system selection, configuration, validation, operation, and use. Alternatively, hasty, poorly written requirements create ambiguity, inflate validation efforts, and introduce invisible compliance risks. We will provide you with a simple, easy-to-understand methodology for writing well-formed requirements.

Figure 1. Examples of functional and non-functional requirements.

What’s in a Name?

What do we call the requirements document? There are several terms:

• User Requirements Specification (URS): The most common term, but it can be misleading and can be taken too literally if it does not accurately reflect the multidisciplinary team effort required to create and maintain the document. Too often, the “U” in “URS” is implicitly narrowed to mean only the laboratory functions. Successfully implemented regulated systems require input from a diverse set of stakeholders, such as lab, IT, QA, etc., which we will discuss later. To be clear, the FDA is aligned with this and defines “user” as “the device manufacturer,”¹ the same as GAMP 5 SE, where “user” is defined as “the organization…not…individuals,”⁴ as well as PIC/S, which states “the company or group.”² It’s also possible to write user stories, but this is not discussed in this column.
• System Requirements Specification (SRS): A withdrawn FDA 21 CFR 11 draft guidance on validation refers to a system requirements specification.⁸
• Intended Use: The Computer Software Assurance (CSA) final guidance refers to “intended use”⁹ but does not mention a URS in contrast with the General Principles of Software Validation (GPSV).¹ 
• Functional Requirements Specification (FRS): As noted above, this document omits the non-functional requirements that are an integral part of any requirements specification. We do not recommend using this term, as it can be misleading. The requirements document should state what the system is required to do; other specification documents (configuration and hardware specifications, and so forth) will define how it should do it.

Why let pesky definitions get in the way? Teams continue to weaponize the “U” in “URS” to pick and choose which requirements to document and which are inconvenient to timelines and resources. Reiterating our advice, management must allow time to develop requirements to ensure the development and refinement of quality requirements.

It does not matter what you call a document if it covers the functional and non-functional requirements outlined in Figure 1 if the term is clearly defined. For the purposes of this column, we will refer to the requirements document as “Requirements Document,” but what you call it is up to you.

Figure 2. Stakeholders in a requirements specification

PIC/s PI-011 states in 8.2 “The organization should regard disciplines related to the introduction of a computerized system” to reinforce early life cycle planning and involvement of all appropriate stakeholders.² Who should be included? Here’s our selection of the great and the good discussed below and summarized in Figure 2:

• Senior Management: As the project sponsor, their requirements are often implicit but should be made explicit to avoid misalignment between operational reality and executive intent.
• Regulated Lab: It owns the system and data, defines functional requirements “fit for purpose/intended use,” and articulates data quality/integrity needs, workflow expectations, exception handling, electronic working, and usability considerations. Many informatics applications assume no problems in operation, but there needs to be a function to record initial deviations and problems rather than record them in a separate system.
• Information Technology (IT): IT contributes requirements related to infrastructure integration, cybersecurity, identity and access management, monitoring, incident response, system integrations, automation interfaces, maintenance, spare parts, and support models. Its requirements ensure that systems function reliably in real-world operating conditions and can be sustained over time. Functions will be covered under a Service Level Agreement.¹⁰
• Quality Assurance (QA) and ITQA: They ensure data integrity and compliance expectations.
• Procurement: It brings commercial and contractual experience that directly influences long-term system viability and overall vendor satisfaction across departments. Include procurement to avoid swapping the selected system/supplier for a cheaper alternative without notice. Procurement should not have the final say on the system selection to save on costs.
• Supplier: The supplier will review the requirements and either confirm that the solution can meet them, suggest alternatives, or determine that some are an input for later enhancements of the system. The aim is to ensure that the supplier will bring manufacturer capability and expertise to support existing requirements and feature enhancement requests to ensure that requirements are realistic.

Core Characteristics of a Requirement

Requirements must state what is needed and should be free of design or implementation bias. They describe what the system must do, not how it should be built based on a system not yet selected. Prematurely embedding technical solutions constrains supplier options and can undermine risk-based decision-making, unless a requirement is a corporate one (e.g., specific database or operating system).

Requirement writing is a disciplined activity that management needs to allow time for. Our list of do’s and don’ts for writing requirements is shown in Figure 3. Core characteristics of a requirement fall into three groups, discussed below:

1. Use Unambiguous, Simple, and Concise Language: Each requirement should convey a single, precise expectation that can be understood consistently by lab users, IT, quality control, suppliers, and testers. Ambiguity is one of the most common root causes of downstream rework. Effective requirements are about 25 words or fewer; if one contains multiple elements, it should be split, as we describe later. Key terms and definitions should be defined in a glossary. Never use “and/or” in a requirement.
2. Requirements Must Be Testable or Verifiable: A requirement that cannot be objectively tested or verified by inspection or review provides little value. Therefore, there should be only one requirement per testable/verifiable outcome. Key terms should be defined consistently across technical and regulatory language. For example, a system log is not an audit trail and they are not interchangable.
3. Requirements Are Standalone, Uniquely Numbered, and Traceable: Each requirement should express one outcome (atomic), with no duplication or contradiction, and be uniquely numbered. Traceability throughout the validation life cycle ensures that what is specified is delivered in the operational system. Traceability is a best practice and a regulatory requirement.⁷ The requirements should be modifiable under a formal change control procedure.

Figure 3. The do’s and don'ts of writing requirements.

Of course, writing the requirements based on these characteristics is the easy part; gathering, eliciting, and/or extracting the requirements (willingly or unwillingly) from a diverse group of stakeholders is another challenge. Requirements must be prioritized and come from understanding the needs of the business and process (not the features), so the focus should be on:

• The business and the benefits the new system will provide
• The problem to be solved
• The outcome to be achieved.

They should not be based on vendor capabilities, preferred solutions, nice-to-have functionality, or price tags. Some techniques you can use may include interviews, workflow analysis, process mapping and redesign, observation/shadowing, and workshops.¹¹ First, draw the information out, then check for accuracy and completeness. Elicitation is iterative and should evolve as understanding is improved and needs are refined. Many deficiencies in requirements documents stem not from poor writing, but from inadequate elicitation. Some sources talk about gathering requirements, but sometimes the process is equivalent to dental extraction.

Incorporating Risk Management into Requirements

Not all requirements require the same level of detail. A risk-based approach, aligned with ICH Q9(R1), helps ensure effort is focused.¹² Critical functionality, that which impacts patient safety, product quality, data integrity, or product availability, warrants more explicit, detailed requirements. Lower-risk attributes or functionality may be described at a higher level without compromising control. Holistic testing and/or supplier development/testing/installation should be leveraged, where possible (provided an adequate supplier audit or assessment of software development supports this). This prevents both over-testing or under-specification.

Figure 4. How to write a well formed requirement.

How to Write a Well-Formed Requirement

The approach to writing requirements we describe now is based in IEEE Software Engineering Standard 1233¹³ and is simple and easy to understand and apply. The process takes a raw requirement and turns it into a well-formed requirement by applying the 3 Cs, see also Figure 4:

• Capability: States what the system must do and is solution-independent.
• Condition: Makes the requirement either testable (in the user acceptance testing or performance qualification) or verifiable (traceable to a report, procedure, or qualification activity, elsewhere in the lifecycle, etc.).
• Constraint: Imposed on a requirement by compunction e.g. corporate requirement, standard, or regulation. Note that constraints can be requirements in their own right. For example, they must use a specific database or operating system.

Theory is fine, but how does this work in practice? Let’s work through an example on passwords applicable to all spectrometer systems:

• Capability: An authorized user accesses the system with a password.
  As written, the only test that can be applied is whether the user has a password. This is about as much use as a bucket with a hole.
• Condition: We have a number of options here, such as password length and/or complexity, to add to the capability. For example: with a minimum length of 15 characters consisting of uppercase, lowercase, numbers, and special characters. This condition will be found in the update to Annex 11 in section 11.5.⁶
• Constraint: Here we have a constraint imposed by 21 CFR 11.300(b) for password aging,³ requiring it to be changed every 90 days.

Adding the 3 Cs together, we have a potential password (don’t forget that requirements must be numbered to ensure traceability throughout the life cycle Annex 11 4.4⁷):

• An authorized user accesses the system with a password with a minimum length of 15 characters consisting of uppercase, lowercase, numbers, and special characters that expires every 90 days.

Remember that constraints can be requirements in their own right, therefore we can split this into two requirements:

• An authorized user accesses the system with a password with a minimum length of 15 characters consisting of uppercase, lowercase, numbers, and special characters
• Passwords will be changed every 90 days

Now, let’s add a dash of practical risk management. Password complexity does not add any value and causes more IT administration problems when users forget passwords. NIST Special Publication SP800-63B 2017 and 2025 editions^14,15 state that analysis of security breaches does little to ensure security, and complexity may lead to users writing passwords down. Therefore, password length is the key here, coupled with a low number of access attempts. Furthermore, despite the Annex 11 update stating that users should not use dictionary words, NIST publication says you can. This column has discussed passwords and the 2017 edition of the NIST standard previously.¹⁶

We can now rewrite our requirement as follows: An authorized user accesses the system with a password with a minimum length of 15 characters.

Let us go further and look at password expiry. The NIST publications state that there are only two occasions when you need to change a password:

• When a user forgets it
• When passwords are compromised and all users need to change them.^14,15

Now we can imagine readers in QA having minor heart attacks because Part 11 says passwords expire³—we must obey! Think risk management! You have a regulation written nearly 30 years ago vs a NIST publication less than a year old. Our advice is to follow the latter and justify it.

Let’s assume QA or even corporate IT insists on a 90-day expiry. Will you test this? Ask yourself, how does a computer calculate time? It requires a trusted time source on the network, which sets and adjusts the system clock. How does your computer tell the time in between network time checks? It counts the vibrations of a piezoelectric crystal. If you want to test password expiry, you are testing the ability of the computer to count. Still want to test password expiry? We thought not: Exclude it from testing with a reason.

Weasel Words Make Requirements Untestable

A common way to make a requirement untestable is to use a weasel word; see Figure 3. Confused? Let us explain, these words may appear impressive in a requirement, but make the requirement untestable. We would like to provide two case study examples from a specification to illustrate this:

“Operating at normal PC response times with no undue delay in response at low computer utilization.”

This requirement has three weasel words that raise questions about what is:

• A normal PC response time?
• No undue delay?
• Low computer utilization?

Our next example snatches defeat from the jaws of victory by adding four words that make the requirement untestable:

“Report production at least every 1 page every 10 seconds at modest network utilization.”

Have you ever seen an immodest network? Incidentally, the requirement is focused on printing, but does not say so explicitly.

Copying Regulations as Requirements

We mentioned earlier not to copy regulations as requirements. To illustrate why, let’s look at the ever-popular regulatory requirement: The system will be 21 CFR 11 compliant.

How will you test or verify this?

First, remember that the regulation has three types of control: administrative, procedural, and technical, shown in Figure 5. Is the supplier going to fulfill your administrative and procedural requirements, such as verifying the identity of your lab staff? Send a letter to the FDA stating that e-signatures are the legal equivalent of handwritten signatures? Or, heaven forfend, you expect the supplier to write your SOPs. Good luck!

Figure 5. Some 21 CFR 11 technical, procedural and administrative controls.

Furthermore, are you going to use electronic signatures as part of your laboratory digitalization project? We thought not! Using the system as a hybrid is the worst option, but your requirement implies you are working electronically. It’s even worse if your selected system does not have an audit trail.

Our advice: don’t copy regulations and use them as the basis for your requirements. Read, understand, and extract the applicable parts of the regulations that you need, justify what doesn’t apply to your system, and use the 3 Cs methodology to write your testable or verifiable requirements.

Intelligent Reuse of Requirements

Until now, we have considered a single spectrometer system, but many labs have different spectrometers and other computerized systems. All will need a requirements document. Can we reuse requirements from one spectroscopy system in another? Yes! But, you need to do this intelligently.

The first stage is to have a standard template for a requirements document; an example is shown in Table 1.

There are eight sections, each with an outline of its contents. The right-hand column is a generalized assessment of whether intelligent reuse of requirements is feasible. Where requirements are unique to a specific system, for example process, interfaces, and data migration, there is little point in considering reuse of requirements. Section 1 can reuse the referenced documents section only.

Intelligent reuse of requirements can be considered for other areas of the specification. For example,

• Time and date stamp requirements can be reused in section 4, provided that the system supports the required company format.
• For audit trails, there is little point in specifying system and data audit trails if the selected system has just a single one or vice versa.
• IT requirements in section 6 come closest to copying and pasting, if there are standard services for IT support.

However, still read and check them: don’t assume all requirements are acceptable.

Table 1. A suggested requirements specification outline highlighting areas for possible re-use of requirements*

We have discussed writing well-formed requirements manually but the elephant in the room is artificial intelligence (AI). Can AI help writing user requirements? Possibly. It depends on how the AI application is trained: trawling the Internet or trained using in-house material? Slop vs. fact or hallucination vs. reality? AI preparation of a generic URS for critical review and update by a validation team can be achieved now. You must ensure that the URS used for selecting the spectrometer system reflects your needs and intended uses. Using it for formatting, document standardization, consistency and helping meet the characteristics defined in this article can be beneficial as the allocated resources can move from formatting to thinking and governing.

Remember this is a section on intelligent reuse of requirements. Understanding the minutiae of processes in an individual laboratory, their analytical procedures, the interfaced spectrometers and the how the configured application will automate them, may be an AI step too far.

Further Reading

While writing this article, we found the following references useful:

• Karl Wiegers and Joy Beatty, Software Requirements, 3^rd Edition¹⁷
• A Guide to the Business Analysis Body of Knowledge¹⁸
• CMMI® for Development¹⁹
• ISO/IEC/IEEE 29148:2018: Systems and software engineering — Life cycle processes — Requirements engineering²⁰
• ASTM E2500-25: Standard Guide for Specification, Design, and Verification of Pharmaceutical and Biopharmaceutical Manufacturing Systems and Equipment Science and Risk Based Approach.²¹

Conclusion

The quality of a system implementation is rarely better than the quality of its requirements. It doesn’t matter what you name the document, as long as it defines and covers the intended use of the system. Changing the document name without fixing vague, untestable requirements is not progress. What matters is that requirements are unique, complete, testable or verifiable, risk-based, and kept living to enable compliance, traceability, sustainability, and business value.

Regulated companies should document and implement appropriate controls to ensure that data management and integrity requirements are considered in the initial stages of system procurement and throughout the system and data life cycle.

Whether or not an organization decides to leverage artificial intelligence or the use of validation management systems for writing requirements, we want readers to understand and have the knowledge to write and review testable or verifiable requirements. This provides the knowledge needed to review AI-generated requirements.

Remember, this is the most important document for ensuring that any computerized system provides business benefit, is correctly selected, and can be validated easily. What you call the document is up to you, but it needs to be written at the start of a project, and management must allow sufficient time for this.

Biography

Monika Andraos is the founder of Dunamis Compliance, bringing over 14 years of expertise in data integrity remediation, risk management, data governance, and computer systems validation within the pharmaceutical industry. Holding a B.S. in neuroscience (cellular and molecular) and an ASQ Quality Engineer certification, she combines regulatory knowledge with emotional intelligence and neurobiology to deliver impactful, compliant data-integrity solutions.

R D McDowall is the director of R D McDowall Limited and the editor of both the “Focus on Quality” column for Spectroscopy and the “Questions of Quality” column for LCGC International, Spectroscopy’s sister magazine.

Acknowledgments

We would like to thank James Henderson, Mahboubeh Lotfinia, and Yves Samson for their constructive review of our article.

References

1. Food and Drug Administration. Guidance for Industry: General Principles of Software Validation; Food and Drug Administration: Rockville, MD, 2002.
2. Pharmaceutical Inspection Convention/Pharmaceutical Inspection Co-operation Scheme. Good Practices for Computerised Systems in Regulated “GXP” Environments (PI-011-3); PIC/S: Geneva, 2007.
3. Food and Drug Administration. 21 CFR Part 11: Electronic Records; Electronic Signatures—Final Rule; Fed. Regist. 1997, 62 (54), 13430–13466.
4. International Society for Pharmaceutical Engineering (ISPE). GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems, 2nd ed.; ISPE: Tampa, FL, 2022.
5. World Health Organization. WHO Technical Report Series No. 1019, Annex 3, Appendix 5: Validation of Computerised Systems; WHO: Geneva, 2019.
6. European Commission. Stakeholders’ Consultation on EudraLex Volume 4—Good Manufacturing Practice Guidelines: Chapter 4, Annex 11 and New Annex 22; 2025. https://health.ec.europa.eu/consultations/stakeholders-consultation-eudralex-volume-4-good-manufacturing-practice-guidelines-chapter-4-annex_en (accessed July 7, 2025).
7. European Commission. EudraLex—Volume 4: Good Manufacturing Practice (GMP) Guidelines, Annex 11: Computerised Systems; European Commission: Brussels, 2011.
8. Food and Drug Administration. Draft Guidance for Industry: 21 CFR Part 11—Electronic Records; Electronic Signatures Validation; Food and Drug Administration: Rockville, MD, 2001.
9. Food and Drug Administration. Guidance for Industry: Computer Software Assurance for Production and Quality Management System Software; Food and Drug Administration: Silver Spring, MD, 2026.
10. Lotfinia, M.; McDowall, R. D. What Goes in a CDS IT Service Level Agreement? LCGC Int. 2025, 2 (3), 18–27.
11. McDowall, R. D. Can We Simplify Data Process Mapping? Spectroscopy 2024, 39 (7), 20–26.
12. International Council for Harmonisation of Technical Requirements for Pharmaceuticals for Human Use. ICH Q9(R1): Quality Risk Management; ICH: Geneva, 2023.
13. Institute of Electrical and Electronics Engineers. IEEE Std 1233-1998: Guide for Developing System Requirements Specifications; IEEE: Piscataway, NJ, 1998.
14. Grassi, P. A.; Newton, E.; Fenton, J.; Perlner, R.; Regenscheid, A.; Burr, W.; Richer, J.; Lefkovitz, N.; Danker, J.; Choong, Y.-Y.; et al. NIST Special Publication 800-63B: Digital Identity Guidelines: Authentication and Lifecycle Management; National Institute of Standards and Technology: Gaithersburg, MD, 2017.
15. Temoshok, D.; Choong, Y.-Y.; Regenscheid, A.; Galluzzo, R. NIST Special Publication 800-63B-4: Digital Identity Guidelines—Authentication and Authenticator Management; National Institute of Standards and Technology: Gaithersburg, MD, 2025.
16. McDowall, R. D. Pesky Passwords? Spectroscopy 2018, 33 (11), 20–23.
17. Wiegers, K.; Beatty, J. Software Requirements, 3rd ed.; Microsoft Press: Redmond, WA, 2013.
18. International Institute of Business Analysis. A Guide to the Business Analysis Body of Knowledge, Version 1.3; IIBA: Toronto, Canada, 2015.
19. Software Engineering Institute. CMMI for Development, Version 1.3; SEI: Pittsburgh, PA, 2010.
20. International Organization for Standardization. ISO/IEC/IEEE 29148:2018: Systems and software engineering — Life cycle processes — Requirements engineering; ISO: Geneva, 2018.
21. ASTM International. ASTM E2500-25: Standard Guide for Specification, Design, and Verification of Pharmaceutical and Biopharmaceutical Manufacturing Systems and Equipment Science and Risk-Based Approach; ASTM International: West Conshohocken, PA, 2025.