Forum Discussion
Azure DevOp - Managing Requirements
We are looking at how to document and manage requirements within Azure DevOps. Sample documentation is here:
We see also the Modern Requirements plug in. Videos from the MR vendor indicate that Microsoft came to them and asked them to help round out their requirements management in ADO by making and selling an ADO native plugin.
In the past, I've managed requirements in Rational Requisite Pro, DOORS, HP/Microfocus Application Lifecycle Management (Quality Center), Aligned Elements, and other formal requirements management tools for a device in a regulated industry, including requirements tracing.
Within ADO (and with MR), it looks like "requirements" need to be defined as Epics, Features, User Stories, and Tasks. My initial reaction is that this doesn't seem like a natural mapping to me: that a requirement is a one-and-done work items that gets scheduled and completed. If the requirement changes ... then what.
Do I understand this correctly?
The "requirements" are then scheduled into sprints?
Is it that this tool manages requirements this way because these were the building blocks available in ADO?
How can select requirements be "shared" between products within a platform of similar products (with common software components), where some requirements are applicable to more some products and and others are not.
I see this old post regarding suitability in TFVS but maybe this no longer applies:
- I see 811 views, but no replies. I have the same question. Does each requirement have its own User Story? Do we just ignore the User Story and Acceptance criteria for that user story since it's actually a requirement that we're documenting? Never assign the user stories to a sprint? No story points? It seem klugey. If I use tasks for each individual requirement, do I just assign them to an "epic" which is the product or feature that the requirements are for?
