Eliciting Requirements

Context: Xp Project
Problem: Customer does not give the requirements that we think will come in future. The resulting plan may produce exorbitant costs for change later when these requirement come up.
Example: web-based corporate IT project, current solution serves 100 people, later rollout to 10000 people may happen. Customer gives no story about scalability.

Proposed Solutions:

Using your experience with similar projects or similar environments, pick out appropriate stories and suggest them to the customer, making sure to express those stories in terms the customer cares about: cost, time, risk, etc. Once you've suggested those stories, the decision to include them in the current iteration belongs to the customer.
As above, present stories to the customer, but take a more active role in advocating their necessity.
Cheat. If communication with the customer is time-consuming, and the story you're thinking of is quick, maybe you can just implement it without asking.

Why do we ignore the cost of communication between software developers and customers? If it is cheaper to implement an additional functionality than to prepare all the data needed for the customer to make a qualified choice about inclusion of such functionality, or if we just have the experience that customers always agree to add this sort of functionality, isn't it better to cut the cost and not ask the customer? --NikitaBelenki

: - Hans, we think you'll be glad later if we implement logging sometime soon.
: - You don't say, Bob. That's fine by me, but how much would that cost, and earn?
: - Piotr here tells me it's a two-day story. It might save weeks in support costs.
: - Go for it.

(...or...)

: Support costs aren't much of a concern yet. Can we save it for next iteration?

That's a cost of 5 minutes of conversation. If it takes less than 5 minutes to implement, I'd just do it. ;)

Though this dynamic is often influenced by how easily the client-side can make small decisions. If you have a ProjectManager who has a lot of say over day-to-day choices, then getting the decision in 5 minutes might be easy. But if it's the case that the ProjectManager has no power at all over the project - a depressingly common occurrence - then the conversation might go more like:

: - Hans, we think you'll be glad later if we implement logging sometime soon.
: - You don't say, Bob. That's fine by me, but how much would that cost, and earn?
: - Piotr here tells me it's a two-day story. It might save weeks in support costs.
: - Okay, let me call a meeting with the five people I have to report to, and we'll hash out all our internal politics and technical misunderstandings and come to a decision. And by the way, do you think you'd be able to conference-call in on that meeting? It shouldn't take more than three hours.

Of course, if you have this sort of client you probably can't do ExtremeProgramming anyway.

Okay for the opposing view.

: Project Manager: Did you finish the XXXX task?
: Developer: Not yet.
: Project Manager: Why not?
: Developer: Let me show you this neat new a capability I put in.
: Project Manager: Does this help in the XXXX task?
: Developer: No, but I'm sure the customer needs it.
: Project Manager: When can you finish the XXXX task?

This is an accurate paraphrase of conversations I have had with developers. The point is, if you have a backlog of work to accomplish, it does not make sense to spend time on unrequested work. I have also found that the "two day change" is rarely accomplished in two days, and the more the developer tries to prove that he can get it done quickly, the more likely the change is going to cause future problems. Finally, I have observed that the vast majority of these new capabilities are never used by the customer after delivery. It seems the customer often does know what he needs to do his job.

In managing projects, I would prefer to take the risk of getting the job done early with no extra bells and whistles, rather than being late and trying to shower the users with extras.

-- WayneMack

If I get called at 3:00 AM, or I have to work unpaid overtime to solve problems, then as I see it I become a "customer" in some sense and I'll assert my right to dictate that a few support stories be implemented to ease my pain. Yes, this is an unhealthy "tit for tat" kind of relationship, but sometimes things can degrade to just that low of a level.

When I was consulting, there was a small movement in the early 90's to describe every detail of a system to the customer before implementing it or vice versa. No matter how small the decision, the customer had to make it. We used to call this the pass the buck or cover your ass methodology. The usual result was no ConceptualIntegrity, a system that was designed by novices. But the consultant could always respond that "Hey, this is what you told me to build". The goal wasn't the system, it was the contract. This approach doesn't work when you are dedicated to or vested in a product or product family - in those cases, you are hired and given the position you have because of your experience and skills. I don't understand the details of marketing and marketing doesn't understand the details of software architecture.

