Big Requirements Up Front
Big Requirements Up FrontProblem:
If you don't ask for it you won't get it.
Solution:
Write down everything you could possibly ever need into a book, and make the coders sign it. Then, at acceptance time, for every missing line item that you find you still need, make the coders work for free to complete it.
Problem:
See ChaosReport? (summary: http://net.educause.edu/ir/library/pdf/NCP08083B.pdf ).
From BigDesignUpFront:
A customer cannot "steer" the project if they do not know - on a high level - what they want this project to become.
I found this statement interesting because I found it 180 degrees opposed to my viewpoint. I feel the customer (specifically the front line users) know exactly what the project should become. It is the developers who need to know what the project should become. The question are the more effective and efficient means of communication from the users to the developers.
The problems I see with "Big Design Up Front" are that the two parties most interested in the communication (users and developers) are omitted; and the context of the user environment is lost when a large document listing precisely defined requirements is created.
I have become firmly convinced that there is no substitute for having individual developers spend a day with individual users and understanding the environment of the user's job. The developers invariably come back from the experience with drastically changed views of what they should be doing. Developers have to intuitively make hundreds of unconscious decisions while creating software; direct user experience provides a context for those decisions.
Again, the point is how best to get information and knowledge communicated from users to developers.
-- WayneMack
I feel the customer (specifically the front line users) know exactly what the project should become.
So when the military wants to develop a new airplane, they make the requirements, but past that do you think they are the best people to know exactly what the project should become?
Who would be better than the pilots in describing what the cockpit should look like? Who would be better than the maintenance crew to define common parts and repair and replacement needs? I would tend to assume that the military probably does understand military needs.
Who would be better to come up with discontinuous breakthrough rather than the status quo?
Per WilliamEdwardsDeming, new knowledge can only come from outside a system; a discontinuous breakthrough would come from someone other that those involved with the current version. Discontinuous breakthroughs, however, are nearly impossible to predict. If one has a planned schedule and budget, it would be extremely risky to depend upon a set of discontinuous breakthroughs. Be content with the status quo and continuous improvement of the status quo.
I tend to agree with this, based on several project where the requirements were coming from the customer management, and the rank and file had totally different needs. However, unless the customer agrees to have the end users available for questions, you aren't going to get incremental requirements. --PeteHardie
Yes, unfortunately in the real world, "the best source" is not usually the same as "the best available source." There are usually ways to get user contacts, however, particularly if the developers are will to go out to meet the users rather than having the users come in to meet the developers. Early in the requirements process, one can have a "Workflow Analysis" or a "Site Survey." Later, one can have a "User Conference," "User Acceptance Test," or a "Pilot Site." Many users are quite willing to describe what they do if someone shows an interest and will answer questions over the telephone or via e-mail once one has made a contact. These users can provide a great deal of guidance in interpreting a Big Requirements Up Front document and allow at least an incremental development to occur. -- WayneMack
I feel the customer (specifically the front line users) know exactly what the project should become.
I disagree with this completely. Fifty percent of the people in this world are dumber than average. As far as I can tell, all of our customers are in this group. For every project I have ever worked on in my career, my organization's services were needed for not one but two reasons:
Concur. I used various public domain and Internet sources to create a set of white papers for a client wishing to improve their engineering process. This set of papers includes an engineering glossary, software coding guidelines, software design guidelines, and others. The single most important paper in the whole mess is the one describing "Where Software Comes From."
The best way to eliminate shifting goal posts is to identify the goals in the original requirements. This can be done in a formal manner by using tools such as the QFD model (zero-sum game) and Fagan inspection or something similar. This is not an excuse for setting all the requirements in stone such that they can never change. Instead, requirements need to be organized into those which must remain unchanged, those that can be altered, and how much leeway there is in changing them.
The papers are up on my biz site for one and all to see, copy, edit, distribute, and abuse as y'all see fit.
The above comes across as user-bashing to me. I try to approach it from the point of view that everybody knows *something* more thoroughly than others, but no one person knows everything. Users know what they need better than an outside analyst does. However, the outside analyst may have more experience selecting, presenting, and weighing the various options.
For example, as a home owner, I may know that my (house) windows are cracking and need repair or replacement. However, I don't really know all the replacement options and their trade-offs. A windows expert can provide such, but the home owner still needs to participate in the process.
It's a matter of working together to match what needs to be done with what can be done within practical constraints. It's a give-and-take process. A domain-poor analyst is asking for trouble if they ignore users. I've built/designed what I thought were nice simple abstractions that simplified everything only to find out there were a lot of gotcha's that snuck up on us, requiring a fundamental rethink. Users having difficulty describing what they want is not the same as users being useless to the process. --top
[While there is clearly some user bashing going on (although I'm not sure about the wisdom of declaring that only dumb people hire me.), there is truth in the statement that users often do not know what they want. I've worked in a domain where most of the clients were quite intelligent, they simply were ignorant about technology. These clients would typically come up with some idea, often with negative impacts, and we would have to engage in a (usually) long and drawn out process of working out what they really wanted. Often this had little to do with the original idea they started with. This does not mean that the customer should be left out of the process (except when it comes time to mail the checks), but too often, what they say they want, and what they really want do not coincide.]
Usually there is a manager who decides what features to include and which are outside the scope. If rank-and-file users wonder outside of stated scope, or into suspicious territory, then perhaps consider referring it to the central manager. (Off-scope features may suggest good future business ideas if you are an outside consultant.) I generally like to collect all suggestions and/or suggested features, and then have the top-level customer rank them. This will at least help focus the project. Depending on the formality of the situation, you may even want them to sign off on the ranking. If the ranking keeps mutating often, then you have documentation to that fact. Some changes are inevitable. Excess changing is a problem. --top
[We developed semi-custom software for very small companies (6-8 people was common). The people who came up with the original ideas often were the only management/ownership they had. They rarely had more than one active request at any given time, so there never was an issue of ranking. Often we had to make the suggestions because the ones the clients supplied didn't actually meet their needs.]
Through this instantaneous feedback mechanism, all of which involves pain, the unschooled become schooled in the ways of the world. One such pain is economic pain, and the realization that, "Hey, you know, this is really costing me money." Thus, the value of the PlanningGame is to give pain to the customer, when the customer does something stupid. The rapid feedback of critical information, such as estimates of time to completion, and relative priorities, helps hone the client's concept of what he really wants. It forces the client to become more aware of what is involved with the software's construction, particularly since the client is paying the coders each iteration.
Hence, claiming that "customers are dumb" applies only to those development processes which do not involve the customer in the development cycle. As soon as the customer starts to see what is involved in the development of his requested features, he very quickly becomes much more fiscally (and thus, feature) conservative.
Never under-estimate the power of pain. --Samuel A. Falvo II
[I certainly agree that leaving the customer out completely is so rarely a good idea we can just say "don't do it." But if we had taken a "you asked for X, it costs Y, will you pay?" approach we would have "pained" both them and ourselves out of existence. I must stress that the customers were not dumb, but ignorant. If I had attempted to do their job, I would have floundered around just as badly as they did attempting to suggest improvements to the technology we provided.]
You seem to be suggesting that the hard decisions be delayed as long as possible for "harmony". I don't know the political situation you faced, but from a "technical success" standpoint, making the hard choices up front is the better bet in my experience. The mess in Iraq is partly due to local governments postponing difficult decisions because they can ride the back of the USA for now (both as a police force and as a scapegoat). --top
[No. That would have lead to us doing the project they originally suggested and let them find out for themselves what the problems with it were. It's much harder to tell them, "This idea doesn't work because of such and such.", extract why they felt they wanted that in the first place, and find something that actually works then to just say "yes, sir" and let them deal with the consequences.]
People want a sense of control over their destiny even if its not always the best technical choice. One trick is to let them have their way with relatively harmless or low-impact issues to satisfy that sense. That may buy you enough influence wiggle-room to affect the bigger issues. If you feel you need control over most or all aspects in order for the project to be successful, rather than pushing for that at all costs, perhaps its time to renegotiate expectations. If "X will only work under conditions A, B, and C", but only A and B are possible/likely, then its time to rethink the price, time-line, etc. Always build in "room for crap" in estimates.
I'd like to inject a term here that XPers and other so-called "agile" types roundly loath: architecture.
First of all, let's define that this is, shall we?
Architecture is the base, irreducible, and immutable set of rules defining how a system works.
and you are smart enough to know them all when you start. props! [Try not to be such a smug turd, eh? Read some more before posting.]
Architecture rules are base because they define a system at its core functionality. You can have me build you a toaster or a coffee maker, but it has to be either one or the other -- not both. You have chosen a toaster. Are you absolutely sure? You better be.
They are irreducible rules because you have defined the toaster I am making in terms of what it absolutely must do to be a successful toaster. It has to cook one or more slices of toast simultaneously, both sides simultaneously, and evenly on both sides. If any of these rules are not met then it isn't a successful toaster. So, if it can't toast one slice by itself or if it cooks unevenly then it is a craprod.
They are immutable because once you have set these rules into place you can't change any of them without changing the target into a different product. You told me to build you a toaster. I've started building a toaster. I can't make it a coffee maker now. If you want a coffee maker I need to start over from a clean white sheet of A size.
The (un)common wisdom about architecture is that these are the rules you will have to live with for the lifetime of the system, so they need to be chosen with care.
Now, note that the architecture just says that the toaster will be capable of toasting one or more slices of bread. The architecture doesn't call out limits on how many slices the toaster can handle. This is the kind of detail that the client hems and haws over as development continues. Two slices or four slices? Two slices or four? Two or four? Bicker, bicker, bicker. Nit, nit, nit. Pick, pick, pick.
All the while you are sitting back, comfortable in the knowledge that any choice they make will not affect your base, irreducible, and immutable rules that you have set in stone.
Go ahead and let the client thrash out the details of the product all they want. Your architecture remains safe.
And if I do want a toaster and coffee machine combo? With this approach, a printer is not a scanner, a scanner is not a printer, and neither are fax machines or photocopiers, so you can never have the hybrids that have become so successful in the SoHo? market. -- zfx
XP works with all practices supporting each other. See RefactorMercilessly. And note that printer, scanners, and fax machines are not DRY - they fail "DontRepeatYourself". Refactor them!
Hmph. Please, folks, let's not drown the basic concept in useless trivia. The idea of setting an architecture in place is so that there are ground rules for defining what the product is. In the case of a printer/fax/copier, the product is a combination of an imager and an image capture device. Note that these functions are independent and need to be defined separately, even though their functionality has been combined into a single box.
Even with a wideband product like a combo printer/fax/copier, you still need to set limits on the architecture so that the client doesn't get crazy with features. So, the combo box can print, send faxes, and copy, but it can't do XY plotting. That's because it isn't a plotter. There are no provisions in the architecture for interpreting XY plotting commands, nor math capability for drawing vectors, nor any of the jillions of other things a plotter needs to do. Why? Because the architecture forbids it.
This is the reason for establishing an architecture. You have saved yourself and your client from needless grief in trying to shoehorn a plotter into a fax machine because you defined the product as a fax/printer/yada yada yada before you ever started. By setting these limits up front you then avoid shifting goal posts later on.
Now is it clear?
In a contract relationship, you should use BigRequirementsUpFront AntiPattern for everything you've asked for will turn up to be a good leverage in contract negotiation once you need it. In a more trustworthy environment, if you have good BusinessAnalysts, let's say you won't need to express everything.
Right, see, that's the point. If you have a clear grasp on the difference between what has to be there and what is more likely to change as discovery progresses then you don't have to have moving goal posts. You can specify the hard requirements up front and only resolve the wishy-washy requirements as they need to be solidified. Establishing an architecture isn't an anti-pattern; it is a necessary component of establishing a baseline of operation for the product.
See: AgilityTest (hint: you are the customer), TheAlmightyThud, BrufPredictsFailure, RequirementsGathering
EditText of this page
(last edited August 7, 2014)
or FindPage with title or text search