This post originated from an RSS feed registered with Java Buzz
by Simon Brown.
Original Post: Requirements coverage
Feed Title: Simon Brown's weblog
Feed URL: http://www.simongbrown.com/blog/feed.xml?flavor=rss20&category=java
Feed Description: My thoughts on Java, software development and technology.
Via TheServerSide.com, I just read an article called Requirement Coverage - Another dimension to Unit Testing. Essentially, it talks about a way to map requirements onto your unit tests and then use those unit tests to help you determine that you actually have coverage of the requirements. This is done through a tool called JRequire.
Now I've not used the tool, but I have been thinking about something similar for a little while. Well, kind of. I mean, the thought of mapping my requirements to my unit tests (even if they are really acceptance tests) doesn't enthrall me. On a large project in the past, we had a fairly large spreadsheet that mapped flows from use cases onto high level operations on service interfaces. I must admit that I left the project before any real development started so I don't know if this approach was eventually taken down to the code level. If it was, I don't even want to think about how complex this would have become.
Anyway, I think that there's a simpler way to do this. If you take most [ requirements | use cases | stories ], you can typically map these back to a single entry point in the application. I'm thinking of things like an action in a web MVC architecture, a listener in a desktop application or even an operation on a service. Assuming a Java implementation, what if you were to use an annotation to highlight the fact that these points of entry represent a requirement or a particular flow through a use case? Depending on how your requirements are coded, you could also annotate methods that implement exceptional flows if desired.
I need to think about this some more but there are some obvious benefits.
Searching for the code that implements a certain requirement is easy because you can just search for the annotation.
The annotations could be used at runtime to produce stats about how frequently features implemented from requirements are actually used, perhaps by reflecting on the annotations or by code injection.
The above technique could also be used to get coverage information on requirements during acceptance test runs, ensuring that your acceptance tests do test all requirements.
I think there's something here and the lack of traceability between requirements and code is certainly a gap in most projects. Any thoughts? How do you map requirements to code?