How detailed the requirements should be?
Developer’s point of view
If you ask developers how detailed the requirements should be, they will tell you that they want to know exactly what clients want to get. And this is good! Vague, high level, general requirements are not going to work for them. Everything has to be measurable so that developers and testers can easily, objectively, assess if a requirement has been fulfilled or not. To give you an example, if client wants to get a clickable button with an image and a label then, in ideal situation, developers would like to get acceptance criteria like:
- size of the image is 16×16 pixels, supported formats: JPG, GIF and PNG
- font size is 12 px and custom styling is not in scope
- label is mandatory and can have between 1 to 20 characters, only alphanumeric characters are allowed
- and so on …
To summarise it – expectation is to get technical details for each and every element.
Client’s point of view
Clients are usually much more high level, they operate on business level. It’s quite rare to hear from a client that they want a “clickable button with an image and a label”. They don’t operate on this level of details, not to mention the size of fonts or number of characters which can be entered as a label.
Much more frequently you will get strategic decisions like:
- IE6 is not a supported browser but still site in IE6 should be functional
- All component should be mobile ready – components should use all capabilities of mobile device and gracefully degrade from smart phones, touch phones to basic phones
- Site should be functional for people who have Java Script turned off
- and so on …
These are all sensible decisions but of course are too general to convert them into acceptance criteria just like that. The devil is in the details…
How to bring these two worlds together?
It’s obvious that there is a huge gap, details-wise, between decisions made by business and development team expectations. Primarily it’s a business analyst, project manager and technical lead job to minimize this gap and get both sides to understand each other. But is it only up to them to do the magic trick? I don’t think so …
To find the common ground, both sides have to step out of their comfort zone. Developers have to start thinking not only how to build a solution but also how to set constraints which will reduce complexity and effort to the minimum and in the same time maximize value for the business. It’s definitely not an easy thing to do. It requires good understanding of client’s needs, deep technical knowledge and experience to assess what solution will work and what will cause more trouble than benefit in future.
Business also have to be involved. Making a few general decisions is not enough for successful project delivery. Business have to collaborate with development team and help them transform requirements into solution.
It’s all about asking right questions
Development team which wants to get more detailed requirements can ask:
- So you want this clickable button with an image … what formats should we support?
- And how many characters you will need for a label?
- How this button should be rendered, are 12 pixels for a label the right size?
Or situation can be like this:
Dear client, we have prepared an example of clickable button for you. We think that in this version everything looks good and all the functional requirements are fulfilled.
- Do you think that image size is correct?
- We think that supporting the most common formats like JPG, GIF and PNG is enough. Do you agree?
- We have limited the length of the label to 20 characters to make sure that button will look good and consistent in all cases. What do you think about that? Is that a sensible limitation? If you want, we can extend this limitation but it will require additional 2 days of work because of something … Do you think that 2 days are worth it?
I think you can see my point here. First set of question is easy but all the thinking is on client’s side. Second set of questions requires preparation and is much harder, especially in more complex cases. I think second case is the way to show that we, as a development team, are adding some value. We are not just sitting and waiting for all the answers to magically appear, we are actively looking for those answers, we are providing technical expertise and this way we are helping our clients to make educated decisions.
What is the final goal?
Projects always have a limited budget (and requirements which are exceeding that budget). Final goal is to maximize return on investment for our clients. Not by working extra hours or running over budget but by
- figuring out which requirements have the most value and focusing on them
- helping to transform general decisions into a solution by providing recommendations and technical consultancy
- keeping things simple, low effort increases customer loyalty
- steering clients out of bells and whistles which are costly
PM can be a bridge between a client and development team but usually PM on his own don’t have enough technical experience to generate recommendations and provide technical consultancy. It’s an objective for entire team.
What are your thoughts on that?
Great post Marek.
I’ve found that clients don’t like questions. Even the right ones. They prefer conversations.
Your second situation is really about playing back a solution with a bunch of assumptions you’ve made earlier. Instead of asking questions, let the client play with it. Then the real conversation starts in which you validate and/or refute ALL prior assumptions.
Man, I assumed you’d support IE6! Of course it should render on the IPAD? Yes, why on earth would you not make these pages SEO friendly.
Nothing hurts you more than hidden/unvalidated assumptions.
cleve
25 Jul 11 at 5:56 pm
Hi Cleve, I agree – conversation for sure is better than a long technical questionnaire!
You have also touched slightly different subject – hidden assumptions which I consider as the biggest danger for any project. Especially those assumptions on client’s side are risky
The real trick is unearth them early!
Marek Blotny
25 Jul 11 at 6:16 pm
+1
cleve
25 Jul 11 at 10:00 pm
The first rule of requirements is to ask your customer ‘why?’. If they can’t explain simply why the requirement is needed then it isn’t essential and it should be discounted. If the response is acceptable, the next question is ‘How am I going to validate that I have satisfied the requirement’? If you can’t agree on how the requirement is to validated, then the requirement clearly needs clarifying, maybe with some constraints explicitly included in the requirement wording. The language of requirements is very important and the differences between shall, should, will, may are VERY important. Any requirement with phrases such as ‘such as’, ‘for example’ should always be rejected as they are open-ended and can never be fully satisfied.
As an example, I encountered a requirement recently which included the phrase ‘any printer shall be supported’. After discussions, and any customer that doesn’t engage in discussions is clearly an indication of a very difficult customer!, it became very clear why the requirement had be written in the way – a third party would be supplying the as yet unspecified printer. However, the discussion did enable the requirement wording to became slightly more achievable by rephrasing as ‘a network connected printer supporting postscript’. At least I would have a chance of testing this (and have constrained it to exclude printers with parallel or usb interfaces).
The hardest part of requirements is not the accepting the requirement, it is the validation at the end. How often have you encountered ‘This isn’t what I wanted’. The only way to avoid this is to remain in constant contact with your customer to validate any assumptions throughout the development so that there aren’t any surprises at the end.
aph
27 Jul 11 at 5:14 pm