Requirements documents - are they beneficial?
We have decided in the development team to write a requirements document for new functionality, I say decided by it was a more a case of a senior developer saying he did it and found it useful for a the following reasons
1. You get the requirements signed off by the customer, this increases the chances they are getting what they want and you both have something to work from.
I'm always willing (most of the time) to take on new ideas especially from Senior developers who have learnt through experience (otherwise known as the hard way) so I thought I would give it a go. I also keen to give it a go because the last piece of work I did didn't have a requirements document and it ended up with me having to add bits on the end because I didn't know they were needed.
I have to admit I got a bit confused to start with mainly of the wording and what kind of technical level I should go in. My first draft ended up a bit of shambles, half requirement, half assumptions and have technical solution. I did feel it was a benefit to go through the project and work out exactly what needed to be done and the different things.
I got the senior developer to have a look at the document and he recommended I move bits about and move the solution into a technical spec. He suggested I should try and write the document from a user point of view and what they would expect, this made a lot more sense to me.
I haven't written the second draft yet. The second draft is feeling a bit more like hard extra work but nothing is as difficult as the fearsome "blank page" of the first draft. So is writing the requirements document a benefit. I have to say I think it will be because it will allow me to get to an understanding with the customer as to what they expect from the project and to what I am going to deliver. The requirements document will help to get rid of the fuzzy points of the project and give me something to work from.
I have also found it is has been quite beneficial in terms of planning the work because as I am writing it I am learning more about the project. It's also quite useful to show other developers what I am working, it also gives an easy way for them to help you out by saying how they would tackle the work and perhaps any code they have written (which you might not be able to find easily) which could help on the project.
So at this point I am giving the requirements document the thumbs up.
1. You get the requirements signed off by the customer, this increases the chances they are getting what they want and you both have something to work from.
I'm always willing (most of the time) to take on new ideas especially from Senior developers who have learnt through experience (otherwise known as the hard way) so I thought I would give it a go. I also keen to give it a go because the last piece of work I did didn't have a requirements document and it ended up with me having to add bits on the end because I didn't know they were needed.
I have to admit I got a bit confused to start with mainly of the wording and what kind of technical level I should go in. My first draft ended up a bit of shambles, half requirement, half assumptions and have technical solution. I did feel it was a benefit to go through the project and work out exactly what needed to be done and the different things.
I got the senior developer to have a look at the document and he recommended I move bits about and move the solution into a technical spec. He suggested I should try and write the document from a user point of view and what they would expect, this made a lot more sense to me.
I haven't written the second draft yet. The second draft is feeling a bit more like hard extra work but nothing is as difficult as the fearsome "blank page" of the first draft. So is writing the requirements document a benefit. I have to say I think it will be because it will allow me to get to an understanding with the customer as to what they expect from the project and to what I am going to deliver. The requirements document will help to get rid of the fuzzy points of the project and give me something to work from.
I have also found it is has been quite beneficial in terms of planning the work because as I am writing it I am learning more about the project. It's also quite useful to show other developers what I am working, it also gives an easy way for them to help you out by saying how they would tackle the work and perhaps any code they have written (which you might not be able to find easily) which could help on the project.
So at this point I am giving the requirements document the thumbs up.
posted by The Hosk at
12:22 am
1 Comments:
Instead of writing it from the users' point of view, consider writing it from the QA's point of view. They're the ones that test the code and if they've got a list of all the things the software ought to do, then they can actually start writing the tests in parallel to code development. This will also help to expose any hidden assumptions on your part, because generally QA either guess wrong (and their tests will fail) or they'll ask for clarification.
By
markm, at Tue Jun 20, 10:59:00 pm 2006
Post a Comment
<< Home