Fallacy Of Requirements
Fallacy Of Requirements"All the problems of the computer industry," say BigDesignUpFront advocates, "would be solved if only we invested enough time and money up front to discover and thoroughly document the true requirements of the business."
"Bunk!" says I, "there is no such thing as 'requirements.'"
"I'm going to buy a new car," I say, "and I want a sun roof on it." "Aha!" says the analyst, "the sun roof is a requirement." "OK," says I. "$1000 for the sun roof," says the car salesman, "and it will extend 3/4" down from the roof." "Ouch!" says I, for both the money and hitting my head on the #*$&@*$ sun roof, "suddenly I don't think I want a sun roof any more!!!" (See, it's not really a "requirement," in the English sense of the word.)
You have to realize that the value of something to the business community depends on both its payoff, in terms of increased revenue or reduced costs, and its cost. Any "business requirement" that is gathered independently of cost considerations is simply a work of fiction.
The idea that we can "go gather the requirements from the users" and then estimate the dollar and time cost of the project for a "go/no-go" decision by the customer is just misguided. And yet it's also standard accepted industry practice.
[Not always so. I am working on a project that requires a link of some kind (IR or BlueTooth, most likely) between a handheld and a local host system. This has to be there, and any handheld must be updated any time it gets near the "docking station" (near a certain door). Without this facility the entire rest of the system is kaka. I haven't priced the docking link yet, but, whatever the cost, we need to meet it to sell the concept. Everything else is negotiable.]
The fallacy resides more in the verb "to gather" than it does in the verb "to require". Gathering implies the act of collecting things which are readily available. Requirements for interesting systems rarely are. That's what makes software development such an interesting species of problem solving. Problem definition is where the action is. The task is to tease the most interesting and solvable problems out of the customer's mess. You can cavil and say this is an impossible task, citing changes over time, communication difficulties, and whatever else you know detracts from doing the job perfectly. But if you stand back and look at a system that's been built, it's fairly easy to see that there are requirements there, and by extension that No requirements = No system". ~~ WaldenMathews
Also, the Business Requirements as described by a system's client may only be part of the larger picture of where the corporation is headed. A SystemAnalyst or SoftwareArchitect might also want to consider the company's StrategicPlan or the sociology surrounding the design of the new system. It is not so much that a RequirementsDocument is false (or contains fallacy) as that software development is part of the larger sociological operations of a company. We narrow the scope of our vision to produce requirements because the narrowing allows us to more easily analyze requirements, however we might pay for this narrower vision in a poor lifecycle for the product that we develop. Sometimes it helps to take TheSeventyThousandFootView.
"Business Requirements" change. And they change for a number of reasons:
Business Environment Changes:
Even if you managed to gather the "perfect set of requirements," and also estimate the work effort and resource availability without error, you can be sure that 3 months into your 9 month project, the business environment will change. There might be a terrorist attack, or the start or end of a war. Interest rates might go up or down. A competitor might raise or lower their prices, or release a new product, or they might even make an announcement that causes some people to change their minds about something. Or, heaven forbid, someone in your company might come up with a better idea on how to do the work.
Change happens. And much of the change has nothing to do with our ability (or lack thereof) to know everything in advance. We simply don't control everything. And the people we work for don't control everything.
So we'll have to learn to deal with change as it occurs.
[This rant inspired by the CooperVsBeck article, and additional readings on AlanCooper's InteractionDesign ideas. Actually, I think InteractionDesign shows a lot of promise, but that AlanCooper's world view does not. -- JeffGrigg]
It is truly a rant.
< Why, thank you. ;->
Because you falsely equate requirements with BigDesignupFront?. Last time I checked dictionary.com, "requirements" and "design" were not synonymous in any way :)
''Agreed. "BigDesignUpFront advocates" was intended to basically cover traditional WaterFall approaches - where one "gathers all the requirements," and then estimates the cost, and then gets the project approved, and then builds and delivers the entire system. "Traditional WaterFall" would probably be a more appropriate term.''
What you describe is partly true (not every aspect of the business changes every other semester) and it is the one of the many challenges (not fallacies) of requirements engineering. But the fallacy of XP approach is letting the software engineering team abdicate from the challenge of requirements and shift the burden and the responsibility on the customer.
And very often the customer is not properly equipped to meet the challenge. But then the XP team can wash their hands, and say "we did everything that the customer tolds us to do", it's the responsibility of the customer that the information system doesn't deliver what is needed. --CostinCozianu
Remember that the Customer is part of the XP team. Nobody can "wash their hands" of the responsibility for a project failure. There can be no "shifting" of the burden if it's a shared burden. -- LaurentBossavit
If the customer (note the emphasis) cannot tell the developers what is wanted, who can? I know next to nothing about billing systems, and if the customer who wants me to build one can't tell me how it works, then why even start development? --PeteHardie
Well, if the customer cannot maybe a team of software engineers (playing the role of "analysts") together with a team of customers will do the trick. The main idea is that if requirements engineering was as easy as stayiong relaxed and implementing one user story at a time, than it would have all been so easy, but it isn't. Maybe not XP in itself, but, certainly the spirit of this page, are in favor of letting the user do a real analysis of what is needed. Software Engineers can just stay relaxed and implement whatever the user tells next, they'll be doing just the programming job.
Ah, but maybe it is that easy, if the customer and the developers keep talking together, proposing ideas, asking each other questions, and working as a team. XP does not say that the customer writes the requirements, the developers estimate the cost, and then you're done. At the ReleasePlanning meeting, the customer explains the requirements to the developers, and the developers ask questions to clarify things. And it's perfectly OK for the developers to ask the customer about requirements they think have been overlooked. "How many simultaneous users do you want to be able to support?" or "What happens if the power goes out?" or "What if the user makes a mistake when they enter this information?" The developers can suggest ideas to the customer. "Would you like it better if the user could select from a list of choices instead of typing in a code number?"
Well, the PlanningGame is centered around UserStory idea. The argument goes that taking requirements from one user story to another user story, it's not the same. And user stories is not all there is to software requirements. And the really knowledgeable users are too precious for the real enterprise to be delegated to stay with a bunch of developer for the duration of development. That's why systems analysts were invented, to extract essential knowledge from several places, to synthesize, tranform and to transfer that knowledge in a usable form to the customer and to the development team.
Then for the developers to suggest real ideas to the customer (like "we might use linear optimization" to calculate these parameters, instead of "we'll let the user choose from a combobox"), it is really necessary that developers have the whole big picture, and they have aquired the necessary expertised in the domain being addressed. Let's take an example: when I developped an accounting application, I learnt accounting before writing a single line of code, or even asking the user what they wanted. Then, when gathering requirements I was able to challenge the users with regards to the validity of their business rules, explaion to them how they can really do things differently with a computer. That's the essential part: things ought to be done differently with a computerized information system. Even if you replace an older system, the new system has to come up with innovations in the way to do things. For these innovations to come about you absolutely need UpfrontAnalysis?, and you need system analysts, you need a MichaelJackson not a DonaldKnuth doing this job.
If I was doing XP, maybe in the nth iteration it would have hit me: we could have done things differently from the very beginning and the system would be a lot more useful to you. Then what ? The responsibility wasn't mine because I'd have done exactly what the customer told me to do up to the n-th user story. I can take responsibility only as good will gesture, and it would be kind of pro forma. That's why I contend that the burden of getting the requirements right is entirely shifted to the customer representative.
The problem is that the user might not have a precise knowledge, or might have trouble to communicate it in the form of user stories. He/she might not articulate a vision of what the overall system should look like and what it should do, because users are not particularly aware of what technology can do for them. A great many deal of users are happy to look at the computer as a typewriter/paper saver. And there's lots and lots of other problems in this area, that might lead to project disaster. What happens with XP from my point of view, is that all these problems are to be avoided by the user, after all the programmers can't be responsible if they implemented exactly what the user told them.
This problems have been solved traditionally by "information analysts/business analysts" who's role is to join the user perspective and the information system perspective, understand excatly the user's needs and articulate a proposal. Jeff called that BigDesignUpFront even if has absolutely nothing to do with design, it is even not WaterFall approach even if might fit within WaterFall.So we have a entire engineering discipline called requirements engineering that addresses this process, and it's not worth reinventing many wheels on this page.
So it seems to me that this particular area is kind of shaky within XP, maybe if it wasn't called XP but ExtremeSoftwareEngineering? ... because there's considerably more to building information systems than just programming.
So the customer needs to include systems analysts in the mix. If they don't, I fail to see how that forces the development team to shoulder the responsibility of deciding what the customer should be asking for, as opposed to what the customer is asking for.
See also: XpDoesntCoverThat maybe it should
I think AlanCooper's point is that yes, the customer can tell you lots of things about what they want; they can tell you all kinds of things about their current way of doing things. But, if I understand AlanCooper properly, he says that much of what the customer tells you will be "wrong," in that they shouldn't be doing business that way: There are better ways of doing things. (AlanCooper's approach strikes me as being very much like BusinessProcessReengineering. ...which I think is a good thing, but not always feasible.) -- JeffGrigg
I have never been a full practitioner of XP (XpPositionsWanted?.....), but I believe the answer to this is that XP has three parties on the negotiating table, not just two - customer, technology, and business. Business is responsible for preventing technology from abdicating its responsibilities (and for assuming them itself, to the extent possible). -- DanielKnapp
Notice that defining requirements is *not* necessarily the responsibility of the customer but of the Customer (which is one of the ExtremeRoles). The challenge is, of course, to find the adequate person(s) to fill this role...
Quoting Bryan Dollery from the Yahoo Extreme Programming group (http://groups.yahoo.com/group/extremeprogramming/message/41797):
Perhaps the first thing we need is a definition for a "Requirement." I often see two conflicting uses:
JerryWeinberg's Exploring Requirements: Quality before Design covers these issues quite thoroughly, especially the one of "need" versus "cost". It is recommended reading.
If you reread the top of this page, I believe the argument applies to the second type of requirement, but not the first. Unless we decide what type or types of requirements we are discussing on this page, we cannot take the analysis further than what is in the top 10 lines.
Characterizing the problem
If you can distinguish between correct and incorrect code, then there are requirements. The issue is not whether there are requirements, but how to discover and agree on requirements.
The phased approach says to research and document ClearRequirements in a special phase early in the project. Once the requirements are "done", then you code. Coding without a bar set, defining what counts as correct vs. incorrect code, would seem to be the height of irrationality.
The agile approach says to discover the requirements piecemeal, as you code. The process of coding and using the software will lead both customers and programmers to invent and flesh out requirements much better, in many cases, than trying to figure out the requirements without a concrete feedback loop.
If we characterize the problem in this way, then perhaps we can focus more clearly on useful action and avoid semantic issues and false dichotomies like, "Aha! It's not a requirement if you'd give it up because it costs too much! The dictionary says so!" In software, a requirement is just whatever you are using, for the moment, as a criterion of correct vs. incorrect code. Whatever propositions customers and developers agree to treat as requirements can freely vary during the project. There's not even anything intrinsically wrong with writing first code and later on deciding what to call correct or incorrect. Contractual requirements are a different topic.
http://www.agilealliance.com/articles/articles/Kovitz.pdf
EditText of this page
(last edited December 15, 2005)
or FindPage with title or text search