Skip to main content

Keeping requirements up to date during project

Last post 10:54 pm August 30, 2023 by Thomas Owens
5 replies
05:53 am August 30, 2023


There are several standards that require keeping requirements (like User Stories) up to date and traceable during the project. Such standards are, e.g., Medical Devices - IEC 62304 and Automotive - ISO 26262. I admit I took ChatGPTs word for this as I do not have those papers readily available.

Tracking changes over User Stories feels painful in so many ways at first thought, but of course it is doable.

Any experiences or advice on how to best accomplish this in an agile project?

08:19 am August 30, 2023

The test plans, which are based on the requirements and contain all the test cases are good for tracking the requirements. Furthermore, the test cases can be linked to the PBIs on the Product Backlog. The list of passing test cases shows the coverage of the requirements. 


09:00 am August 30, 2023

To be more specific, I mean the case that some User Story is implemented, and later the functionality is changed. Now, according to standards, the original User Story should be modified (or replaced) to reflect the modification.

This certainly does not hold when team is using yellow notes that are scrapped after Done :) Unfortunately this is not possible in all projects.

01:17 pm August 30, 2023

I may be wrong but I don't believe there are any standards that the original product backlog has to be modified.  Going back to the days of waterfall and requirements documents, the original documents were never modified.  They were changed via addendums, much like laws are done in the United States.  You always preserve the original and modify by attaching documentation that explains the modifications. 

In the instances you (or should is say ChatGPT) suggested you would still need a record of the original requirements. So, instead of modifying the original text, you would modify by attaching new text that explains the modifications.  If you are using some electronic system to manage your backlog, you would just link the modification to the original.  If you are using yellow notes, that are thrown away, then you have no record of the original and you are already out of compliance with those standards so your problem is much bigger.

01:37 pm August 30, 2023

There are several standards that require keeping requirements (like User Stories) up to date and traceable

There's your problem. A user story isn't a requirement. It's a placeholder for a conversation about a potential requirement. That's not the same thing.

Tests which assure compliance with an evolved requirement are, indeed, more likely to be worth tracing. Business tests trace to unit tests for example. If the business requirements change, we have a direct follow through and the ability to leverage automation support. This is far more specific than a shoebox of sticky notes.

10:54 pm August 30, 2023

Ian is 100% correct. Although user stories may look like requirements, especially when they are fully refined and ready for development, they aren't. When a user story is added to a backlog, it's a placeholder for a conversation (or, likely, multiple conversations) with key stakeholders. When it's fully refined, it describes a change in state of the system to enable a user to perform a valuable activity.

Tests are what you want to look at for tracing.

Standards such as IEC 62304 and ISO 26262 don't have (as far as I'm aware) any product requirements in them, but do specify process requirements and the types of information to capture and provide to stakeholders, at least as far as I'm aware. I'm only tangentially familiar with these standards, but I'm familiar with similar standards from other industries. Sources of requirements that you would want to trace to would be things like the US FDA's 21 CFR Part 11 or the EU's Annex 11 for electronic records and computerized systems in the pharmaceutical space, SOX requirements in the finance space, and similar regulations. Although these requirements still have procedural requirements, depending on the nature of the system, you can highlight test cases that demonstrate that your system conforms to these requirements in the same manner that you can trace a test case that demonstrates conformance to user requirements.

Specifically in the software space, it would be worthwhile to look into specification by example, which is sometimes called "executable requirements" or "executable specification". By taking this collaborative, iterative, and incremental approach to capturing requirements as automated tests, you not only have traceability to requirements, but you can actually use your requirements specification to perform verification of the system.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.