(Circle of LabVIEW: Part 3 of 6)
This is Circle of LabVIEW: Requirements, the third of a series of blog posts that describe different stages of the LabVIEW project life cycle from idea to market. Although reading them in order will help understanding the bigger picture, each blog post is self-contained with a small section regarding the "RT Installer," a kind of sample product used in this series.
This blog post aims to describe the process that happens around the time a project is bid and awarded; it focuses on the process of generating requirements that can be used to capture project scope and later verified.
Once we’ve spoken with a client and hammered out a rough scope, we have enough information to generate an estimate in terms of time and budget and generate a proposal. Fortunately, the project is out of ”project purgatory,” but the proposal isn’t enough to verify that the product or project works.
There isn’t an objective way for us to know whether this project or product functions as expected during the conception phase; to solve that problem, we create a document called a System Requirements Document. What this document does is refine or focus scope, identifying key points of functionality, spelling out how things should work given certain circumstances and most importantly, a list of verifiable requirements that can be used to verify functionality.
A requirement translates client expectations/scope into technical requirements that can be used to plan software development and later used during software acceptance testing to objectively verify functionality. A good requirement is best described as being concise, atomic, unique, and verifiable.
Below are some example requirements:
- If pressure (PT-001) is greater than the over pressure limit(LIM-001), software will trigger over-pressure alarm (ALM-001)
- Software can control pump manually and automatically
Now, let's analyze both examples:
If it’s not obvious, the first requirement is good because it’s atomic; it only describes one functionality, while the second requirement describes two. The first requirement is very concise. It tells what pressure it’s referring to, what limit it’s referring to and what interlock it’s referring to; there’s no ambiguity.
In contrast, the second requirement doesn’t indicate what manual, automatic, or control means. It’s generally impossible to verify requirement 2.
Good requirements can be used to plan software development. For example, requirement 1 above can be used to generate the following tasks to complete during development:
- Acquire current (PT-001) using a data acquisition device
- Using gain/offset convert PT-001 from mA to engineering units
- Create logic that can compare PT-001 in engineering units to the over-pressure limit (LIM-001) and trigger over-pressure alarm (ALM-001)
The requirement can be verified by setting the over pressure limit to a known value, then causing the pressure to be greater than that limit and confirming that the interlock is triggered. Once requirements have been put together, it’s safe(r) to start software development since you now have a clear scope.
After the proof of concept for the "RT Installer" was completed, we wanted to put together a requirements document to capture the expected scope and give us something we could use to verify functionality during and after software development.
Check this 20-page PDF of the requirements document put together for the "RT Installer":
