Requirements coverage
How do you map requirements to code?
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.
How about something like...
@Requirement(id=1,name="Get account balance")
public String execute(HttpServletRequest request,
HttpServletResponse response) {
...
}
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.
Re: Requirements coverage
I would map requirements to junit methods instead of within the implemtation code.
The benefits:
- JUnits are supposed to be suscinct test cases of one thing. This maps nicely back to requirements. Mapping within the implementation code requires a lot more bookwork to match everywere a requirement may hit.
- You can know if the requirement passes or fails from the JUnit outcome. From this, you get N working requirements and M not working. Tis much harder to determine when sprinkled in the implementation code.
- Alternate flows can be better tested from the JUnit by using/injecting mock objects.
Re: Requirements coverage
Re: Requirements coverage
I had the exact same idea and made an annotation out of it. Here was our scenario: How do we ensure that all the business rules for a particular use case that was being implemented in an iteration were accounted for in code.
My annotation looks like this:
@ImplementedBusinessRules (rules="", applicableusecases="") public void methodWhereUCImpStarts();
We then run a report (using java reflection) to get stats and comapare it with the listed rules for a usecase.
Where do we put the annotation? We put it on a business class method on the EJB. This is the method that orchestrates the use case (more or less). The idea should be that although this might not be very accurate all the time, a maintenance guy wanting to fix code defects has a fair idea where to start and can navigate from there.
Our real painpoints though have been design:
Personally, I have traced them all to the requirements not being documented at the correct level. We have too many and too detailed.
Requirements traceability, take #2401296
Simon asks, How do you map requirements to code and presents an idea he had recently, basically tagging certain points in your code with an annotation identifying t...
