Getting to the Essence of the Work


The essence is crucial to all projects, to all work areas, and to all levels of agility. Only by understanding the essence of the problem do we become able to find the correct requirements, and eventually the right solution. In fact, once you have found the essence of a problem, its solution is usually self-evident.

When trawling for requirements, much of what you hear is inevitably a stakeholder's idea for a solution, not a description of the underlying problem he is trying to solve. Your task is to interpret what is said, thereby uncovering its essence. The essence of the work represents the fundamental reason that the work exists. The fundamental reason for IceBreaker's existenceits essenceis to accurately predict when roads are about to freeze. How it accomplishes this goalthe technology, the instruments, the computers, and the people it usesconstitutes its implementation, and is not part of its essence.

You must be able to separate the essence of the problem from any proposed solution. There are several reasons for doing this. First, it allows you to solve the real problem. You won't achieve that goal if your stakeholder is fixating on some "flavor of the month" solution. Second, it allows you to avoid inadvertently reimplementing past technological decisions. What may have been appropriate several years ago when the current system was built is not necessarily the right thing today. When you discover the essence, it means you understand the real work; in most cases, the essence will then suggest the best solution.

You must be able to separate the essence of the problem from any proposed solution.


Try to imagine the essence as existing separately from its implementation. Consider this: On the one hand, you have technologymachines, electronics, networks, people, paper, and so on. Technology can be used to implement a solution to many problems. A computer doesn't know if you are running a spreadsheet or playing a gameit's just a piece of technology. On the other hand, you have the problem to be solved. The problem is some piece of work, some business policy that can be stated without any attendant technology. The problem would exist regardless of any technological implementation. That is the essence.

The essence exists regardless of any technological implementation.


You can derive the essence from a technological implementation. For example, when you approach an automated teller machine, what is the essential piece of business that you wish to conduct? "Withdraw money from your bank account" would be a logical answer. The actions that you have to takesuch as insert a plastic card, enter a PIN, have your retina scanned, and so oninvolve interacting with the technology the bank chooses to use. In contrast, the essence is that you access your account and withdraw money from it.

McMenamin, Steve, and John Palmer. Essential Systems Analysis. Yourdon Press, 1984. The title refers to "essence."


Note how technology-free that statement is: "You access your account and withdraw money from it." Consider it, and now consider how many other ways you could "access your account and withdraw money from it." Lots of technological possibilities exist, but only one essence. And that is the point. The requirements you are looking for are the essential requirements. How they are implemented now or in the future is not important to you at the moment.

As a consequence, when you are trawling for requirements, you must look past the current implementation. You must also ignore the future technology, for that matter, however exciting it may be. Instead, focus on the underlying concepts that exist because of the real work.

Robertson, James, and Suzanne Robertson. Complete Systems Analysis: The Workbook, the Textbook, the Answers. Dorset House, 1998.


For example, the current implementation of IceBreaker uses a computer to interpret the electronic signals from the weather stations and record the road-surface temperature and moisture content. The engineers use a PC to run their analyses of the freezing roads. But all those devices are incidental to the essencethey are just the means chosen to carry out the essence. Look past those devices and ask, "What is this activity doing to help the work?" "What policy is being followed by the activity"? That policylet's call it "the fundamental policy"is the essence.

Why is this important?

If you write a requirement that contains a technological element, then that piece of technology becomes a requirement. For example, suppose that you have a requirement like this:

The product shall beep and put a flashing message on the screen if a weather station fails to transmit readings.


What's wrong here? The message is now consigned to a screen. Perhaps there are better solutions, such as telephoning the road engineers, sending an e-mail message, or launching a weather station diagnostic application. Now imagine you write the requirement like this:

If a requirement contains the means of implementation, then it is a solution, not a requirement.


The product shall issue an alert if a weather station fails to transmit readings.


Because you have described the real, the essential, requirement, the designer can now cast about and find the most appropriate solution.

As another example, consider this requirement for a ticket-selling product for a metro train:

The traveler shall touch the destination on a map on a screen.


The stakeholder wanted to employ a touch-sensitive map of the metro network and have the travelers touch their destination station. The product would compute the appropriate fare and, as a bonus, show an illuminated pathway of the fastest route to the destination. This might be a clever implementation, but it is not the essence of the problem. It is not the only way to implement the requirement: Perhaps better ways might be discovered. If the requirement is expressed in its essential form, it looks like this:

The product shall accept the destination from the traveler.


The designer is now free to study the best way to implement the essence, and can use other technologies (within the constraints of the project) to get the traveler's destination into the product. Had the touch screen idea been left as the requirement, it would have resulted in a less than optimal product. Indeed, studies in this case showed that the majority of travelers did not know the rail network well enough to be able to locate their destination quickly enough.

The point is that we should not prejudge the implementation, no matter how well we think we understand the problem, nor how appealing the technology might be.

Letting go of these preconceptions is not always easy, and over the years we have found it one of the hardest concepts to convey to our clients and students. It becomes even harder if you are using eXtreme Programming. This approach, which is aimed at producing solutions, emphasizes getting to the next iteration as quickly as possible. But something is missing here: How do you know if the solution is addressing the real problem? Have you included a brief pause to think about the essence of the problem? Have you carefully scrutinized your enthusiastic customer's ideas about how to solve the problem? Once you do, you may come up with not only the best solution, but also one that will last even after today's technology falls out of favor. When you address the real issues, your solution does not have to be chopped up and changed as successive users tweak it to do the job it should have been doing all along.

When you address the real issues, your solution does not have to be chopped up and changed as successive users tweak it to do the job it should have been doing all along.





Mastering the Requirements Process
Mastering the Requirements Process (2nd Edition)
ISBN: 0321419499
EAN: 2147483647
Year: 2006
Pages: 371

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net