Thinking about the requirements

Users don't know what they want until you show it to them.

-Unknown

As good requirements are trickling in, it is important to think about their implications and how all the requirements are interrelated. After all, we are putting together an entire solution that will meet the requirements in a seamless manner. Two or more requirements in combination can actually generate a third requirement. Let’s examine this over-simplified example.

Requirement 1: The system will be able to receive alerts via CAP 1.1 and CAP 1.2.

Requirement 2: The system will allow the user to distribute incoming messages via CAP 1.1 and CAP 1.2 through a variety of channels to include CCTV video displays, speaker arrays, telephone speakerphones, computers and SMS.

So this is pretty straight forward; we receive alerts via a specific protocol and the user can send the message out via a wide variety of systems. Let’s see how it would play out in real world.

An alert comes in and the user sees the alert. The user goes into the CCTV system to publish it to displays. Then the user taps into the speaker array system and does Text to Voice to sound off the alarm, then the user taps into the phone system and transmits the recording to the phone system, then the user goes into another system to send the alert to PC and finally to the last system to send out the notice through SMS. In the end, the process took much longer than expected and the user is not happy and the distributed message may not be relevant anymore.

A derived requirement in this scenario could be:

Requirement 3: The system will provide a standard interface for transmission of messages from Requirement 1 through channels in Requirement 2.

In this scenario the user would receive the message, go through some checkbox list of systems that the message needs to go out of, click a button and voila!

Business users will not be able to proactively see the solution in the skeptical light that engineers can. As such, an experienced project team should develop additional requirements to improve end-user experience and usability. Naturally, these “good ideas” need to be vetted through the customer prior to being included in the design requirements.

There is much more to properly gathering and documenting requirements. However, I keep running into this scenario and as such wanted to address it.  

Requirements

Alice: Oh, no, no. I was just wondering if you could help me find my way.
Cheshire Cat: Well that depends on where you want to get to.
Alice: Oh, it really doesn't matter, as long as...
Cheshire Cat: Then it really doesn't matter which way you go.

The requirements are the start of it all. If there weren’t any we would all be in the unemployment line. Without solid requirements, the solution will never meet expectations. It’s as simple as that. Most of the information here is common sense and industry’s best practice; however it still gets ignored most of the time. You would be surprised at how many systems start being designed without requirements. There are a few things that I would like to add on top of the regular “requirements gathering” curriculum.

There are plenty of resources on requirements gathering and I will not attempt to explain the entire process, however here are some common pitfalls that I have seen:

●      Requirements gathering and validation is a very politically and fiscally challenging process. Few people realize that there is a very direct relationship between requirements and money. Simply said, the more you ask for, the more you will need to pay. If this is not acknowledged, the project team needs to help the customer manage expectations.

●      Another common mistake is for incorrect requirements, your requirement can’t be to buy product XYZ. The requirement needs to be for a system that provides functionality A, B and C. Based on this the project team should conduct market research and select the best product or a combination of products to meet the requirements.

●      The requirements shouldn’t be blindly accepted by the project team. If the information you need is not there, you need to take a step back and get the right information. This is sometimes difficult.

●      Nothing kills morale more than working for weeks in one direction only to find that the requirements weren’t accurately documented and having to shift gears.

●      Requirements are complete when all requirements have been documented and mapped to validation criteria which in turn map to validation scenarios. Documentation of requirements is essential because it communicates the requirements to all parties involved. Language in the document needs to be plain, clear and specific.