Item — HN Reader

Great article that I would have loved to have read 5 years ago. I work in med tech and have to develop software according to the IEC 62304 standard. I was responsible for designing our software development process and when reading the standard I had no idea what these concepts (requirements, traceability, etc) meant in practice. Initially I thought these were outdated concepts (the standard was written in 2006 and now everyone is cool and agile). However, after dozens of releases and team composition changing all the timeI definitely see the value in theory. In practice many companies have bad requirements and no proper requirements management systems, so for them the standard is probably more of a burden.

Anyway, would have loved to read this much more positive view of requirements systems before, so I would have tried to build something beautiful instead of shoehorning the IEC standard into our existing process.

2 comments

A pity. For me the IEC 62304 is one of the standards who make the most sense.

For me traceability has one more very nice aspect: you always trace whatever you do (think merge request or it deployment request / changes) back to the reason/authorization why you do it (think project, change request, defect, ...). Like that you are never in the limbo why you do something. Especially in regularity domains that is a must have but honestly i would not run a company otherwise. Because it also ensures that money is spent where you want it. With or without requirements in between them.

The article focuses more on requirements but I think that traceability is at least equally important -- Why (what is the justification) to include feature X (in this way)? If this is disregarded it becomes difficult to work economically towards a goal. Unfortunately, it is often the way things are done because a) people want to satisfy their curiosity and "play" around with new things (which is fine if kept in check), b) problems are complex or poorly understood and doing something is easier than finding out.