Posts Tagged ‘Requirements’

Tracing user stories and code – why is this valuable

Written by Blaise Rey-Mermet on . Posted in Agile Requirements Management, Lean & Agile Product Development

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:

Sample requirements traceability between user stories and the product

  • 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

Requirements for products that should not fail

Written by Blaise Rey-Mermet on . Posted in Lean & Agile Product Development

Here are the slides from my seminar “A Specific Requirements Formulation for less Risks and more Dependability” at the Embedded Computing Conference 2010 ECC . It contains some practical examples and things to remember when formulating requirements for products that should not fail.

The cooking recipe is in short to address the risk in the requirements by specifying:
• the value
• the required quality level, measurable
• who will use this
• under which conditions
• with which risks
• and what happened in the past

Get immediate feedback.
The results are requirements that you can trust.

Thanks to all attendees!

Agile Requirements: Expressing Assumptions in User Stories.

Written by Blaise Rey-Mermet on . Posted in Agile Requirements Management, Lean & Agile Product Development

Last Saturday was cold and I was at home browsing through a pile of unwrapped magazines, so I came across an article by Daniel Jackson about dependable software (see reference below). The author explains the importance of software in safety-critical equipment that we come across every day and he considers approaches that offer a greater trust in them. He defines dependable systems as follows:

“A dependable system is one you can depend on—that is, you can place your trust in it. A rational person or organization only does this with evidence that the system’s benefits far outweigh its risks. Without such evidence, a system cannot be depended on…“

In the development of critical products, we use agile practices like Scrum because they make the product more dependable and safe. In this context, the requirements play an important role.

With Scrum, we can use and adapt User Stories to help to clarify this dependability:

  • First, in Scrum, we formulate requirements in the form of User Stories to enforce verbal communication because talking (and listening carefully), writing and drawing is a more efficient and careful way to communicate.
  • Second, User Stories help us to discuss carefully with the stakeholders the purpose they want to accomplish, the value of a requirement, not the implementation details. For example by using a template like “As a … I want to … so I can ”. This is particularly helpful when testing the system: to know in which context to test it. Example of User Story, in this case the control unit of a medical device:

    As a
    patient, I want a view of the operating history for the last 24 hours in the simplest possible way so I can easily read it in low lightning conditions or when I am tired or confused.Commitments to the details can be postponed and made later when the first implementations and prototypes allow a better understanding. At this time, the constrains (or non-functional requirements) related to User Stories can be written down (just) in time for the implementation and make the requirements quantifiable.
  • Third, for dependable systems, the critical properties of this functionality, and the assumptions that could cause problems -if untrue- could be added to the Story in the same way. When discussing or writing Stories, consider expressing the critical properties and the assumptions, and add them to the Story, for example:Assumptions:
    1) Ambient luminance range: 100 to 1000 lux.
    2) Viewing distance: 20cm to 60cm

    3) For alarm signals, specific requirements shall apply.

Knowing the assumptions and intends of the User Story seems important enough to take the time to clarify this with the Product Owners. For the agile development of dependable products, just-enough details may mean clarifying the value, the constraints, assumptions and risks that make the story verifiable, and doing this at the latest possible time, when the first implemented features permits a better understanding of the product. In this way, we can balance the benefits and the risks, and implement User Stories where we are reasonably sure to understand the risks.

References: D.Jackson, A Direct Path to Dependable Software. CACM.ACM.ORG 04/2009 Vol.52 No. 4 – http://sdg.csail.mit.edu/publications.html