Managing your software requirements is probably one of the activities you’ll spend your most time on. So what the hell are software requirements? In short, it’s a list of features your software has and how it behaves. Old dinosaur people might call this a “specification” – people say that, a hundred (or fifty) years ago, these sort of specifications were written out before developers would start writing code. While that sounds crazy, it was rational at the time, because writing code was slower than writing specifications.
Nowadays, humanity has moved on, and writing code is often faster than writing specifications. That being said, the medical device regulators are still stuck somewhere between the stone age and modern times, so you need to write out your software requirements.
A quick note: If you’re developing a hardware device in Formwork, the term is called “Design Inputs” and not “Software Requirements”; this is also how Formwork displays it, too.
Click on “Products” in the top menu, and “Software Requirements” in the left menu. Let’s get started!
Here’s how a list of Software Requirements might look like:
As you can see, there are individual Software Requirements (SWR-1, SWR-2, etc.), but also something we call “Systems”, i.e. the grey boxes which contain them: Frontend, Hardware, etc. – they can also be nested, as you can see with the “Medication Feature” system. So Software Requirements are essentially just a list of things which can be grouped. Cool. Let’s create a new Software Requirement, shall we?
Click on “+ New” in the top right corner. You’ll be greeted by this form. It’s a bit lengthy, but don’t worry! Formwork will hold your hand and guide you through everything.
Here’s what you can fill out:
- System: This is the “grouping” we saw earlier. If you’ve created a system (group) and want this requirement to belong to it, select it here.
- Category: These are categories as defined by the IEC 62304, the standard for medical device software development. Examples are “Functional” (use this for most requirements), “Interface”, etc.
- Internal ID: This is automatically assigned, but you can change it, if you like (there’s no rational reason to do so). Each requirement needs a unique ID.
- Title: Short title of the requirement which will be shown in the list.
- Description: Longer-form description of the feature.
- Below that, you can link your Software Requirement to one or multiple of each of these things:
- Software Detailed Designs: Only displayed for class C devices (chances are you’re not class C). Link this Software Requirement to one or multiple Software Detailed Designs.
- Stakeholder Requirements: Link your Software Requirement to one or multiple Stakeholder Requirements.
- Failure Modes: Link it to Failure Modes for your risk management (ISO 14971) compliance.
- Software Tests: Link it to Software Tests to show that you actually will be testing this requirement.
- Risk Controls: Link it to Risk Controls for your risk management (ISO 14971) compliance.
So that was a lot of stuff. What should you fill out, and what’s optional? Let’s take a look.
| Field | Mandatory / Optional | Reason |
| System | Mandatory | Not every Software Requirement needs to belong to a system. For class A software, you technically don’t even need systems. |
| Category | Mandatory | As per the IEC 62304, each requirement should be associated with a category. |
| Internal ID | Mandatory | As per the IEC 62304 (and for your own sanity), each requirement should have a unique ID. |
| Title | Mandatory | How the hell do you manage requirements without titles? |
| Description | Optional | Some requirements might be so simple that only the title is sufficient. Other requirements might need more details. Might also depend on your auditor. Please don’t over-engineer here, only as much details as required. |
| Software Detailed Designs | Not displayed for class A and B devices. Mandatory for class C devices. | As per the IEC 62304. |
| Failure Modes | Optional | Not every Software Requirement can lead to a failure. Only link Failure Modes to Software Requirements which can actually have failure modes. |
| Software Tests | Optional | While this field is technically optional, every Software Requirements should be covered by a test. Feel free to leave it empty for now, but definitely come back once you’ve defined at least one test which covers this requirement. |
| Risk Controls | Optional | Not every Software Requirement is itself a Risk Control. Quite the contrary, it’s rather rare. |
So I hope that cleared things up a bit. As you can see, I’m walking a fine line here between getting this post done and not diving down a million rabbit holes on what the hell all of these things are – check out our other articles for pointers on what to actually write in your documentation. This is the Formwork Manual, so I’ll try to stay on topic and move on!
One more important thing to keep in mind is that you can edit Software Requirements at any time. So don’t stress out if you e.g. haven’t created a Software Test yet which you can link to this requirement. Just go ahead and save the requirement first and come back later.
So hit “Save”, and you’re done, for now!
The requirement is now neatly displayed in the list you saw above. You can also drag and drop it if you’d like to re-order things. Cool!
Versioning
All Techdoc items (that includes Software Requirements) are versioned in Formwork. What does that mean?
It means that an auditor might roll up to your company and say “hey dudes, please show me the list of Software Requirements for <ancient version of the software 2 years ago>”. And you need to have that list.
So, in Formwork, this is easy: On the left side, select the old version number, and you’ll be presented with the Software Requirements list at that point in time. Magic! (This, by the way, is why Jira sucks: It doesn’t have proper versioning.)
You can create a new version any time, but you probably only want to do that once all your documentation is complete and you’re bringing that version of your product to market (or submitting it to your auditors).
Sending Software Requirements For Review
Just before your documentation is done, you’ll want to send your list of Software Requirements for review. This is a regulatory requirement, because, at the very least, you need some documentation that you checked your Software Requirements for completeness. To do that, click on the “send it for review” link at the top of the Software Requirements list.
Check out our article on Reviewer Roles to see how reviews work and how to configure them.
