Much Ado About Requirements

Maybe you're a Project Manager who is ready to attack my commentary.
Maybe you're a Developer who is ready to applaud it.

Either way, you're reading it, and that's progress.

If you work in IT, you've heard the term "requirements" before.  You have a basic idea of what requirements are, and what they're supposed to do for you, your customer and your team.  If you're on the end user side, you may have heard the term thrown around by various IT people in their quest to get you a solution that works for you.  The problem is that many people fail to understand how to avoid what I can only term "bad requirements".





In short, bad requirements happen when you do something that isn't required.  Now, that may sound redundant, but it's really that simple, if you understand what "required" means.

From the Merriam Webster Online Dictionary1:

re·quire

 verb \ri-ˈkwī(-ə)r\

: to need (something)

: to make it necessary for someone to do something

re·quiredre·quir·ing

In simple terms, if something is "required", it's needed or necessary.  Common sense, right?  Not as much as you might think.  When multiple people attempt to detail what is "required" for a given project, task or initiative, the requirements end up getting confused, until it turns into a free-for-all of what people think should be there.  Quite frequently, these are little more than opinions, but let's dig into what kinds of things you end up with.

Conflicting Requirement

• When a requirement is given that directly or indirectly conflicts with or contradicts another requirement. This most often happens when the people involved in the gathering, review or implementation of requirements change, or the user(s) population is different.

The thing with conflicting requirements is that they even apply outside of IT.  Anytime you are presented with something that needs to be done, and then presented with something else that needs to be done that is in conflict with the first, you've got a conflicting requirement.  

For example, say you are a farmer.  Your primary produce is corn, and your entire farm has been cultivated to grow mostly corn.  A major produce vendor wants to purchase your corn from you on a monthly basis for an agreed-upon rate.  You sign the agreement.  Two years later, the same produce vendor complains that you're only providing corn and not a variety of produce.  You're confused, because the initial agreement only called for corn.  The produce vendor points out that the agreement never said that you would "only" provide corn, simply that you would provide produce, and it should be assumed that you would be flexible and diversify your produce offerings over time.

The above is a perfect example of a conflicting requirement: not because the agreement was not specific enough (which it should have been anyway), but because when the produce vendor first approached you, they were clear that they reached out to you for corn.  It's therefore logical to assume that the produce vendor might not have needed anything else, or that they were getting other types of produce from other vendors.  It's not a problem to renegotiate the contract, but that expectation should have been set forth in the beginning, and it wasn't.  You're now stuck with a complaint that really wasn't your fault and could have been avoided with more clarity.

So how do you address the conflicting requirement?  By calling it out.  First, make it clear that this is a conflicting requirement, and that the expectation was that you would provide corn.  If you have additional produce types you can offer to renegotiate for the extra produce.  If you don't, you'll need to let the vendor know that you were not positioned to provide them with anything beyond corn, and move on.  The vendor may not like that answer, but it's a factual answer that protects you from further issue.  It doesn't have to be a big deal, as long as you manage the expectations.  That can be hard if the vendor is not reasonable.

Deficient Requirement

• When a requirement is given with so little information as to be nearly impossible to act on with confidence, or where the requirement is stated in such a way as to confuse the intent of the requirement.

As before, deficient requirements can happen outside of IT.  If you're presented with something that a person says must be done, usually by a given date or time, and you're not given sufficient detail to know what they are looking for, you've experienced a deficient requirement.  For example, say you're a secretary for a law firm.  The main lawyer asks you to write up a letter to a prosecutor advising them that your firm has decided to accept a plea bargain on behalf of a defendant that you're representing.  The lawyer then gets on a call and walks off.  You're left with tons of questions:  What prosecutor?  What's their address?  What plea bargain?  What defendant?  What case?  All of these are necessary in order to do the letter properly, but you were not given the information as expected.

How do you address deficient requirements?  Ask questions.  A lot of people are nervous to ask for clarification on points that aren't clear because they think it makes them look stupid when in reality, not asking the question and making mistakes will do far worse.  The person who gave you the deficient requirement may get upset that you're asking; you can gently mention that these points were not given in the first instruction, thus the need to ask.  A reasonable person will back down and apologize for not being as clear as they need to be.  Some may think that they did not make such an error; as long as you stick to your guns you should be fine.  But do not proceed without full requirements.

Requirements Creep

• When a requirement keeps changing, often because the person giving the requirement has not taken the time to think through what the true need is.

These are the most challenging types of requirements for developers, because once you've gotten to a certain point in a development strategy, it's difficult to switch gears especially if the change doesn't seem to make sense.  The best example I can give: you're asked to build a web page for a user.  They ask for certain colors, layout, etc. A week before go-live the user comes back and asks for a completely different layout.

It's important to stress up front the importance of being consistent with the requirements and not make major changes unless there is a viable reason to do so.  Ideally, most changes should be fleshed out before development begins.  There are strategies you can employ to help with this, from whiteboarding to wireframing and storyboards.  You might even do graphical mockups of the final product to allow the user to envision what the final will be.  Code freezes go a long way to ensuring you can at least get your development cycle done, then consider introducing change management afterwards.

