Any book/resources on Requirements Specs?

[AlexPaes]

Hi to all, i know this might be slightly off-topic here so let me put it in context.

For the last couple of years i've been working for a small studio as a web developer working on several small web applications. After spending so much time complaining to my superiors that i wasn't getting enough and/or correct information on the customer's desires and expectations they finally decided we should take a different approach. Now they have put me in charge of this and suddenly i'm responsible for implementing some process where we can both extract useful requirements specs from the client as well as effectively communicate our systems features and limitations to the client.

Since I have never done anything like this i'm completely lost and so i'm looking for resources/feedback from people that are aware of how this process can be successfully implemented.

[Jacques Chester]

I've usually worked from Software Requirements by Karl Wiegers. He promotes a lot of commercial tools, but at work we're experimenting with using Redmine (a Trac-alike) to store and track all our requirements.

[AlexPaes]

Hi Jacques, thanks for your reply, i'll try to check that title at the local book store and see if fits my needs. I never thought of using a trac-like tool for keeping track of requirements. Can you detail a bit on how that works? I mean, do you use it to interface with the clients? And if so, how's the clients feedback so far?

[Jacques Chester]

At the moment we use it internally.

Redmine (and I think most of what follows applies to Trac also) allows you to define custom fields for issue trackers. So for instance I have a Use Cases tracker with fields for the Primary Actor, Goal, Success Guarantees etc. Then I put the body of the use case in the defined description field.

Similarly I have a field in Requirements for the Requirement Type, which maps to the standard IEEE categories.

Using a tracker this way means we have a very granular view of what has been done and what's left to be done. Also we can use the standard features to, for example, assign requirements to different versions, or make a particular task the responsibility of a particular user.

It's a Java shop, so I'm thinking I might take some time to write an adaptor into Mylyn for Eclipse, so you could have it all tied together nicely.

We haven't exposed this to the users yet.

[Jacques Chester]

I suppose I should add that the beauty of this is that Redmine and Trac can recognise issue numbers in source code checkins.

In Requirements there's a lot of talk about traceability -- that you should be able to justify any code or test with a requirement, use case or business rule. It sounds fine in theory but if you follow the traditional document-driven requirements process you're in for a world of tedious paperwork.

With Trac or Redmine you can add something like "For #27" in the checkin message and it will automagically link the tracker entry to the sourcecode and vice versa. Then, tada, traceability. Mylyn would make it even niftier because it associates issues with the Eclipse workspace as well.

[AlexPaes]

Thanks for your explanations Jacques,

I must say this is all quite new to me, our shop's workflow with requirements until now was myself getting a verbal requirements run-through with my boss by my side in something like a 10-20 minutes briefing and that was it, it's easy to see that both the development team and the customers have had their share of grief. For several reasons i think it will take quite some time before i can setup something half as evolved as you describe, the development team is quite small, coding mostly in PHP (yuck) in emacs or vim and only recently have i managed to integrate svn in the pipeline (everyone else thinks this is not necessary), so you can see how far behind this shop is. I believe the quality of the final product we offer is directly related to the quality of the coding pipeline, but unfortunately i'm the only one thinking so here. I'll have to look deeper into references and so before making a decision, if i go with something too complex it's plain to see that i will get nailed to the cross by everyone else here. I'll keep providing feedback as i progress on this matter...

[Balooga]

At the moment we use it internally.

Redmine (and I think most of what follows applies to Trac also) allows you to define custom fields for issue trackers. So for instance I have a Use Cases tracker with fields for the Primary Actor, Goal, Success Guarantees etc. Then I put the body of the use case in the defined description field.

Using a tracker this way means we have a very granular view of what has been done and what's left to be done. Also we can use the standard features to, for example, assign requirements to different versions, or make a particular task the responsibility of a particular user.

Trackers are a good first step, much better than trying to manage everything in WORD or EXCEL.

[Balooga]

With Trac or Redmine you can add something like "For #27" in the checkin message and it will automagically link the tracker entry to the sourcecode and vice versa. Then, tada, traceability.

How does it handle changes to requirements over time, or over phases? For example a specific requirment may be different for Phase 1, 2 or 3 of a feature. Or a requirment may be updated for Phase 2 due to a business change. Does the link in source refer to the correct version of the requirement; IsPhase 2 before the change or after the change, or Phase 1 or Phase 3 of the requirement?