Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 3 down vote favorite

You know what they're asking for. You know what they really want. However, technically the way they wrote it is with a litmus test of requirements that don't match what they want because they don't understand what they're asking for.

Should it be a part of our job to match the spirit of the requirements, or match ridiculous requirements with this gut feeling that the requirements will change once they see the final result?

I feel it's more ethical to determine what the user really wants, and find a solution with requirements as a guideline, but often I find others lose patience too much and just wants to give them what they technically ask for.

share|improve this question
8  
It is your job to understand what the customer wants. You are the technical expert, the customer gave you their best guess, but they aren't the expert. They are relying on you to build what they want, not what they told you they want. However, keep in mind that requirements are required. They are not suggestions. If any requirement is unclear then it is your job (or your company's job) to get clarification of the requirement or even to rewrite the requirement until both sides can agree what is the meaning of the requirement. If you fail to do this then you will cost your company a lot of money – Dunk Jul 21 '11 at 17:43
Keep in mind that requirements are a form of communication. Communication rarely succeeds if only one side is participating. – Marcin Jul 21 '11 at 22:47

9 Answers

up vote 17 down vote accepted

It is better to explain what the customer will get if you follow their requirements as they are written, and suggest that the requirements be rewritten to clarify the customer's true intent.

But generally speaking it is the Project Manager's job to interpret the requirements in a way that will adequately fulfill the customer's needs. It is pointless to blindly follow a set of requirements literally when you know you are setting yourself up for failure.

What about technical debt, for example? Do you write a crappy, poorly architected program that is unmaintainable but meets the customer's requirements, or do you take the time to do the job right?

share|improve this answer
+1 Yes, if you are fortunate enough to have a project manager. And that project manager is also competent. – P.Brian.Mackey Jul 21 '11 at 16:37
I can't control project management in terms of end-result look and feel, because that's "outsourced" within organization to a separate department that has no programming experience, and to one that I'm not allowed to get into detail with. – Lee Louviere Jul 21 '11 at 16:39
1  
If you are a developer, it is part of your job to give your project manager time estimates that include things like unit testing and refactoring. The design of the program is probably beyond your control; if the customer wants 100,000 checkboxes in a web page, you either have to show your Project Manager a better way, or let him know that you think it will be problematic and do your best to provide what is asked for. If it falls down, the Project Manager and customer get to decide what they are going to do about it. – Robert Harvey Jul 21 '11 at 16:40
5  
+1 Agreed. Always clarify with the client and keep your email / paper trail. That way if it doesn't turn out the way they wanted, you have proof that they got exactly what they asked for, despite your best efforts. If you don't ask and do it differently, you risk it coming back to bite you. – Becuzz Jul 21 '11 at 17:32
2  
@DJClayworth: In a perfect world, everyone would have clearly delineated responsibilities and accountability. In practice, it rarely works out that way. If you look at the comments posted above, you will see that the OP was blamed for a design problem, even though the design was not his call. – Robert Harvey Jul 21 '11 at 18:52
show 3 more comments
up vote 5 down vote

Yes...it IS your job to go back and get clarifications. We, as developers, need to be just as involved with gathering and understanding requirements as any BA or business user. If you suspect they want something different than what is on paper - talk to them.

Face to Face if possible - always better than email or IM. THEN - follow up with an email - keep your paper trail.

share|improve this answer
up vote 3 down vote

Since you are asking a question about ethics, you need to specify which code of ethics you are adhering to. I will answer based on the Software Engineering Code of Ethics and Professional Practice from the ACM.

The important sections are the ones on the client relationship and the product itself:

CLIENT AND EMPLOYER - Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest.

specifically:

2.06. Identify, document, collect evidence and report to the client or the employer promptly if, in their opinion, a project is likely to fail, to prove too expensive, to violate intellectual property law, or otherwise to be problematic.

and

PRODUCT - Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.

specifically:

3.06. Work to follow professional standards, when available, that are most appropriate for the task at hand, departing from these only when ethically or technically justified.

3.07. Strive to fully understand the specifications for software on which they work.

3.08. Ensure that specifications for software on which they work have been well documented, satisfy the users’ requirements and have the appropriate approvals.

The above should answer your question about your ethical obligations. Your development team needs to alert your client about the issues your team sees with the requirements.

I would suggest that you do not do this on your own. You need to document what you see as the issues, and discuss with your project management and technical leadership.

Well run projects should have a requirement management process, which should include provisions for documenting and resolving problems that are discovered during development.

share|improve this answer
up vote 3 down vote