"Wish List" Requirements

• When a request is made in the context of a requirement, but there is no true "need" behind the request. A lot of these come from multiple affected users with different ways of working.

It's important to note that these types of requirements aren't bad.  Wish list items are a great way to collect user feedback for improving an application.  However, they aren't requirements and should not be presented as such.

A good example of this:  Ford delivers thousands of vehicles to car dealers monthly.  Certain dealers sell more of certain types of cars compared to others.  When Ford polls the dealers about this, it turns out that most consumers are interested in two features that are only found on the cars that sell more.  They express to Ford that in order to sell more cars, these features are necessary and should be added to the entire fleet.

While it's certainly plausible that adding these features to every car in the fleet might spur sales, there's just as much probability that the features in question are just icing on the cake for the consumer.  Since they're features and not components of the vehicle, they aren't "required" to be installed, even if they make selling the car easier.  The other vehicles are still selling, just not as much, and there may very well be other factors contributing to the difference that the dealers aren't seeing.  Were Ford to poll the consumers who bought the cars, they might even get the same answer: that the features were enough to trigger them to buy the car.  It still doesn't make the feature a requirement.

However, say a dealer had one type of Ford car that was lacking anti-lock brakes.  They notify Ford that they think this might have been a design oversight.  Ford does research and agrees that all cars in the fleet should have anti-lock brakes as a security measure.  In this case, the anti-lock is a requirement that must be met.

"In Before Lock" Requirements

• When a requirement is presented at "zero hour" - that is, just before development begins, or just before the product is finished

This is almost always a symptom of poor requirements gathering and expectations management.  If a user is presenting requirements at the final hour, it means that their expectations for the project timeline were not properly managed, and as such it isn't really their fault.  However, you've got to ensure the integrity of the product by limiting how much you throw into the development without testing and vetting.  You should consider code freezes and development life cycle timelines to ensure that this does not happen.  Unfortunately, it is way too common.

Confidential Requirements

• When a requirement is provided but the detail behind the requirement is purposely withheld.

This sounds like a contradiction, and it is except that unlike deficient requirements, the person providing requirement has a thought process in mind; perhaps due to an overarching directive, and they are giving you something that must be done without the details of why or the impact of the requirement.  A good example of this happens in companies with business intelligence and/or analytics departments: a CFO wants to run a specific report about the company's financial outlook across a 5-year evaluation term.  There's obviously a reason behind the need for the report, but the CFO does not divulge the reason.  With proper details, the business analytics employee might choose to develop the report in a way that allows multiple complex views, so that if the initial report data does not give the CFO what he/she needs to proceed with whatever decision, they can independently change the report parameters without asking for another report.  This is obviously more efficient and allows faster turnaround.  If the CFO is adamant that the parameters be limited to what was specifically asked for, they may not be taking into consideration a need that won't exist until they see the data.

This is a trust issue.  The CFO must trust the employee's interpretation of the need for the data and allow the employee to think beyond the immediate request: if the CFO needs this data, they probably will need other data points based on what was requested, such as a longer term, more financial parameters, more product detail, etc.  The employee must trust that the CFO is giving enough information to know how best to serve the need, rather than just addressing a single request.  The net effect of this confidential requirement is obvious to see: the CFO reviews the single-point data received and determines they need more information, thus causing them to have to request another report from the employee.  The employee gets frustrated because the CFO ends up asking for the same data that was offered in the first place but was instructed not to provide.  Efficiency is lost.

IN some cases the confidentiality is warranted, such as acquisitions not yet announced.  These can be mitigated with non-disclosure agreements or other sorts of confidentiality measures so that the employees can fulfill the requirements properly, and anticipate future needs effectively.

Conditional Requirements

• A requirement created based on conditions that have not yet been met or have not been verified to be truly needed.

Another contradiction.  A conditional requirement is one where you are asked to do something based on "maybe", and it often results in extra unnecessary work and loss of productivity.  It also can result in a loss of accuracy, especially if the condition ends up going another direction and results in a shorter timeline for completion.

An example of this would be a bagel shop that fires a variety of bagels based on the anticipated purchasing pattern of its customers, where they instruct the cook to fire more plain bagels because they assume that the majority of their customers will order plain bagels the majority of the time.  In a given day, the bagel shop may start running out of other flavors because they did not properly anticipate the true requirements of its customers when choosing which to fire.  Other bagel shops that are better run will keep a count of which bagels are ordered and the statistics behind the different flavors to determine which to fire more often than others, and they will take an additional step of adding a "delta" - that is, a certain percentage more bagels than anticipated, within reason - to ensure proper coverage without assumptions.  The former is a conditional requirement: "maybe they'll just buy plain, make more of those".  The latter is a true requirement: "Looks like most customers are ordering everything bagels more than others.  Make the same amount across the board, add a delta of 20% more everything bagels, and 5% of all others, and we can adjust as necessary."

This is a small subset of bad requirements, but hopefully you get the picture, and the above helps you spot these issues. Deal with them before they affect you adversely.