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?

Just because the customer asks for something doesn’t make it a requirement.  It makes it a discussion point.  For questions to ask, see my other blog post when should I question a technical business requirement

I tend to see five categories of non business requirements.  Many of these come from posts I’ve seen at JavaRanch rather than my actual users.

1. The customer is making assumptions about the technical implementation
Any requirement starts with an actual need.  Sometimes this is what gets stated as a requirement.  Other times, an implementation is given as the requirement without mention of what the original requirement is.

2. The requirements are technical and suggestions slip in
Some requirements, such as when you are interacting with other systems are technical.  Making it harder to differentiate the actual requirement from implementation suggestions.  With such a technical customer, it’s going to be harder for the customer to separate what is really a requirement in his/her head.  Questions can often draw this out.  And the technical customer may provide more useful insights during this process.

3. The customer  is trying to pre-optimize
Some customers give you requirements based on what they think is easiest rather than what they really want.  This happened to me recently.  My customer asked for something that was acceptable rather than what he preferred because it sounded easier to implement.  (In reality, it was an order of magnitude more work.)  When we talked about it, we decided to go with the actual easier solution.  Talking about it worked out very nicely.

4. The customer doesn’t really know what he/she wants
I think this is the hardest case.  It’s more than asking questions until you find out what is in the customer’s head.  It takes more discussion to help the user figure out what he/she wants.  Often technical mockups/prototypes help.  When you don’t know what you want, you may recognize it when you see it.  Or at least recognize what you don’t like in what you see.

5. The customer isn’t aware of what is out there
Sometimes a customer gives interaction requirements based on the desired behavior.  This makes sense.  At times, this description is extremely similar to an existing widget.  Either a built in one or one that’s already been implemented.  Showing the existing widget often results in something the customer likes better.  (or likes that he/she can get for little effort.)  Of course, technical people don’t always know the name of the widget either as evidenced by my what is this widget called thread!

What other categories can you think of?