I frequently get requirements that are vague, contradictory, or likely to lead to a bad result. My standard response has become to write an email that's generally like this:

I want to double-check something with you.

What I understand is that you want me to do X, Y, and Z, you know that implementing all three of these will result in [a particular bad result], and that's what you want to happen.

If this is not correct, please tell me specifically where I've misunderstood and what you'd prefer to have done by [some date and time, like tomorrow at 1 PM]. Otherwise, I will begin implementing based on this understanding.

I've found this to work very well. I just did this last night, and my client corrected their requirement before I started work this morning.

This approach doesn't blame the other party, but it puts the ball in their court to figure out and clearly state what they really want in a timely fashion, and makes it their responsibility to accept the consequences if they don't. As a consultant, they're paying the money and they call the shots. So I figure if they want me to do something dumb, I'll warn them in plain language, but ultimately it's their decision, and as long as I still get paid, I'm happy.

share|improve this answer
up vote 2 down vote

Slow down, Cowboy!

Ask for the users input.. And explain why your way is better.

share|improve this answer
I'm dealing with a situation where we there are conflicting requirements that don't appear conflicting until you actually get down to platform capabilities. To the user its like, you can implement everything in the checklist independently and then it's all done. However, we can really only give n of x from the checklist no matter how we implement it. However, if I scrap the requirements, I can come up with an alternative that fits what the user "really wants" but doesn't fulfill the checklist. – Lee Louviere Jul 21 '11 at 16:35
3  
@Xaade: "conflicting requirements that don't appear conflicting" That means you have to talk to people to (1) explain the conflict and (2) understand what the real expectation is. There's no magic. It's a conversation. – S.Lott Jul 21 '11 at 17:01
up vote 2 down vote

Should it be a part of our job to match the spirit of the requirements, or match ridiculous requirements with this gut feeling that the requirements will change once they see the final result?

Neither.

We invented the Agile processes so we wouldn't have this stark (and unmanageable) choice between two fairly bad alternatives.

The point of being Agile is to find a sensible, high value, useful path between two modes of failure.

share|improve this answer
Please reference Agile processes. – Lee Louviere Jul 21 '11 at 17:19
2  
@Xaade: Is Google broken? en.wikipedia.org/wiki/Agile_software_development should be the first place to start. – S.Lott Jul 21 '11 at 17:22
up vote 2 down vote

If you build to spec and they don't like the result, you can say "I built to spec! What's the matter?" Then there will be rewriting and refining of specs and code. Unless they ran out of money to do that. In which case you'll need to find a new client if your client can't get more money.

If you build to what you think they want and you get it wrong, they will say "You didn't build what we want! Re-do it! No, we won't pay you this time!" and you will be in trouble, and maybe even out of a job. Which might suck.

In conclusion:

If you start to get a feeling that what they want will not be good for them or that they won't like it, talk to them about it! Get clarification before you start writing that code.

share|improve this answer
I don't like this. It results in wasting the client's money. The client can't be responsible for money they do not understand. – Lee Louviere Jul 21 '11 at 17:16
@Xaade: So talking to the customer to find out what they really want is wasting the client's money? – Dunk Jul 21 '11 at 17:29
@Xaade: Re-read my last paragraph. It will take a little bit more time up-front, but more money will have been saved by the time the project is done. – FrustratedWithFormsDesigner Jul 21 '11 at 17:33
up vote 1 down vote

The bottom line is that the customer wants what he wants even when he doesn't know what he wants. Get it? So any exercise that doesn't directly or indirectly lead to this ultimate goal is an exercise in pointlessness.

Talk to the customer and get the requirements sorted out to what they REALLY WANT on paper, so that way when it goes to QA testing the testers will not be confused about what the real requirements are.

The SPIRIT of the requirements is a matter of your opinion and it may not coincide with what other stakeholders, developers and testers view the requirements to be. Leave as little room for interpretation in the written requirement as possible.

share|improve this answer
So reconcile the spirit and the technical requirements on paper with the client before proceeding. The problem is often the client won't respond with due diligence. They expect you to have that diligence. Would it be worthwhile if the alternatives are minor, to have both worked out? – Lee Louviere Jul 21 '11 at 17:18
up vote -1 down vote

@Xaade given your response to @Morons (heh, funny how his ID fits this situation so well) I think it would be in everyone's best interests to pursue your idea that you know the correct solution given all the technical constraints.

Iterative design is applicable at all stages of the design. So iterate through the requirements phase until everyone gets on the same page.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.