Reasons Reqs Go Unread

[Dan]

So many of have "been around the block" a few times.

I'm not looking to start a fight with developers, some of my best friends are developers. I've just never been a developer so I don't have insight into all of the things that make them tick, and compete for their valuable project time.

So the question I have is, why do you think a developer would not read a reqs spec? Or maybe a little less harsh, read it but just pay it minimal heed when it came to actually designing and coding the system?

A: Too Busy? "Just have to crank something out and we'll work it out in UAT."
B: Too Smart? "The users can't really want THIS. I'll give them something that'll be really cool."
C: Too "Green"? "These docs seem a little vague. Not sure who to talk to about this, so I'll just do my best."

The above is a bit rhetorical as I've seen all of these. Sometimes on the same project, from the same developer, in the same day!

The real question is when faced with scenario A, B and/or C, what strategies have you used to mitigate/correct this and foster a more collaborative ownership of the reqs and the project success?

[bkuhn]

I'm continually surprised at the number of times I'll have a developer ask me about something that I spent a lot of time documenting in a spec. Honestly, I'm not sure if it's laziness or lack of comprehension. I know we spend a lot of time interacting with people whose first language is not English. Is that part of the problem - I'm not sure.

One technique I've used which helps (though doesn't eliminate the problem unfortunately) is hand-off sessions. During these meetings, we walk through the requirements and Development has an opportunity to discuss and ask questions. Doesn't this happen during Validation, though? Sometimes - but a lot of times you have more Developers that are going to develop the app than were involved during Validation.

Another technique is the "show me" approach - where you have Development show working code as it is developed. This doesn't prevent developers from producing something that doesn't match the spec, but it does catch things before they reach Test (and we all know the sooner you find problems, the cheaper it is to fix them).

[MTalbot]

The real question is when faced with scenario A, B and/or C, what strategies have you used to mitigate/correct this and foster a more collaborative ownership of the reqs and the project success?

Tasers?

I think BKuhn has the right idea - have a handoff between the business and the developers, so that there's a personal connection in addition to the document.

[gescober]

I've been lucky in that most of my developers go over my specs with a fine-toothed comb, but there are those that don't bother to read the requirements. I really don't know why - as Bkuhn mentioned, I think it's part laziness, part comprehension, and part not wanting to read through a boring document.

As the others, I always have a walk through of the requirements - in Agile, I guess this is the "conversation" you're supposed to have. I believe Agile also assumes that your developers can't/won't read lots of documentation, so you shouldn't bother doing much of it up front, hence the "User Story".

When I was doing RUP, when we did the walk through of the Use Cases, we also did our UML modeling. Collaborative modeling really helps to cement understanding (as well as foster lots of arguments).

[bkuhn]

I've been lucky in that most of my developers go over my specs with a fine-toothed comb, but there are those that don't bother to read the requirements. I really don't know why - as Bkuhn mentioned, I think it's part laziness, part comprehension, and part not wanting to read through a boring document.

As the others, I always have a walk through of the requirements - in Agile, I guess this is the "conversation" you're supposed to have. I believe Agile also assumes that your developers can't/won't read lots of documentation, so you shouldn't bother doing much of it up front, hence the "User Story".

When I was doing RUP, when we did the walk through of the Use Cases, we also did our UML modeling. Collaborative modeling really helps to cement understanding (as well as foster lots of arguments).

I think you've hit on another problem - long lists of requirements with nothing else in the document. No one wants to read those (except maybe the test team!). Your other suggestion is spot on as well - getting development involved in the modeling can help a lot.

[BizAnalyst]

So many of have "been around the block" a few times.

I'm not looking to start a fight with developers, some of my best friends are developers. I've just never been a developer so I don't have insight into all of the things that make them tick, and compete for their valuable project time.

So the question I have is, why do you think a developer would not read a reqs spec? Or maybe a little less harsh, read it but just pay it minimal heed when it came to actually designing and coding the system?

A: Too Busy? "Just have to crank something out and we'll work it out in UAT."
B: Too Smart? "The users can't really want THIS. I'll give them something that'll be really cool."
C: Too "Green"? "These docs seem a little vague. Not sure who to talk to about this, so I'll just do my best."

The above is a bit rhetorical as I've seen all of these. Sometimes on the same project, from the same developer, in the same day!

The real question is when faced with scenario A, B and/or C, what strategies have you used to mitigate/correct this and foster a more collaborative ownership of the reqs and the project success?

D: Have experienced lousy requirements documents in the past and had to figure it all out by themselves anyway, so learned to pretty much ignore them.

