InsideSpin.com

I have been struggling with how much detail to put in my requirements documents that I provide to Development. I often get caught in a trap -- too much detail and Development feels I am telling them how to do things, too little detail and they feel they are not able to provide a proper assessment of how long a feature would take -- is this common or am I approaching it incorrectly? This is one of the first times I am drafting Requirements documents so I might be doing the wrong things. Any ideas are appreciated.

LoveGolf,


Every PM has a different approach to writing MRDs. Over time, you'll improve your requirements writing technique and tune it to your development environment. In my experience, I've found that it is best to strive to minimize the amount of pages in an MRD, while maximizing the context for the developer. Many developers concentrate solely on the technology and require your guidance to figure out what to build. You'll want to cite a few real-case examples for each product feature that you're requesting, this will help the developer figure out why they're building it and put it in business context.

It is a fine balance between writing requirements that are too vague and writing requirements that are too specific. The rule of thumb that I use is to stop when the requirement gets into implementation. However, in some cases I've found that it helps development greatly if you create 'prototype screenshots', done in PowerPoint to illustrate the preferred embodiment of the requirement. It forces a 'user-centric' design for the product. However your approach will generally depend on the type of development team you have.

The most important thing, is to always, always, always, hit your dates for presenting your requirements. If you don't, development will move on and start coding without you. After all, if you can't hit your MRD date, how can you expect development to hit their launch date?


Hope that helps.

Cadman.

Some people like detail and others like to left alone to figure it out. I think it's best to tailor your style to the individuals you are dealing with on the dev team.

In an early stage company you might have to have spend a lot of time filling in the detail as everyone is trying to figure out what to do and how to do it. After the product concept becomes more mature the team should start to gel you and develop a mutual trust. At this point you can probably put less detail in the document.

Examples of different methods
- If you have a senior developer claiming tons of experience then I would expect there to be very few discussions over the technical details. If either of you are new to the company/project then I'd expect the first release/iterations/sprints to be taken up with discussions of this sort and then quickly move towards the mutual trust mode.

- If you have new or junior people leading the development who are not confident in their roles you'll need to a lot more discussions about the details. If this doesn't change over time then I'd raise this as a concern to management as you have the wrong people in your dev lead roles.

In either case you may or may not put the results of the discussion in a written document. ;)

Akw

The move to agile development can really help with this problem. Being able to write user stories is a great way to change the level of detail for different requirements. A user story outlines a minimum amount of useful functionality that can be implemented. I also like to have a high level requirement doc accompany user stories, as the doc outlines the overall goals of the release and what we are trying to accomplish with it. The details on what the product does gets covered in user stories. (http://scrummethodology.com/scrum-user-stories/)