Abstract your requirements up-front (Part 2)

Due to a host of reasons including politics, budget, time or project owners' lack of experience, creating an abstract Use Case Survey (or other expression of abstract requirements) as a first step may not be possible

Every requirements analyst has been in a situation where before or during a meeting a stakeholder gives you, in the example of software, a detailed user journey and even screen mock-ups of how they want the software to work. They think they've done the work for you. An abstracted view of the requirements and use case development is not required. I say this is fine and useful in situations where the following conditions are met.

1. The stakeholder owns the use case or is the authorised proxy of the owner.
2. The use case is relatively atomic.
3. The work provided is obviously correct or mostly correct. (If it's only mostly correct, you need to weight the cost/benefit of the battle to improve it.)
4. The inputs and outputs are controlled by the owner or the owner has the authority to speak for those who supply the inputs and rely on the outputs.
5. At the time you cannot identify any duplicated effort in producing the requirements.
6. Delivering the product is cost-effective.

I'd encourage you to make these points a checklist and mark against it when the situation arises.

Mostly these conditions are not met. You are presented with the “customer is always right” problem. Many experts say you need to follow the dictum to the letter. I've heard an academic say (to paraphrase), “Deliver the request, regardless of the consequences”. This doesn't work in the real world.

The needs of the project stakeholders are your primary concern. However, remember you are a professional. This stakeholder wouldn't give detailed instructions to a lawyer on submitting a statement of claim or instruct their accountant on the method of depreciation to use.

Business analysts may not have a state sanctioned professional organisation like the Bar or Institute of Chartered Accountants; however, you still have similar ethical obligations to your project stakeholders. If you receive a request which is unrealistic, inefficient, impossible or just plain stupid, you have a professional obligation to inform the stakeholders of this fact and recommend an alternative course of action (in writing if at all possible). Otherwise you are not a business analyst, you are a clerk.

In my opinion you are also under an ethical obligation to explain why the first step of system creation needs to be producing abstract requirements, use cases or any other method you prefer. Doing this in writing is important, if only to cover your own arse.

There will always be people who will ignore your advice, cut you off during an explanation, treat you like a clerk and demand the project be performed in a wrongheaded manner. If these are your clear instructions after performing your ethical duties to your best effort, then go ahead and do what's requested. When it all goes pear-shaped, don't be afraid to say “I told you so”.