I am currently tasked with creating a software architecture for compliance with IEC 62304. These regulations are notoriously vague, and do not provide any real substance as to what is required for a "software architecture". The standard states

The manufacturer shall transform the requirements for the medical device software into a documented architecture that describes the software's structure and identifies software items.

Now I went to an applied computer science school, so the vast majority of my teachings were around how to actually write code and working on projects, so as far as I can remember, we never covered anything involving creating software architecture diagrams.

I've already basically written all of the software, but for regulatory submission purposes I need to create this documentation for the project.

So in short my question is this: What exactly does a "software architecture" consist of?

  • You might also want to have a word with your quality people - the folks who write all your SOPs and such. They may be able to help you get a handle on what the standard means, as they are probably more used to reading standards than you are. Commented Mar 5, 2013 at 18:58
  • @MichaelKohne Unfortunately, software within medical devices is a new field for my company, so we don't have any established practices as of yet, I'm kind of the Guinea pig. I had to draft the SOPs from the applicable standards, and from a purely software engineering background, it isn't easy
    – Dan F
    Commented Mar 5, 2013 at 19:06
  • Oh fun. Are you in the US? I work for a medical device manufacturer (EEG machines), and I think that pure software products are viewed as 'devices' by the FDA (though I could be wrong). If you are in the US, you REALLY should get someone with expertise (there are consultants for this kind of thing) to come in and go over your procedures and such before you start selling products - they'll make sure you've got at least a stab at being in the right position if the FDA comes calling. Commented Mar 5, 2013 at 19:17
  • @MichaelKohne I did try suggesting that to my boss, but I guess the company wants to try and handle it ourselves first before shelling out the money for the consulting
    – Dan F
    Commented Mar 5, 2013 at 19:19
  • Ohh. Umm, you want to be REALLY careful on that - an FDA audit could be seriously damaging if you aren't reasonably close to being in compliance. Consultants are expensive, but flunking an FDA audit could be much more so. Are you selling for patient use, or for research use? You can get away with a lot more if it's for research only. Commented Mar 5, 2013 at 20:21

3 Answers 3


We're going though the 62304 learning curve right now.

As the previous answer suggests it is just the high-level view of your medical device software.

According to the standard you should at minimum list the various modules/components. Components are defined as being made of software items. However, how you define components and items is entirely up to you.

In our case, products often have one component and rarely more than three.

In the case of a engineer-workstation-based GUI project, we have four component. The GUI, the product logic, and an existing DLL we are required to integrate, and the underlying mathematical modelling engine that the whole system is based upon.

The architecture consists of

  1. description of the GUI,
    • basically a list of screens and their associated workflow
    • a description of the objects(software items) associated with each screen
  2. a description of the product logic
    • a description of the state machine, and how it interacts with the GUI workflow
    • a description of the state machine class (a software item)
    • a description of the mathematical-modelling operations being performed for the client. (broken down into stages - each stage is a software item)
  3. a description of a required DLL, its SOUP status, etc. (one software item)
  4. a reference to another software component developed under 62304

One thing to bear in mind is that (despite the heavy implication of the way the 62304 standard is written) you don't have to create the architecture diagram up front and then fix it in stone in a waterfall coding model. The FDA have encouraged the use of more agile approaches, allowing you to develop the architecture along with the code, so long as your validate the final architecture against the final design. So start with a simple architecture that allows you to make progress, and keep it up to date as you develop the code. See the AAMI's TIR45 publication for some documented justification.


Software Architecture looking at the software from a high level. This will focus on how different software components interact with each other. It also consists of how outside systems can interact with your software system, or if you even allow outside systems to interact. If you think of how a building architect does by designing a building, a software architect will design a software system. This involves documenting the software system. Some examples of how to document would be to create a requirements document, use case document, class diagram, state diagram, interaction diagram, help files to name a few.

As far as how much detail to use, I would say you will want to use enough to effectively portray what the system is supposed to do and what different messages mean when the system is not doing what the client is trying to do. They will need help documents and a glossary of terms, specially error messages.

For your team, I would use the requirements and other various documents to specify how the system works. This will help greatly with maintenance and enhancements. The requirements will help guide the team to determined when you have a finished, working product.

  • As far as a "software architecture" is concerned, what exactly is considered a "software component"? My software isn't particularly complicated, it basically consists of a UI for entering user information, and a second UI for controlling the device
    – Dan F
    Commented Mar 5, 2013 at 19:21
  • It is everything that goes into your software system. Both user interfaces and how it interacts with the device would be part of your architecture. Also any 3rd party components and/or any other components that are written that are not part of the two user interfaces.
    – DFord
    Commented Mar 5, 2013 at 19:33
  • How fine-grained should I be with my breakdown of the system? Is it purely discretionary, or would breaking it down to each individual UI element be required? Sorry to be asking so many questions, I just really have no idea what I am doing with this, and you seem to be helping out so far
    – Dan F
    Commented Mar 5, 2013 at 19:40
  • @DanF I added more to the answer that I think will help you.
    – DFord
    Commented Mar 5, 2013 at 19:52

The standard is vague. But the expectation is that your QMS processes will be structured to define how your organization uses those documents. You define the requirements for the document, how those documents will be used and maintained. To reenforce that point, the Paperwork Reduction Act (PRA) of 1995 is to ensure that Federal agencies, including the FDA, do not overburden the public with federally sponsored information collections; the information required serves a useful purpose. The FDA has very general goals, but if the architecture document contents don't serve a real purpose it is not required.

So a software architecture document (IMHO) must serve a set of requirements in a project. The general needs of the FDA may be met, I think, if the document:

  1. Communicates a useful ideal of the scope of a design to a reviewer, or new worker familiarizing themselves with the product.
  2. Defines independent functional blocks within the design. Independent both in the sense of independently specified, designed, and, tested components of the design.
  3. Identifies testable interfaces to each component in the design.
  4. Defines consistent terminology that is used in the project to refer to the components of the design.

The architecture document should be a primary reference when the project subdivided the work and should be reflected in the cognizant engineering skills of leads in the group, sections of the documentation, and how V&V is approached.

This is not a requirements document, though. It should give a context and vocabulary for the pieces and the processes in the box, but the requirements document should provide the meat for the functions and the testing required.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.