Comment:     by Krishna Manda 10/2/2008 Hey Karl..well the same applies with ATM MACHINES too.You will be penalized for inserting XYZ card into ABC machine.Now at the end of the day ,user need to know how much hes being charged(as Mr karl wanted to know the amount of time for parking)for using a card which was not issued by a particular bank.The bottom line here is, should the ATMS revile service charges to the users for using wrong debit cards.Now can i say the BUSINESS,USER and FUNCTIONAL REQUIREMENTS are colliding?
	Comment:     by Venkat Moncompu 6/19/2008 Hi Karl, Assuming that this was indeed a slip between cup and the lip, so to speak between user requirements and business requirements, would an approach such as model based testing have "caught" this or similar type of requirements gaps? In the industry, we all create use-cases (or some sort of system requirements)but there are very few who do a validation of these models against user needs or requirements. Could this have been another instance of this (mal)practice? Thanks Venkat
	Comment:     by Torsten Zelger 8/3/2007 It is even worse in Scotland, since this is almost exactly what happened to me during my holidays last week. I parked my car at the parking space of the Fort Augustus visitor center and was surprised that the parking meter gave no information about how much money to put in there or how much cents would turn up into how much parking time to not get fined. So the machine was like a big surprise box. I put in a two pound coin and then press the green button to print out the ticket so you can see whether you paid enough. But when you print it out you cannot extend it since it is not related to a specific parking place. Of course I paid far too...Read On
	Comment:     by Roger Cauvin 5/29/2007 I always like real examples to which we can all relate. What I see as the issue here is not business, user, or functional requirements (BTW, how do nonfunctional requirements fit into these levels?), but problems various stakeholders are trying to solve or avoid. The "business" is, as Karl speculates, probably trying to solve the problem of insufficient revenue. Users are trying to avoid the problem related to getting parking tickets and avoid paying a lot to park. Thus the "business" objective of maximizing revenue conflicts with the users' goal of minimizing cost. However, there is not as much conflict as it might...Read On Author's Response: 5/29/2007     Thanks for the input, Roger. I see nonfunctional requirements fitting primarily at the user requirements level, but they can appear elsewhere, such as a business objective for scalability. We can approach requirements either from the perspective of "problems to solve or avoid" or "objectives to achieve". Both are valuable and there's a certain symmetry that might arise. Regardless of the specifics of this incident, the main message for me was the notion that the business that's building the product and the people who will use it might not always have congruent goals. This is more likely with commercial products (or public-use products, like this one) than with internal information systems, but it could arise in more situations than I had previously considered.
	Comment:     by Karl Wiegers 5/8/2007 That could well be the case, Dennis. But in addition to the cost, I'd still like to see how much time I bought, or even better, when my parking sticker will expire. For me, though, the main insight from this experience was to realize that sometimes there *could* be a disconnect between the business requirements and the user requirements, which I really hadn't considered before.
	Comment:     by Dennis Essa 5/8/2007 There could be another nefarious entity involved in the requirements process - the law. There may well be a requirement that the user be able to tell how much money they are spending (consumer protection law). Or it could be an attempt at risk reduction by removing the possibility of the user not knowing how much money they were spending. [You and I want to know how much time, but SOMEBODY would sue the city because they screwed up the math and got charged more than they think they "authorized".:]
	Comment:     by Sanat Sharma 5/8/2007 That's great Karl. Same thing happened with me in a parking slot. I was asked my car number by an automatic machine on an entry gate and when I entered the number, the machine said you are not eligible to park this car. When contacted the local guy there, he manually opened the barrier and allowed me to park the car. When asked the reason, he said "This is working as it is from the day one itself". Funny ..... Now its confusing what was Business Requirement, User Requirements and Functional Requirements in this case. -- Sanat Sharma Author's Response: 5/8/2007     Thanks for sharing this story, Sanat. The business requirement behind the automated parking system was probably to save money by automating previously manual operations. The user requirement might have been for you, the driver, to be able to enter the lot and park your car. The functional requirements involved the operations of asking for your car number and taking actions (such as opening the gate, or not) in response. It's hard to know exactly what went wrong internally in this case. But if the system was flawed such that manual intervention was still needed frequently, the parking lot owners aren't going to meet their business requirement of saving money!
	Comment:     by Robert Rose-Coutre 5/7/2007 Great story Karl! You don't have to be a conspiracy theorist to see a similar pattern among user interfaces that profit the respective businesses. For example, a pre-pay gas pump had a big green "Yes" button to push when the display said "Would you like a receipt?" One day the question changed to "Would you like a car wash?" The display being hard to read at all in daylight, and the habit of seeing "Would you ...." and quickly pushing the "Yes" button must have made them a lot of money. Pushing "Yes" immediately takes another $1.00 out of your credit card and then changes to "Would you like a receipt?" My first time, I didn't even notice...Read On Author's Response: 5/7/2007     Thanks for the great (in an informative way, not a happy way) story, Robert. This seems like an example of social engineering. You were already conditioned to say "yes" so the gas station could switch the question to one that was more in their favor and naturally you keep answering "yes". Very clever....

Back to Top