You might try tying your tests to requirements through code conventions
and post-build scripts. We've had success doing this. The approach is
evolving, however. So far we've just been generating .csv files as build
artifacts available through our Continuous Integration interface.
However, we're working on a scheme to tie into requirement management
tools as well - no reason the approach can't be extended in any number
I wrote up what we've done. I don't know that it's a perfect fit for
you, but perhaps it will get your creative juices flowing.
Using Tests for Requirements Management
--- In AgileEmbedded@yahoogroups.com, Alan Dayley <alandd@...> wrote:
> Thanks for this, James.
> Defining these stories as tests is a good answer. We already perform
> tests to make sure specifications are met. Documenting them in the
> Product Backlog as tests could work.
> How would you document the tests to the rest of the company?
> Marketing and management sometimes gets worried about meeting
> particular requirements. These requirements need good communication
> both to the dev team and the people outside the team. The big chart
> may solve these concerns.
> On Wed, Apr 29, 2009 at 11:54 AM, James Grenning james@... wrote:
> > You can rephrase non-functional stories into tests. Devise tests
> > that demonstrate that the specification is met by the system under
> > System performs operations XXXX and YYYY at after 2 hours at 0 C.
> > Depending on how many of these non-functional requirements you have,
> > you might want a big visible chart to identify the specifications
> > that span the whole project.
> > James
> > ----------------------
> > James Grenning
> > www.renaissancesoftware.net
> > www.renaissancesoftware.net/blog
> > www.twitter.com/jwgrenning
> > On Apr 29, 2009, at 12:47 PM, alandond wrote:
> >> We are having a discussion about how to better handle specification
> >> item stories. We'd like to hear about the experiences of others to
> >> spur our creative improvement efforts. Let me explain a bit.
> >> What we are calling a "specification item story" is a line off a
> >> product spec sheet. There are specification sheet items like:
> >> - Operating temperature: 0-70 degrees C
> >> - Performance: 10 MB/s
> >> - Meets safety standard "Foo Public Safety Standard"
> >> We are finding it difficult to write agile stories for these items
> >> and break them down into workable sprint tasks. For example, the
> >> operating temperature touches on case design (mechanical),
> >> component selection, clock speeds and even firmware operation. It
> >> appears to the team as a constraint on the design but not
> >> actionable as a task or set of tasks.
> >> How do your teams handle these types of requirements?
> >> Alan
> > [Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]