Slashdot Mirror
Getting Accurate Specifications for Software?
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?"
Your boss is correct: it is your job to get accurate specs.
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.
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.
http://michaelsmith.id.au
* 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!
Work smarter, not harder.
I agree with the parent comment. It's too big an intellectual challenge for most people to think about the details of software design. Users just want their software to work.
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?
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.
-- Patent no.123456: A way to personalize
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.
TCAP-Abort
I've found that you can iterate on a design document all you want, and create nothing but churn. I have found that it's far better to iterate with an actual prototype or mock-ups, because users don't think the same way looking at a sheet of paper as they do looking at an application. I've started using Ruby on Rails or PHP to do quick and dirty prototypes for our users (most of our internal intranet sites are Servlet/JSP based, but it's so painful we only want to do that piece once). Lately, my management sees the functioning prototype and says "hey, we're done" and has me polish it up and then move on to another project. The prototypes end up becoming the final app. I'm not sure how I feel about this; the "final" product (in my mind) never gets done, butthe users are happy... which I guess at the end of the day is the most important thing.
"To hope's end I rode and to heart's breaking: Now for wrath, now for ruin and a red nightfall!"
Domain knowledge is what makes you really valuable to a company. As suggested above, go and work with the users to figure it out, and then implement it. If anyone wonders what is taking you so long, be prepared by documenting exactly how you spent your time learning the procedures / formulas. That kind of documentation is useful come review / raise / bonus time. Seriously, it can take years to gain high levels of domain knowledge.
:-)
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.
How are you still employed? The users aren't your enemy, they're your customer. How would like it if you went to a tax accountant and he treated you this way just because you hadn't done all of the hard work before you brought your information to him?
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.
Do you like meetings, because the only way to do this propertly is lots of meetings. Talk to them, talk to them some more, go away and think about it, and talk to them again. Talk about how you think it should go. Then get corrections. Ask lots of questions.
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.