Engineers will always need to manufacture requirements. The important issue is that requirements are collected up-front and that the customer is involved in creating as many of the functional requirements as is possible. In most cases, the customer (especially if it is a marketing department) wants to define the features or overall feel of the system. They don't want to, nor should the have to, comprehend and dictate the optimal length or space between the threads of a screw.

-- RobertDiFalco

Yah. This happens a lot, folks. Over on ClearRequirements I prattled on about a certain client who couldn't even deal with a missing requirement when I rubbed their nose in it. I created the requirement from a clean white sheet of paper and they chose to ignore it. Oh, well. -- MartySchrader

...had UserStories from the customer indicating that they want the logging done a certain way.

Why does the customer need to understand the low-level details of transaction-logging, internal diagnostics idioms, or automatically generated problem reports or support? Maybe you can reuse this to derive information for dynamic-failover. Who knows? The customer shouldn't. Maybe they know they want user to be able to generate automatic problem-tickets. You are hired because you know how to develop this feature. If this is a commercial product where, say, marketing is a proxy for the customer or user, you can't rely on them to have the same knowledge that you have. If one always relies on the customer to make educated decisions about low-level design issues or each subsystem, the project is doomed.

If the customer wants automatic problem tickets, go for it. If they want transaction capabilities, go for it. But in both cases you have a UserStory that does justify the work you've described. That's all I meant by saying the customer "wants the logging done a certain way", i.e. it must have capabilities that go beyond System.out.println() or util.Debug.log(). If you're writing a CAD program, chances are the customer doesn't want to be paying for a logging framework.

What the user says they want...

What the user says they want when they are thinking of payment is not what they will want when the system actually fails or has problems. How does it sound when you say to your customer we asked you if you wanted X but you said no, feature X would have prevented just such this occurrence. When 5 layers of management are breathing down your neck to "just make it work" only then will you understand how hollow putting everything back on the customer truly is. Developers actually need to bring some professionalism to the party, not just be order takers.

