If you’re building custom lab software or a new integration, the first thing you need to do is gather a list of requirements. In our work with clinical NGS labs, we start every engagement with an assessment of the current state and gap analysis. It’s our role to help lab staff translate their knowledge of the lab and its processes into requirements that can be used for software development.
- Complete
- Correct
- Feasible
- Necessary
- Prioritized
- Unambiguous
- Verifiable
Our field application scientists work with lab staff to tease out the lab’s requirements and write them in such a way that they effectively represent the lab’s needs. This means taking into account four things that can have a big impact on the requirements.
1. The need or goal of the software
A key question we ask labs is: What is the need or goal of the software?
- To make lab workflows more efficient.
- To reduce errors.
- To eliminate manual data transcription.
- To remind people to do a task.
For example, a lab might say that it wants to record information from a TapeStation system into the laboratory information management system (LIMS). That sounds like a simple requirement, but it’s actually more complex than you might initially think.
We could store the data as an attached file or we could take data from the file and store it in a table or database. If we use an attached file, what if the user uploads the wrong type of file or the wrong TapeStation data? To confirm the correct file is attached, we need a requirement that describes TapeStation data. We need to know if we can verify it against a barcode or the sample names.
It takes several iterations of requirements to cover all these scenarios and ensure we are meeting the lab’s objectives.
2. The ratio of happy path to unhappy path occurrences
Initial lab requirements often describe the “happy path.” In software development, this refers to the default scenario, during which no errors or exceptions occur. How frequently this happy path occurs — whether it’s 50%, 80%, or 99% — affects how the requirements are written.
For example, if there’s a high error rate for a given task, you’ll need to build in significant data validation. If users routinely upload the correct data and there are no errors 99% of the time, less data validation will be required. Depending on the error rate, you might also need to include a mechanism for human intervention and override.
The happy-path/unhappy-path ratio will dictate what validation functionality is required within the software’s user interface.
3. The sample throughput level
Throughput highly influences how much effort should be invested in automation, whether it’s liquid handling or LIMS automation, and is a very important consideration when building requirements. It also affects how your software should handle sample pass/fail and what information the software needs to display.
Labs that have low throughput (for example, a couple of plates each day) will likely have a pass/fail requirement of close to 100% — almost every well on a plate will be required to pass. Medium-throughput labs might have a lower threshold. With ultra high throughput, the threshold might be measured differently, with labs seeking to reach a quality control level that is measured over the span of a week at a time rather than on a plate-by-plate basis.
As such, the level of throughput, whether 2 or 20,000, can affect software requirements significantly. Because the lab’s focus is different in each case, what the lab quality staff need to see on their software dashboard is also different.
Low throughput labs might not need a dashboard at all. Some labs might need a view of how many plates have been processed, the reagents, operators, and which liquid handling robot was used. Other labs might just need a graph of the number of samples that met the quality threshold because they want to know if there is any sort of systemic failure requiring their attention.
4. Any anticipated changes to the lab’s tools or processes
When we’re gathering software requirements, labs sometimes overlook their plans to replace a tool or change a workflow or they aren’t aware that these types of changes will have an effect. For example, while they might be using one robot to do the DNA extraction now, the lab plans to purchase a new robot for this task within the next few months. This type of information can make a huge difference to software requirements.
Obviously, as a lab’s business evolves, there will always be changes. Our goal in writing the requirements is to consider these events and the impacts they might have, such as how long it will take to make a programming change and how much that might cost. For small changes, it might be something we tackle later, while for bigger changes, we might want to ensure current requirements will also future-proof the lab.
One way we might do this is by choosing to implement an indirect integration using a CSV file, knowing that it works with the lab’s current workflow but can also be used with instruments the lab intends to purchase. Knowing a lab’s plans means we can also reach out to the different product vendors to ensure the requirements won’t need to be completely revised to accommodate a new tool — that’s a software engineering best practice. Plus, it can be more cost-effective in the long term.
The value of field application scientists
Having field application scientists at Semaphore means we’re in a better position to help labs translate their needs into effective software requirements. We can work with the labs to understand how their business works, what their workflows look like, and how they plan to grow — and we can transform those high-level requirements into detailed, unambiguous software requirements.
If your lab is looking to work with a software consultant, we highly recommend asking about their requirements gathering process. You want to be sure that they understand the complex needs of clinical NGS labs and know how to map those to software requirements.
