Simplify The Requirements

SimplifyTheRequirements is a relative of DoTheSimplestThingThatCouldPossiblyWork. Of course, once you have simplified the requirements, then you can still DTSTTCPW. However, you might not think to simplify the requirements - most people don't explore the dimensions of negotiation in them. I think I was in the industry 20 years before I ever saw someone renegotiate the requirements the users gave him. I was astonished, because he had turned a large nasty convoluted set of requests into one that we almost had ready. Just by showing up and suggesting to the users they maybe didn't need what they asked for.

I didn't expect to soon find another case of a person with sufficient user-domain knowledge to question the requirements, but uncovered something different and more interesting... while in Norway, working on a national, mission-critical, online, COBOL-based banking system (I list all of that to highlight that I knew nothing about either the requirements or the implementation technology), we ran into an unpleasant mutual exclusion problem (also not my area of expertise) - having to do with two processes going through sets of unlocked DB2 tables, one updating, one reading. Before the two teams of people in different companies threw in the towel, I reviewed the principles of mutual exclusion, and came up with a roughly 2-page proof of a tricky algorithm that would work.

We simplified the algorithm and proof a little, and presented it to the two groups. They accepted, albeit a bit slowly. On the way home, possibly thinking of DTSTTCPW, I concluded that this was a dangerous solution. Any coding change, and the whole proof would have to be redone. The COBOL programmers weren't going to do that. So I asked my colleague if we couldn't remove some of the requirements.

He and they kept finding parts of the problem statement that were unnecessary and I kept finding shorter proofs. Even in an off-hand remark, I asked, "why do you need all these data? don't you have copies?" and they said, "oh, we just need them as a checksum." Oh! just a checksum! we can provide you with a checksum! and so on. By the time we were done, the only thing that had to be done was compare the timestamps in two tables, being careful to read table A before table B. Proof was trivial. Code was trivial.

In fact, we never figured out how to test the mutual exclusion, because they couldn't generate test cases that would get in between those three statements. They did, however, before we went live, find a case of a misreported bank balance based on the previous, unlocked database program.

The point of the story is that even knowing next to nothing about the problem and the technology, merely persisting with my questions, the experts simplified the problem to the point that a really simple solution could be used. We really did do the simplest thing that could possibly work, but coming in through a different door. So questioning complicated requirements is now near the top of my bag. --AlistairCockburn

This is so natural for me that I don't think to say it (cf AskWhy). Thanks, Alistair.

Here's a thing that I've noticed happening a lot on the C3 project. When we talk about a Story, and generate the EngineeringTask's and the estimates, the programmers will naturally talk about "if we have to do this" and "if we didn't have to do that" among themselves. The users are there listening. When they hear that they can have what they asked for in four days, and something slightly different in two, they often (but not always) pick the two. What's neat about it is that the people don't feel they're negotiating, they're just talking about alternatives. No pressure. It's a very interesting effect, unexpected (by me at least). --RonJeffries

On in-house systems, I've found it useful to hang out with the end users a lot. The dynamic between meeting people one-on-one and in groups seems to be powerful leverage. I meet with people individually to make sure that I get as many different views of the system as possible, and strategically in groups so that users with a simpler view of the requirements have the opportunity to negotiate the others down.

It is funny, what Alistair describes almost sounds like therapy. Or at least the old Eliza AI program. When people are confronted with their ideas there is an opportunity for change.

-- MichaelFeathers

I'm in the midst of a dilemma which is related to this page, which I have entitled SimplestForUserOrProgrammer. -- BobHaugen

In my experience on doing RequirementsProcess?, I have collected a variety of RequirementsQuestions which have helped me along the way. -- MarkInterrante

I was once pairing on a story with someone. We got about 1 hour into our work when we discovered that a rather large change would need to be made to a framework in order to complete a user-interface story. The layout of the new UI required a right-justified form and until that time, every form in the system was left-justified. At the time (and this was prior to our using XSLT), changing our home-grown, ultra-lean html-framework to support left and right-justified forms would've doubled or tripled our story estimate. So the story was most definitely at risk. What did we do? We decided to go talk with a couple of our customers - a few product managers. We explained the problem and wondered if they could come up with a modified design that would make it easier for us to implement the story and put it back in the range of our original estimate. At first, they said they couldn't come up with a different design. "Are you sure?" we asked. They decided to talk it over with the lead product manager - a very bright guy. Within an hour, they came back with a design that everyone agreed was better than the original and didn't require anything to be right-justified. We implemented the story on time and felt great about our collaboration with our customer. (Actually, this particular story is shown with a completed X and the initials of yours truly on page 98 of Planning Extreme Programming).

There was no defined process for what my pair and I did that day. We were working on a highly collaborative team in an open-workspace with honest-to-god on-site customers sitting right next to us. The company was (and still is) a dot com. The company could not afford to waste time or energy. We knew that. Everyone did. We dealt with the risk that we had discovered in a story as soon as we understood that time and energy would've been wasted had we not acted to manage the risk.

-- JoshuaKerievsky

I usually approach this from the opposite direction. Most of my clients have been pretty adamant that they have a good handle on what their customers expect out of a piece of equipment. (Of course, they say this even when they are completely, totally wrong.) They'll have some requirement or other that I can see will cause all manner of headaches down the road. I will feel them out a little to see how serious they are about a requirement, but iff they still insist they want it I will take the projected use of such a facility to its logical extreme. "Gee, how are you going to handle this?" I ask. "Oh, that won't come up," they assure me. "Really? What happens when the customer tries to use it this way?" I'll continue. "Uhh..." they say.

And so it goes.

With smart clients you can usually show them how big the hole in the end of the gun is and describe how big a hole it will make in their foot. You can often convince them that the pain from that hole will be correspondingly large. They'll back away from the trigger and let you convince them to rework or replace dangerous requirements with those that make more sense and can be implemented without anything like the kind of risk they were facing. If they insist on shooting themselves in the foot, though, you have to stand back far enough to avoid the splash and cover your ears. Oh, well. LetTheClientDecide, such as it is.

-- MartySchrader

I've updated this line of thinking with my blog entry http://alistair.cockburn.us/index.php/Simplify_requirements_with_adaptive_sampling. Same line of thinking, new words, some new examples, and maybe a new insight or two. --Alistair

CategoryRequirements, CategorySimplification