YAGNI isn't about that. It's about first finding out what the customer actually wants (and finding it out with the customer's informed knowledge of their own problem domain), and then doing that and only that. Which IMNSHO is what 'professionalism' is all about. See ReduceSneakyScope.

The customer is supposed to own requirements. There's nothing wrong with going to the customer and saying "Look, in my professional opinion, we want to implement some logging functionality. If we don't, it will make diagnosing problems in the field a lot harder. If we do, it will cost us a little bit of extra time each iteration, because we're putting logging statements in (plus the time for the framework to evolve), and there'll be a performance hit. Come back to me and tell me if you want to do it."

It's about giving your customer options. A smart customer will listen to anything you say, as they're paying for your professional expertise. For all you know, logging was something the customer was going to ask for later, and by the way, here's the format we want it in. The right question asked early on would prompt the customer to give you that format early on.

Communication is what it boils down to. It's okay, even good, to give the customer ideas for stories. "Have you thought of this? Is 24/7 a requirement, or are nightly and/or weekend offline maintenance cycles acceptable?" The customer and you talk about what it will take to implement and what business value it will give, and then the customer decides when to do it.

But once the customer is aware of the issue, the customer owns requirements.

The customer isn't going to give you a requirement that all error messages be logged in a way that support people (IE: you) can view them to help resolve problems. Most customers simply expect the system to work, without error, forever. If it doesn't, they consider it your fault. (And they may or may not be right. ;-)

In an XP environment, this may mean that you should prompt the customer with issues that have, in your vast (or half-vast ;-) experience, have been issues. Like...

: "Is it OK if the system corrupts data in the event of power outage?" (A: of course not)
: "If a power outage or physical disk failure occurs, is it OK to lose that day's work (restore from a backup) or must the system ensure that all work is recovered - at a cost of XXX ideal man days (IE: transaction logging)?"
: "Do you expect the end users to resolve their own problems, or will they rely, on occasion, on support from the developers or a help desk?" (...and if so, what infrastructure is required to provide this support.)

As the manager of a project I'm in charge of balancing all the factors in meeting a customer agreement. Part of the balance is using my 20 years of experience to make judgments. Sometimes I do something that won't provide a benefit in this quarter but will pay off in the next quarter. That's called experience. Vision. Judgement.

Mostly my judgements are right. Sometimes they are wrong. Not making a judgement is not the best response, however. Much of this page would seem to advocate not making judgements because something may go wrong. You should have enough experience to do better than that. If you don't you shouldn't be managing the project.

These would be sound principles if managing software projects entailed only giving directives to a number of technically interchangeable engineers; and they in turn were allowed no initiative. If this were the case, then no other method would work.

This isn't what we're discussing. We're discussing an engineer's justification in adding, of her own initiative, a feature such as logging, without referring to her customer - who might very well be an experienced project manager, such as you describe yourself above. As a project manager you would want a say in that decision. XP asserts that this puts you in the CustomerRole?.

Is this an individual level decision or a system level decision? Logging has systemic implications that shouldn't be made by a developer using their local view. In addition there are schedule and resource issues to be resolved. Schedules/features are constant flux so it's hard for a developer to be aware of the current set of trade-offs/compromises.

I would be wary of characterizing a developer as a person who can't or shouldn't be aware of a set of contradictory forces in constant flux. That's almost a definition of the core skill involved; it's unbelievably easy to set up a shifting balance of contradictory forces when coding.

To return to the engineering and medical analogies, XP is not saying that the customer should supervise every rivet or each suture. Instead, XP calls for business to make the decisions that matter to them. An engineer might tell the city council that the bridge could be 40% cheaper if it had only four lanes rather than six (because it would require fewer supports), and let the politicians decide whether the extra traffic is really worth the cost. A doctor should inform a patient about treatment options, like a new kind of surgery that allows the patient to recover faster (but occasionally has severe side effects). The patient might just say "whatever you think is best", but at least they should have the option of deciding.

Guess we have a different idea what a rivet represents in the software world. If logging isn't a rivet then I don't know what is. You seem to promote low level decisions up to be business decisions. For me at least that is not a reasonable way to work.

Does adding logging impact the schedule enough that the customer will notice? If not, then the customer does not have a business decision that they need to make. Suppose that logging does take significant time. In XP, the OnsiteCustomer should be given information to make a business decision. That information would include the team's beliefs that logging would be difficult to retrofit later, and that logging has often saved time in debugging. If a team really wants to use logging, then a good customer would accept the schedule delays in hopes of saving debugging time later. If either the developers or the customers believe this decision-making method is unreasonable, then they probably shouldn't use XP.

However, in many professional projects it is good to have a small range of discretion before bothering the customer. The bridge-builder wouldn't bother the council about a single $20 cost overrun on a $40 million project. A project using XP probably wouldn't worry about a single 2-hour delay on a 4-day task. In XP, this discretionary range should be smaller than most methodologies because of the OnsiteCustomer practice.

You are running a risk that you will not get all the functionality implemented that was asked for

Those are risks one weighs when trying to meet an agreement. You look at your schedule, all the possible things you want to do, and then decide. The customer has requirements and we may generate other requirements in meeting customer requirements. If we think it's important and we'll make the schedule then we'll do it. Otherwise we won't. Seems very simple. In this context, Yagni can seem like an overly simplistic rule. And a rule that smells a bit because it's applied to all situations, regardless of whether it's appropriate. If instead, you were to let the work guide you, perhaps the rule wouldn't seem so universal.

It is unprofessional to put in logging, *or any other feature*, simply because you think it will save you time down the track. If you honestly believe that, make the business case for it and get the customer to accept it. If they don't, then quit; the project is obviously doomed, right?

Where do you stop with this strategy? Why don't you consult with the customer on every line of code? Why don't you consult with them on every micro decision in the project? Do you ask the customer if you should stock jolt or diet coke? At some point you actually make decisions on your own. Where is that point? It's hard to imagine your stating a line because everything effects a project. Everything.

How about if the first time you had a doubt, however small; even if, say, it concerns a single line of code; you went to the customer and asked? They might tell you to bugger off and not bother them with one-line issues, which you'd stop doing. You'd repeat the process with five-line, ten-line, hundred-line issues; not literally LOC metrics, of course, you can use the preferred "story point" metric. You'd translate it into LOC if this was what the customer understood. You'd repeat until you and the customer knew how large the critical issue size was. You'd do it at the start of the project, and of course you'd tell the customer why you were doing that and secure their agreement.

Could it possibly work then?

For me that demarcations is based on the requirements we agree on, the schedule, budget, and acceptance test. This is what the customer wants. No customer I?ve worked with generally cares in detail how get there as long as we meet our agreement. Even on very large $200 million projects. Some form of logging (security, operation) is usually a requirement, but for the sake of argument, if we think it will help us meet our goals, we do it. If we need a larger disk and it's within our agreement then we'll do it. If we need to do something outside the scope of our agreement then of course we'll negotiate.

A customer can't override that no more than a customer can tell an architect to design for inferior materials. Wanna bet? It's a far nice idea to design a house for a steel frame rather than a wooden one. You need a lot less framework (because steel is stronger than wood), it goes up faster (because there's less framework), it will be better resistant to earthquake and storms, and you don't have to worry about termites. However, very few architects will say "oh, you really should have steel in your house". None of them will go and put it in without telling you. The reason is that steel frame houses cost nearly twice as much to build as wooden-frame houses.

The equation is simple: if you are working on putting in logging functionality, then you are NOT working on functionality the customer has explicitly asked for. You are running a risk that you will not get all the functionality implemented that was asked for, and you are running that risk without consent from the customer. Now, unless you've got penalties in your contract for late delivery of an iteration, this is unfair, as you're assuming a risk that you won't be responsible for. Furthermore, the logging itself has business impact. The customer may have a particular format that they like their logs in. They may not appreciate the impact on performance that a logging system imposes. They may have a particular environment that makes logging problematic (say, a read-only file system, and no console). It is unprofessional to put in logging, *or any other feature*, simply because you think it will save you time down the track. If you honestly believe that, make the business case for it and get the customer to accept it. If they don't, then quit; the project is obviously doomed, right?

The touchstone is to flip the roles. If you were the customer, and you discovered that the developers were doing work that:

presented a risk of not meeting the schedule;
promised no immediate RTI;
had taken on this work without informing you (at least of the risk to the schedule)

wouldn't you be pissed off? Going back to the car analogy, wouldn't you be pissed off if your mechanic did major (and expensive!) work to your car without your consent? Now, going back to your usual role, why would you want to piss the customer off when a few minutes of conversation ("Gee, Rick, I think we need to do some logging in this software") could avoid the whole issue? -- RobertWatkins.

There's always a translation process from the semantics of customer needs to the syntax of implementation needs. As far as the customer is concerned, he only cares about cost and benefit. So quantify into those terms. Add in all the buffer-space you think you need. Come in a month early and under cost and you'll get a medal. So add two months on the end, and, say 50% cost. Hmmm, maybe a bit more. The customer needs security so build it in. That's how the big consultancies rape their customers and yet leave them smiling ;).

Some XP people would urge you to change your environment to a flexible one, with an informed customer you can trust.

Either way, beware of concentrating on too fine a grain of analysis detail. That can quickly lead to AnalysisParalysis, or a product that's built according to the customer's inexpert technical decisions instead of their business needs. What you need to do with the customer is agree upon

the features they need
the quality attributes they need
the time they are willing to invest into 1 & 2.

If these don't line up, you must present them with options and trade-offs. The idea isn't to cover your ass, it's to create excellent software. You are not presenting options to intimidate your customer, but to empower them.

And if you are working with a customer that makes every issue within and outside of their domain a subject for haggling, you should probably find a new contract. There's nothing wrong with a team saying something like "We build scalable highly-available systems. If you don't want that, you don't want us." This would be like a skyscraper architect turning down a contract to build a two-bedroom house.

Creating software systems is your domain, not theirs. The customer is in no position to make judgments on requirements at this level. Why would you ever ask them about this kind of stuff? Negotiate features and you implement the system how you think it should be implemented. Do you let them select class names, variable names, etc? If not, why would you let them decide other aspects that are more software engineering related?

A full-XP environment would ask the customer about any features that could be avoided and require significant work (that would affect the schedule). In a sense, these questions are like your plumber asking: "I could do a quick fix of the leak, or I could order a special part which would cost $300 more in parts and labor. The quick fix should last you a couple years, while the part would be permanent. What do you want to do?"

Many proponents of XP would probably say that if you can't trust the customer (or if you really do know the customer's needs better than the customer), then XP may not be appropriate.

It has nothing to do with trust, it has to do with knowledge and experience. If you think to make the system you need to add logging and include that in the price then the customer gets to say no, but how can you possibly let them dictate how it should be built?

In XP, the customer makes the business decisions, and the developers make the development decisions. Developers inform the customer of the estimated cost of each feature.

Features are clearly always negotiated. But what you consider a negotiable feature is way low level. If I considered logging crucial to the success of a project, which I do, then I would keep that in and negotiate a user level feature. If we couldn't agree then I live to fight another day. A customer can't negotiate out what I consider necessary for project success, much like an a soldier can't say I was just following orders.

It's about results. If the customer doesn't want it and I think it is necessary then I'll add it. If there's not enough time I'll quit. Life is too short to work on doomed projects. The customer won't accept at the end excuses like "but we told you X was really really important."

My problem with doing what you do is that I end up making business decisions. I've proven to everyone's satisfaction that I'm horrible at making business decisions. So I try hard to stick to code, and let someone else decide what I should code. It's because I'm so horrible at knowing what the customer needs that I find XP to be a good fit for me.

Logging and many other issues are in the software domain and that's my domain, not theirs. While I usually have no special insight into customer domain issues I do have insight in how to make projects work. A customer can't override that no more than a customer can tell an architect to design for inferior materials. If you were a builder you would use substandard materials because a customer told you to?

Up to the point where someone gets killed or dismembered, yes, if the customer wants junk, I give the customer junk. In the business world, quality is only one of the variables that are important. Time-to-market, among other things, sometimes trumps quality. If I do not allow the customer to turn the knob on quality, I am making business decisions that I have no right to take away from the business manager. I am also counting on the pain of bad quality to cause a rational manager to quickly turn the knob back up. If that doesn't happen, my job will probably become a lot less fun and I'll want to go find a funner job. But I never had the right to make that choice for them.

There's clearly a limit to how much detail I should be bugging the customer with. I do make decisions on the customer's behalf -- things like "how do I structure this code", things which decidedly affect quality. But I want to ask the customer about stories like logging or scalability since they're features that would take more than an hour to add. If it shows up on the schedule radar, I want the customer to decide.

It could also be that short (2-3 week) iterations cause smaller things to show up on the schedule radar. If I were on a 9 month iteration, what's a day? But in a 2 week iteration, even a few hours matter.

I can see that I made an assumption about iteration size. Oops. You and I are clearly operating in different universes, but I do not think that the way you operate is wrong -- I just don't know the environment you've adapted to. -- WayneConrad

But it's your schedule to manage. You know what can and can not work in that schedule and you should plan accordingly. If you iteration size is so small you say you can't do a particular feature then I?d change the size. We have iterations of 6 months for hardware/software projects. We have iterations of 5 minutes for some things. As you manage the schedule you know what can and can't work. I don't see the plus in picking arbitrary iteration numbers. This seems a smell to me. The work will tell you how long it should take. Listen to it. See SmallIterationsSmell.

There are two reasons to put a feature in that has not been directly requested by the customer. One is that you feel, in your considered judgement, that it will be easier to do this now than later, and that there is a good chance you will have to do it. If you can keep the cost of change low, then it will not be so much harder to do it later. The other reason is that you might forget about the feature. In this case, I'd suggest writing a note (possibly as a comment in the source). A third reason would be that it makes it easier to do feature A if you first do feature B. In this case YAGNI doesn't apply (though DTSTTCPW might).

If you really think a feature will be required, talk to the customer and find out. YAGNI is a rule for the developer, not the customer, as the customer is deciding what you will need. -- RobertWatkins

I think that this last point is the one we miss so often in discussing YAGNI: if we stumble across something that shouts out "You are gonna need this!", well, we should ask the customer about it right then and there. If they want it done, we rewrite the user story to cover the change, adjust our schedule if/as necessary, and carry on, remembering to DoTheSimplestThingThatCouldPossiblyWork and realizing that hey, we just discovered we ARE gonna need it. -- Lonna

I agree completely with the above. I have dealt with dozens (maybe hundreds!) of situations where we've identified something that we absolutely know we'll need to support and where putting it in first really, truly, does save time. In some cases we know we're going to need to support them because they form part of the overall requirements spec. The question of whether you postpone putting functionality in or go ahead is ultimately a judgement call - I would modify this concept to WhenInDoubtLeaveItOut -- GaryBarnett

See: InfrastructureInXp, OnlyForesightMatters, YagniAndLogging, ItIsntInTheSpec, HiddenStory, ClearRequirements

CategoryRequirements