When Requirements Collide

I've always thought that implemented software functionality should enable users to accomplish their goals and help the business achieve its objectives. However, a recent experience led me to believe that sometimes a conflict might naturally exist between business requirements and user requirements.

I traveled to a city that has converted its standard parking meters to a kiosk system. To pay for parking, I first insert my credit card into the kiosk for that block. The kiosk displays the current time and the amount of money I have agreed to pay so far. Parking costs 75 cents per hour, with a one-dollar minimum for a credit card purchase. Pressing the up or down arrow key changes the displayed payment amount by 20 cents. This process of figuring out how much time to buy requires a lot of mental gyrations.

Rather than using my trusty geek calculator watch (yes, I do wear one), I eventually concluded that I must have put in enough money. The kiosk printed a parking sticker that displayed in large digits the time at which it would expire, which was what I really wanted to know in the first place. It was also considerably more time than I needed.

It wasn't helpful for the kiosk to show only the cost of the parking request before I completed the purchase. I didn't care how much it cost; I just needed to buy enough time to avoid getting a parking ticket. It would have been much more useful had the kiosk displayed either the amount of time I had requested to buy so far or the expiration time based on how much payment I had put in. At first glance, this struck me as a poor user interface design.

But then I realized that perhaps this wasn't an accident.

I think in terms of three levels of requirements for a software project. At the top level are the business requirements, which describe the business objectives for the project and address the question of why we're undertaking the project. Next, we have the user requirements, which describe what users will be able to do with the product. In this case, the primary user requirement-a use case-was to purchase a parking sticker. Functional requirements, the third level of requirements, describe what the developer must implement. Obviously, there's more to requirements than this simple model, but this will suffice for today's discussion.

I've always preached that alignment between the three levels of requirements is vital. Developers must build the software that will let users accomplish their tasks, and these tasks must align with achieving the project's business objectives. However, this parking kiosk experience suggested that perhaps collisions between business requirements and user requirements are to be expected in some circumstances.

The "business" in this case was the city's parking department. I presume that one of its business objectives for the kiosk is to generate as much parking revenue as possible. Unlike with traditional parking meters, where you might spot an empty space with time still on the meter, every person parking in this city must buy a separate kiosk sticker for his use of the parking space. Building a user interface that encourages drivers to buy more time than they need generates additional revenue for the city. A single parking space thus can generate revenue from multiple drivers concurrently if the first one bought more time than necessary.

As a user of the kiosk, though, my objective is to buy just the right amount of time that I need. This kiosk made it too easy for me to spend more than required. Sure, I could have calculated how much money to spend to buy just enough time, but not everyone wears a calculator watch.

I'm not big on conspiracy theories, and I'm not accusing anyone of devilish design here. But is it possible that designing the kiosk's user interface not to show the amount of parking time requested was a conscious decision? I'm going to watch out for this kind of disconnect the next time I drill down from business requirements into the detailed requirements that are intended to achieve the business objectives.