In every requirements management effort there is a moment when the seemingly inevitable question comes up: “Are we talking about business requirements or IT requirements”. Other taxonomies are in use - the BABOK lists 5 levels- , this specific question seems to be triggered by whom should own and validate which requirements.

I will not discuss the role issue but I will demonstrate a clear distinction between business requirements and IT requirements. The answer boils down to dependencies.

Business requirements

A company operating ferries for accompanied heavy goods vehicles has the following requirement.

<strong>REQ 001</strong>: The time it takes for drivers (without a reservation) to book a sailing will be less than 15 minutes.

<strong>Rationale</strong>: Less time lost means drivers with a choice will favour our company.

This is a very precise statement about a capability (sell) of the company, it does however not specify a specific solution, and the requirements stays the same no matter what the solution looks like. As the process is designed another requirement is added:

<strong>REQ 002</strong>: Drivers will receive a coat-hanger like paper that must be hung from the rear view mirror, displaying information about the boarding time and gate on both sides.

<strong>Rationale</strong>: No need for the driver to memorize the gate he needs to drive to and no risk of looking at his boarding pass while driving.

This requirement is very precise about what is needed. The requirement may change if the process changes, it does remain the same no matter the precise (IT) implementation.

It’s quite possible the hanger was proposed during functional analysis by a member of the IT team. If however the requirement depends only on the business process, independent from the implementation, it’s a business requirement.

In order to speed up the process and reduce errors, it’s decided to use license plate recognition.

<strong>REQ 003</strong>: The license plate registrations of the trucks driving to the sales booth will be captured automatically. The registrations will be available to the sales clerk.

<strong>Rationale</strong>: The registration information is used throughout the process, the identification captured in this way reduces the number of erroneous registrations caused by typing errors.

In this case it’s very tempting to write: “…. using ANPR cameras (Automatic Number Plate Recognition) ….”, as it seems to be the only possible solution. This would make the requirement dependent on a specific technology. Writing the requirement without reference to one technology, the goal is still clear and the solution remains open.

IT requirements

The job of the IT team is then to design and build a solution for the IT component(s) of the process. The solution will be sliced into stories, use cases or any other means of describing the functionality in scope for the current processes. For each, more requirements will be uncovered. One use case or story is “verify vehicle characteristics”, where the sales clerk verifies whether the vehicle characteristics of the vehicles with a reservation are as specified.

<strong>REQ 004</strong>: The sales clerk can select the data for the vehicle at his booth from a list with all the vehicles in his lane. The list with vehicles is ordered chronologically as the vehicles arrive at the booth.

<strong>Rationale</strong>: The ANPR system processes different vehicles in parallel. Some pictures are harder to process than others. The output of the system is not necessary the order in which the vehicles are approaching the booth.

If this is included in the narrative of the story or use case, the rationale should be included too so that the reason for this is clear and this requirement isn’t dropped along the way and nobody remembers why this is a requirement.

As important as this is for the business users, the requirement is there in this form because a specific solution has been chosen (the list from which to choose). The requirement is a specification on top of a solution and therefore an IT requirement. This requirement is not independent from the implementation.

After the first release of the system another requirement is added:

<strong>REQ 005</strong>: The sales clerk must be able to remove a vehicle from his queue.

<strong>Rationale</strong>: The ANPR system sometimes creates two entries for one vehicle. Fixing this (double entry) issue is prohibitively expensive.

This change request is an IT requirement even if it’s formulated by the product owner representing the business interests. The requirement adds something to a specific solution.

Conclusion

So the way to distinguish both boils down to the direction of the dependency arrows.

Why should I bother, you might ask.

1. Business requirements leave more room for agility and creativity.
2. IT requirements are more volatile and will have a different lifecycle.

So it pays to know the difference when planning reviews and setting up change request procedures.