Requirements management in dev tool (Jira, DevOps, Git etc)

[drm71]

What experience do people have with this, I am working on some projects and for the first time bumping into the concept of SW dev teams managing the requirements for a MDSW themselves somewhat "silo'd" and using traditional development tools for requirements. This results in exported requirements reports that come out from user stories (eg in DevOps) and they messy, as in vague, incomplete and hard to qualify as "requirements" (this is kind of a separate issue), previously I am used to requirements being drawn up by a cross platform group including R&D, QA, SW etc starting from User Requirements and breaking down into Product Requirements (which may include SW or sometimes SW reqs can become a separate section of this), with ongoing risk management, identifying risk control requirements etc, then verification is linked to requirements which are linked to risks where approrpriate, and validation of user reqs via system level testing by users on production software.

I guess it's possible to setup "developer type tools" to handle this but it seems like it is only causing problems. Especially as some of these companies seem to add their own requirements / testing and the export of "the current requirements out from their dev tool is a kind of after the fact deliverable.

Is it possible to set up a properly controlled documentation on the outside as I am used to seeing and then have developers map their setup to this? (I am thinking that it might be easier to get them on board with this), or is it just wasting time and it's best just to start over and move the documentation and management of risks and requirements into the QA controlled system and as an input to developers? I get the feeling that the developers are used to working in non med tech projects and base their workflow around typical developer practices that might be efficient for them but seem like a clumsy and difficult fit for medtech regulated environments. But maybe I am wrong?

 

[wesselkooyman]

I often see Jira for requirements management in startups. Sure, you can do it, but in the end, traceability will never work in a 62304 compliant way. I currently have a client that uses a Jira plugin called RTM, which allows you to manage requirements and test cases. This is already much better than vanilla Jira but you'd have to manually do the traceability to risks in Excel.

Once Excel enters the picture, it always becomes a mess.

So i'm currently migrating them to a proper ALM.

 

[Tidge]

I am a strong believer that unless the development team understands what a tool is for, trying to enforce (regulatory) compliance on a development team through the use of a tool is a fool's errand. Similarly I don't buy high-end shop tools for rank amateurs... unless a professional knows what they want to do and can see how a certain tool makes their job easier, giving them a complex tool just means it will either not be used correctly, or not used to its full value.

I would do traceability on "paper" first. If a team can't master what traceability is using paper, then they will get into trouble when it comes to automated tools. I witnessed a large team of highly paid professionals waste years of time trying to establish a perfect system of traceability for development (within multiple tools) instead of working on their actual product development.

Specific to Software Development team tools: I do think that Jira can work really well for issue-handling. Issue resolution is extremely close to what developers (i.e. programmers) actually have expertise in (i.e. coding) and it doesn't take much oversight from a non-programmer (i.e. project manager, software QA) to manage individual issues in (a default?) Jira configuration. IIRC there was a default issue-handling workflow that was pretty good about enforcing good software development discipline.

 

[drm71]

Thanks! This is reassuring, I agree that issue tracking can be great here, I am used to seeing Github with dedicated anomaly repos with issue numbers which can be listed in release notes, linked to pull requests and version tags etc.

My problem here is I want to try to (in a nice way) explain to the developers that using DevOps for requirements and exporting fluffy "requirements docs" based on what look more like user stories and test cases (and implementation descriptions!) is not the way, and it would be better to give in to QA and have proper requirements documents "on paper" linked to risks and under the control of QA and change procedures.

So I was also hoping to get a bit more confidence that they won't turn around and say "but we can do just as well within DevOps using this and that and this and that".

It doesn't seem like it's working well for them and it definitely won't fly once they move over to IVDR regulated products, I think there are other issues related to cultural/political differences to be addressed (it's hard to know what to say when you try to explain how notified bodies work and how audits try to follow through your objective evidence that you are compliant and safe and the replies are that they don't trust auditors, and feel like because they change their minds their comments aren't reliable and they want the auditor to defend why they think such and such should be done....).

Any recommendations for good references that can be used as support for arguing for the benefits of doing it "the proper way" (as I've only really ever worked in med tech environments, the concepts of risk, quality and standards are assumed and obvious so it's a bit of a culture shock to think about how you would start to explain to people not used to this niche and think "they know what they are doing"

 

[Tidge]

Any recommendations for good references that can be used as support for arguing for the benefits of doing it "the proper way" (as I've only really ever worked in med tech environments, the concepts of risk, quality and standards are assumed and obvious so it's a bit of a culture shock to think about how you would start to explain to people not used to this niche and think "they know what they are doing"

I rather like Pressman's book Software Engineering: A Practitioner's Approach. I found it to be incredibly thorough and easily divisible into different subject areas such that even folks who have a very short attention span can get through relevant chapters. My experience is that few "working professionals" are willing to engage with text, but it could be worth a try to dump a few pages on them at a time.

It has been my experience with most engineers (not just software developers) that most will adamantly stick with "what they know, because it works" and only come around to analyzing their (inefficient) process/methods once the inefficiencies surpass some critical threshold... and even then it is necessary to move into problem-solving space as opposed to blindly flailing about (e.g. googling, asking LLM) for specific, random solutions to whatever immediate problem they have. Circling back to Pressman's treatment: he's got the topics mapped out such that it is easy to pick one topic and move forward/backward through the process to understand "what came before" as well as "what should follow" to be an effective engineer.

 

[drm71]

Thanks for this reference, seems like several versions but the latest (9th ed?) is from 2019, right? I found a PDF of the 7th edition online but I will buy the latest version (important to support the author properly) if you recommend it as you seem to have a lot of knowledge and experience!

 

[Tidge]

I have an older (i.e. not most-recent) version that I like well enough (also 7th) that I haven't invested in the latest.