Sad, but true.

[MAlexander]

So the question I have is, why do you think a developer would not read a reqs spec? Or maybe a little less harsh, read it but just pay it minimal heed when it came to actually designing and coding the system?

What about the flip-side of the equation -- business representatives who won't review the documentation thoroughly to make sure it reflects their needs? I've had as many, if not more, problems with the business saying "oh, we're done with requirements" after the discussions are through, and then never closing the loop by validating the documentation. The assumption seems to be that, since the Analyst was there in the room during the discussion, the documentation will automatically be absolutely correct.

How have others been able to get meaningful reviews from the business, other than threats or hand-holding.

[gescober]

Most users I've had only have to be burned once where they have a developer who didn't build what they wanted because it wasn't specified properly. After that, they always pay attention. On occasion, I'll have a user who isn't as engaged as they need to be, in which case, I'll try to express the requirements in a more interesting/obvious way, or insist on walking them through, or even pick a fight - take the opposite position on a controversial requirement, and provoke them into engaging me.

Oops, the suggestions above probably count as threats or hand-holding. The one that isn't a threat or hand holding is in how you express your requirements. If you have masses of text that is hard to wade through, then illustrations in the form of diagrams or pictures can work better. There are a number of workshop techniques or exercises that involve more active participation that may work better, as well.

I think one key is work iteratively, and show them design - especially UI design - as it relates back to their requirements. Once they make that connection, they're usually much more engaged.

[JCR]

I have been a developer who wrote the code, a PM who wrote specs and a business stakeholder. In all this time (and much of it in hindsite) I have rarely seen the problem really just be that someone did not pay attention to the specs. Having been on all sides of the table, I perceive that the problem often is one of communication rather than laziness. Sure, we all run into people in our careers that just refuse to pay attention, but those are the exception rather than the rule.

From a Developer Perspective
I have run into conflicting requirements many times on every project that I have ever been on. Sometimes it is that one subset of requirements is very clear, but the larger set or some other functional set conflicts directly. Sometimes I heard a requirement expressed one way in a meeting and a different way on paper. Often, I have seen requirements that conflict with general design tenets (UI or architecture).

From a Business Stakeholder Perspective
This is by far the crappiest side of the table to be on in a software project. You are asked to sign off on a solution based on bullet lists, use cases and sometimes screen shots. This is like buying a car by looking at the web site of the car manufacturer and never having seen the car. It is ridiculous. This is fundamentally why the SDLC is broken at most companies and why Agile and rapid prototyping is the future of software delivery. Sitting back on the delivery side of the table now days, I never become exasperated with the business folks like I did when I was a developer.

I would suggest that you dig whenever a developer or business user starts asking questions that you think are covered in the requirements. Those of us that write requirements often think that what we write is very clear. But it is not the clarity of a single requirement that makes a requirements document clear - it is how the whole system fits together. The best answer is to move to Agile and some flavor of prototyping and only deal with lose requirements up front. If you cannot do that, then realize that no requirements document will ever cover an entire solution - and even if it could, it would be so large that no one could possibly consume it all. If the assumption is that your team is competent, then there is likely a real reason that they are asking you a question that you think is covered.

Sorry to hop up on a soapbox, but requirements and Agile is a topic near to my heart.

[achen]

Those of us that write requirements often think that what we write is very clear. But it is not the clarity of a single requirement that makes a requirements document clear - it is how the whole system fits together. The best answer is to move to Agile and some flavor of prototyping and only deal with lose requirements up front. If you cannot do that, then realize that no requirements document will ever cover an entire solution - and even if it could, it would be so large that no one could possibly consume it all. If the assumption is that your team is competent, then there is likely a real reason that they are asking you a question that you think is covered.

Sorry to hop up on a soapbox, but requirements and Agile is a topic near to my heart.

I agree with the idea that you simply cannot describe in words or even pictures a complete system with enough clarity for someone to go off and develop it with no verbal communication. I view the requirements as being primarily useful as driving discussion about what is being built and as a log of the specific decisions/agreements that have been fleshed out.

The devil is in the details though and the question is how much detail is too much detail? Some agile proponents say that you should only write down scenarios, I don't think that is enough detail. However writing out every single field length may be too much detail (for the business at least).

We all hear that mistakes cost 80X at development compared to requirements, but that does not compare the time it might take to avoid all the mistakes. In the case of an improper field length, the time to document thousands of field lengths (to avoid the one that you get wrong) may completely dwarf the time to fix the field length.

On the other hand, the field that you forgot, may need a major architectural change.