Writing specs for complex situations.

[cloureir]

Years ago when I was working as a systems analyst at the computer centre of XYZ University, I had to gather information from different schools and departments to design a decision support system. It was, to be honest, a very difficult assignment. People spoke different “languages” and have different opinions about what the software should have. I could hardly understand some of them. Imagine having to talk to mathematicians, linguists, economists, clerical staff, etc, etc. I ended with contradictory definitions of the decision support system. Whenever I said, but Mr. X or Dr. Y said a different thing, they said the others were wrong. It was like having many different specs for the same system! At the end we abandoned the project for other rea$on$.

Now I wonder what I would do if I face a similar situation. For example, if I had to develop business applications for multi-organisations, each organisation with a different culture and opinions about the same software.
Have you ever written specs for something like that? How did you deal with stubborn, close minded users… who also change requirements whenever they want!

[Kheun]

Not sure if it helps. You can some of these representative into a room to brainstorm a list of features set. With the features set, you can send out an email to everyone for polling their opinion by giving a score for each feature. The reason for polling is to understand the importance of the features for everyone. From the survey, the feature with the overall highest score is most needed and vice versa. With this result, you can then proritize which features to be implemented.

[Deniz]

I think you should look at the minimum requirements for a system and design a prototype.

Once people see a working prototype their attitudes often change and you'll find everyone becomes a genius all of a sudden and you'll have more ideas (good ideas) than you can put in. And fo the bad ideas or just plain stupid ideas, take the time out to explain why you think this is. You might find that you're the one missing a point. (or the guy is just plain dumb). Either way, once the design is done do not take any more specs until the first version is out. Explain to the one paying you why this has to be so when people go to him to complain that you (the analyst) is a stubborn and lazy good-for-nothing-bum the boss will know that these are taken note of and will be available for version 2!

Assertiveness when dealing with people is a must. If you're acting like a 40 year old mumbling computer nerd who cant string two words together to form a sentence, you will be pushed around (and probably shortchanged in your paycheck).

Just my $0.02 worth.

[Kheun]

Good point, Deniz. By dividing the features into phases and implementing them into an executable program in each phase, it is much easier to demo the executable and obtain valuable feedbacks early in the project.

[Deniz]

That method, I can tell you, has saved me from going completely insane a couple of times...

[cloureir]

good point
there is a drawback though. users/clients might think that you are almost done. when they see the screens, menus, etc. they will expect you to finish soon. And then you have another problem, to convince them that the prototype doesn't work that it's only a mock.

[Kheun]

good point
there is a drawback though. users/clients might think that you are almost done. when they see the screens, menus, etc. they will expect you to finish soon. And then you have another problem, to convince them that the prototype doesn't work that it's only a mock.

That's why you need to use visual clue to indicate to them that it is not ready. For example, you can gray out or disable a button to indicate that the functionalities associated with the button is not completed yet. It also helps to explain what to expect in the future.