Businness Analysts and design

Sometime since I last posted, so one from the past:

This was originally posted about ten weeks ago on the Requirements Networking Group (RQNG 080320 "Does a BA do design?", http://www.requirementsnetwork.com/node/1117#comment-2132) in response to a post claiming that there is no distinction between requirements and design. I have mildy edited for this blog.

Of course there is a meaningful distinction between requirements and design! That doesn't mean that the distinction isn't sometimes more of a grey blur than a clear line, but it is nonetheless meaningful.

Requirements are all about definition, either of the problem to be solved or the solution. Design is all about, well, design - making decisions about what a thing should be as opposed to what it does. I can define a solution, that is, defining its essential external characteristics, without designing it, which is primarily about internal characteristics.

Do I think that BAs should be involved in design? It depends, at the least they should be involved in reviews to gain confidence that the design will provide the functions, and thus enable the capabilities, that are needed. Does that mean they DO design? No, it does not. If a BA does design, does that mean that requirements and design are not meaningfully distinguished? Of course not.

I suspect that a lot of such thinking comes from the common failure to distinguish between problem and solution definition. Countless times, I see or hear of BAs presenting functional specifications to users without understanding that the functional specification defines the solution, and hence without the actual problem being clearly defined anywhere.

On a related note, should BAs take into account design in the analysis? Of course they should! I often use the example of seats in a car. From a pure problem perspective, you should not include seats in the stakeholder requirements as they are a solution. But no other solution fits the constraints of the problem, so use them.