My other blog entry “what is a business requirement” covers what is a technical business requirement.  Some such requirements are fine as the customer really does know what he/she needs and is trying to save time.  Or the customer wants the system to be similar to another one.  (In which case that fact should be one of the requirements.)

On the other hand, sometimes it is our responsibility to question the requirement.  Here are six questions to ask to see when that is the case.  Again, many of these examples come from posts I’ve seen at JavaRanch rather than my actual customers.

1. Does it meet a business need?
“The user should see red text on a pink background.”

This is not a business need.  It’s a technical detail – and a poor one at that.  Examples of a proper business requirement would be:

• “The user should see red text on a pink background because it’s part of an existing system that does that (or a standard.)”
• “The disclaimer should be small, hidden and low contrast”

Whereas the provided “requirement” invites discussion as to what the actual business goal is.  It may be that the customer didn’t realize how hard red on pink is to read.

2. What is the real goal of the requirement?

“The user should be able to query by the last three letters of their name”

Huh?  There is an important requirement hidden in here – to be able to find people who have a title like ‘PHD’ at the end of the name.  However, this isn’t the best way to go about implementing it.  The real requirement is crying out for a different solution like a separate field.  Which will only get discussed if you start talking about the real requirement.

If you don’t understand what a requirement accomplishes, the real goal probably hasn’t been stated.

2a. Is it someone’s opinion on the best approach?

“Only allow two files to be processed at a time.”

This category is a variant of finding the “real goal of the requirement.”  In this case, the true requirement is performance.  Which is a technical matter and not a business requirement.  Real requirements should be:

• “A file should be processed in X seconds”
• “The earliest files should be processed first” (don’t parallellize everything)

3. Is it feasible?

“Remember the user has logged in on a given machine after restarting the browser or rebooting.  But don’t use cookies because I heard cookies are bad.”

It doesn’t how much the customer wants something if it can’t be done.  This example isn’t possible.  It’s time to talk to the customer about the trade-offs between remembering an identity and cookies.

4. Is it cost effective?

“Add this one field to the list” [where you are using dynamic paging/sorting in the database, that one field is from a table several joins away and you are just under your performance requirement]

You notice in this example, the relevant facts you know are significantly longer than the requirement.  It sounds like a trivial change to the customer and they may ask on a whim.  Once you tell the customer what the implications are, he/she can decide whether it should still be implemented.  Sometimes a customer wants a feature if it is cheap, but not if it is expensive or will degrade another aspect of the system.  Communication is the only way to find out which is the case.

4a.  Will it introduce unnecessary complexity or maintenance problems?

“Make a minor change to the search algorithm” [where the requested change would either goes against the existing architecture or would require a really unmaintainable hack]

A variant of the previous one with a different emphasis on the cost.  Again, it is only through sharing what you know that the customer has enough facts to make a decision.

5. Is it usable?

“Put the reset button to the left of the submit button”

If a requirement goes against how computers work or standard conventions, it’s likely to confuse the living daylights of the end users.  It’s your job to inform the customer of this and to make sure the customer truly understands the implications of this decision.  Maybe make a mockup and have the customer try it out.  Or stop random people in the hallway and see how they try to click.

6. Will it compromise security?

“Use http for processing a credit card transaction.”

I think we all know why this is bad.  Similar to usability, it’s your job to convince the customer that he/she doesn’t really want to do this.  Only in this case, it’s even more important.  Security concerns are unethical to code just “because someone asked you to.”  (And for someone who counters with the case where sharing public information isn’t an issue, that’s not a compromise of security.)

What other questions can you think of to advise others to ask?