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?"

Comments

he's right

[Anonymous Coward]

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.

Re:he's right

[KDan]

Absolutely. Get your ass off your chair, walk over to the users, and talk to them about what they need. Then write yourself a detailed spec if you feel you need it. Then turn that spec into some paper-based mockups and walk the users through it. Then make any corrections needed. Then write the software.

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

Re:he's right

[idontgno]

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.

Systems Engineering

[MichaelSmith]

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.

Forget it

[Moggyboy]

After working in the industry as a consultant for nearly 10 years, I can honestly say that none of the following has ever occurred:
* 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!

[Futurepower(R)]

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?

Re:an unrealistic ideal

[cyclop]

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.

Re:And parent comment is right, too. MOD PARENT UP

[walt-sjc]

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.