When we talk about software, the saying “garbage in garbage out” applies both for data and its requirements. And if you write a poor user requirements specification, the result will be a poor software.
It’s not a wild conclusion: feeding a software with bad data will result in badly processed data.
So, with this post, we want to give you some tips about what we think is the proper way to write your URS and its application in CSA. Let’s start!
But Where Do We Start?
First, we need to look into the GAMP® 5 reference for the SDLC (Software Development Life Cycle) which is the ASTM E2500.
In there, it clearly states that the foundation of the requirements specification document is based upon product knowledge, process mapping and understanding, regulatory requirements and company quality requirements.
What Is the Point for the User Requirements Specification?
It’s actually a key point: it provides the software developer with a clear statement of what the computer system should do.
Let’s think outside the CSA box for a second. Pretend you are ordering a yakisoba, but you don’t like onions. Would you forget to tell the cook that you don’t eat onions? How would the cook know your preference?
Here we have the same situation.
The software developer can’t guess what you need. In fact, he doesn’t have the obligation to understand your products, processes, regulatory requirements, and quality requirements. Your job is to make them clear to them.
Writing User Requirements Specification Can Be Simple
We prepared a few tips to help you improving your user requirements specification:
- Don’t forget to provide an overview of your products. Include their manufacturing process and list all the regulatory and quality requirements;
- Start with a process statement: Where does the solution fit? Why do you need the software? What do you expect as final outcome?
- Always use diagrams and workflows;
- Start your requirement with a verb. For example: “calculate the difference between X and Y and present in the screen with the label XXX” or “capture a digital sign from the PLC with the current setting for pressure each 60 seconds”.
- List the data that will come in, and describe the processing and storing/presenting of the results;
- Explain your formulas, calculations, and algorithms. And, most importantly, where the results will be used and its impact in the process / product / regulatory requirement / quality requirement;
- Keep it simple, go straight to the point. Too much information only creates confusion;
- Avoid the use of acronyms and terms that only your company uses. If you really must, don’t forget to explain what they mean;
- Classify your requirement according to its source (e.g. business process, regulatory requirement, usability, availability, etc.);
- Prioritize your requirement (e.g. mandatory, important, desirable),
Of course, this is not a complete list of best practices. But we think that it is a good starting point.
Don’t Forget to Involve All Your Company’s Key Areas
It’s important to involve all the key areas in your company so that you can provide the most accurate answers to the following:
- What products are affected by the usage of this computer system?
- What are the critical quality attributes of those products?
- How will the computer system affect those critical quality attributes?
- What are the regulatory rules applied to the process(es) affected by the computer system?
- What data will be captured and/or processed by the computer system?
- Which data captured and/or processed by the computer system is subject to regulatory inspection and retention?
- What are the know issues related to the products and processes affected by the usage of this computer systems?
We Can Support Your Computer System Validation
If you want to know more about how can we help you managing and improving your computer system validation, check our CSV/CSA solution and don't hesitate to reach out.
