Getting Accurate Specifications for Software? 147
spiffcow asks: "I design internal software for users that are largely computer-illiterate, and obtaining accurate specs for these programs has become a huge challenge. In the most recent instance, I asked for detailed specs on what an accounting program should do (i.e. accounting rules, calculation methods, and so forth), and received a Word document mock-up of an input screen, complete with useless stickers. This seems to be the norm around here. When I asked my boss (the head Sales manager) for specs, he responded saying that it was my responsibility to determine what was needed. How do I convey to the users that, in order to develop the software they want, I need detailed, accurate specs?"
he's right (Score:5, Insightful)
In my experience, the best way to get these is *not* asking people what they want or need (because they are usually not capable of putting that into words), but to observe how they do things right now, and determine which features they need (or which features would ease their workload) that way.
Systems Engineering (Score:5, Insightful)
Its called Systems Engineering and its a whole other profession. For a large, complex system like the ATC systems I work on syseng could easily account for 30% of your staff. Remember that getting the design right in the first place it the hardest part.
The only way I can think of the convince the "sales" people who apparently run your site is to create a really big stuff up and document it in advance to make them culpable. The problem is that they will probably just get rid of you when they respond.
You could try a kind of passive-agressive approach. Keep misunderstanding them. A bit like a monty python sketch. Don't go so far that they really get angry. Judge it so they come to their senses and start to write down exactly what they want.
Isn't there an old adage: The user got exactly what they asked for but not what they want.
I think you are screwed. Sorry. I have been in that situation before.
Re:he's right (Score:5, Insightful)
And count your lucky stars that your company is incapable of writing proper specs - if they were, they would have outsourced your job to India or Brazil a long time ago.
Daniel
Forget it (Score:4, Insightful)
* I've received a specification for a new project that accurately tells me what the program should do, and doesn't assume prior knowledge of the entire business;
* I've read the original specification for an existing project that matches the way it's actually been implemented;
* Management have believed me when I've informed them that either of these conditions are occurring and are preventing me from doing my job in a timely, effective fashion;
The lesson to be learned here is that there is no tried-and-true methodology that works across the board in IT, and thus there is no established framework for non IT people devising specifications for IT people. The problem is always going to be that each person in a business is so far down their own specializing holes that they forget how much people in other departments know or don't know. I liken it to teaching someone how to drive a car after you've driven for many years - after a while these things become ingrained in you, to the point you forget that your pupil doesn't know to hit the clutch before changing gears. CRUNCH!
And parent comment is right, too. MOD PARENT UP! (Score:5, Insightful)
The correct approach is a very loving one. You try to discover what would make their work easiest, and make the software do everything software can do. Most jobs require that a person turn himself or herself partly into a robot. That's wrong. If a machine can do it, a machine should do it.
Programmers typically say to this, "I just want to be a programmer, not a sociologist." The real world requires every one of us to be a sociologist, or be out of touch with what's happening.
--
Is U.S. government violence a good in the world, or does violence just cause more violence?
Re:Systems Engineering (Score:2, Insightful)
Re:an unrealistic ideal (Score:5, Insightful)
I am by no mean a professional developer, however I develop a data analysis application that my collegues use in my lab (I hope to release it on Sourceforge soon). I do it not only for *my* data analysis, but also for other kinds of analyses, so I discuss "specs" from my collegues and implement them.
What I found is that when they are in front of the app, after a bit of usage they think "could you add feature X?" "how can I do Y?" and so on. I implement X and Y, and only then they ask "oh, you did Y? So why not Z?" etc. So the spec becomes dynamic, in the sense that only when they see a milestone accomplished new possibilities come to their (and my) mind. It's a climbing process. I don't know if it's the same also for pro developers.
Face it. You'll never get decent requirements (Score:3, Insightful)
IMHO the way to deal with it is to accept it and make it part of your process. Since you're talking about in-house development and small to medium sized projects I'll recommend an agile, itterative method. Make a small incremantal release every other week and get your requirements from the user feed-back.
At the end of the day, users are unable to express what they what they want. They only knows that they have a problem situation and that they want a piece of software that makes all their problems go away.
Re:Systems Engineering (Score:3, Insightful)
No, it's not necessarily your fault; however, programmers should become familiar with at least one area in which they intend to work.
Re:Something I struggle with as well (Score:2, Insightful)
Re:And parent comment is right, too. MOD PARENT UP (Score:5, Insightful)
One example I can bring up from my past is designing industrial test equipment used for calibrating mechanical metering devices. I spent a month where I worked side by side with the people who would be using the equipment, 9 months developing prototypes (including all the hardware and software) and ended up with a product that cuts a 15 minute procedure down to 2. Again, I had to work with the users to see how they used the prototypes, and refine the hardware / software to real-life conditions. I even had to consult with a physics professor at the local university to help with some of the complex flow equations (physics is not my specialty, but I know enough to be dangerous...
Could I have ever expected my users to develop detailed specs? No way - it's not one of their core competencies.
Re:he's right (Score:2, Insightful)
Re:he's right (Score:3, Insightful)
Damn straight. All of us who get specs like these are in a special place. We have to bridge both the Analyst and Programmer jobs. If you are lucky the person who writes your specs won't go on a power trip and scream at you if you don't write exactly what they put in their word document. If you are lucky you have been given the chance to find the needs, fill the needs, and write great software.
You might not be that lucky. But, the harder you work the luckier you get.
Re:he's right (Score:3, Insightful)
Next stop, the unemployment office (Score:1, Insightful)
Ignore this poster. He's probably "between jobs" right now.
If you really want detailed specs from your users then create some forms for them to fill out with specific questions about the aspects you are unsure they need included (like calculations to be performed at certain steps). Better yet, if you give them a proposed workflow diagram with adequate explanation of each step and let them crtitque it you'll end up with a much better idea of what they're asking for. You'll get the added benefit of getting the user to start thinking about how things work outside of their own little specialty. You may learn something in the bargain as well.
I would have to agree with a previous poster that anyone who expects to only have to do coding after someone else has done the spec gathering should not be surprised when they get notice that their job has been moved to Mumbai.
Re:he's right (Score:5, Insightful)
but being informed on actuarial terms is not my business
Then you'd better have some damn good and damn accommodating domain experts.
An analyst's job is to understand the business rules and figure out how they can be sanely implemented in an IT solution. (Or, more importantly, when they can't.) And unfortunately, that sometimes means learning the jargon.
That's why my general (25-year) experience says that the best analysts are, first and formemost, generalists: capable of quickly absorbing the rudiments of any computable field of human endeavor. If you're doing the systems engineering for an accountancy, you'd better learn the fundamentals of accounting. Automating medical records? Learn medical recordkeeping. Weather forecasting? Heh. I could pass for a forecaster now, in casual conversation, because I've worked on weather data-gathering and forecasting systems so long.
Obviously, you are one of those quick-study generalists I spoke of, because of the breadth of (successful, I presume) systems you've helped implement.
That just leaves the problem of customers who don't actually know what they do, at least in enough clarity and specificity to implement as software. That's just a matter of patience and iteration. Prototyping can be helpful here, if you have time. Otherwise, I guess you just have to sigh and assume your first cut will be wrong.
Re:Force them to say What, not How (Score:3, Insightful)
WHen you start to get an idea, produce a document and then, in another meeting, go through it with them.
This job is more about dealing with people, extracting little bits of information from them, getting them to think about the problem, more than programming.