Establishing and maintaining traceability between the requirements and the product is valuable not only for critical system (and most systems are at least critical for your business) but also for any system that you intend to maintain and improve after their initial deployment. Traceability is often seen as expensive and politically sensitive since agile teams tend to consider that the requirements are not a part of the delivered product. So is tracing them waste?
What is it?
By tracing requirements, I mean tracing the requirements up to the delivered product (software, electronic, mechanic). For example acc. to CMMI [see Ref: CMMI]: Requirements traceability: “A discernable association between requirements and related requirements, implementations, and verifications.”
Why tracing requirements?
- This is necessary if you consider that the requirements are useful to understand and maintain the product – which is not such a strange idea. There is information in the user stories that is not documented in the code: the “why”, the purpose and value of a specific feature. Losing this information makes it very hard to understand the impact of requirements changes on the product.
- For complex systems, none of the original developer will remember the original purpose of each part of the product. Keeping a trace to the product requirement does this.
- It is essential to establish and continuously improve organizational knowledge about the product. Team members can understand the original intend of a specific feature without having to keep asking the lead architect for help.
So – how to do it?
- Simplify: Define a simple strategy (what is traced with what, on a graph). Trace only what is useful– what you are willing to maintain. Then do it systematically.
- Automate: don’t try this without some kind of (Requirement Management) tool. In regulated product development, standards require that a product is completely specified. The users’ needs must trace to specifications that define the system required to satisfy those needs. Nothing should have been added or omitted. Requirements management tools are necessary to establish and maintain this level of consistency.
A possible traceability strategy for User Stories: The traceability between the product and the requirements can be supported by keeping a record of the earlier stories, tasks and functional tests. Before establishing new traces, look for what you may already trace without calling it so:
- If you systematically apply the agile practice of writing codes specifically to meet test cases, your product is indirectly traceable to the Stories through the acceptance tests.
- A Sprint Goal satisfies a set of User Stories. At the end of the Sprint, each Sprint goal is demonstrable by a (potentially shippable) set of features. So these features and stories are indirectly traceable through the sprint goals.
- For functional requirements, I usually systematically group stories in Use Cases and then trace the Use Cases to product specifications and code.
Depending on your product and teams, many other strategies are possible to do this in an efficient and simple way. Feel free to comment.
References: CMMI for Development, Version 1.3 http://www.sei.cmu.edu/library/abstracts/reports/10tr033.cfm