An analyst is just a developer who can’t code in the chosen implementation technology.
the reason I bring this up is:
We are always told we have to use tortuous programming languages because English (or your choice of normal language) is too imprecise. Our ability to code in higher and higher language is developing slowly as people write layer upon layer to translate our higher language to computer meaningful stuff.
But if an analyst is writing specs that someone is going to code in this precise programming language, how come they can get away with using an imprecise language? How does the coder move from vague to precise? (hint: personally I go and ask the customer, but that’s just me). Don’t say CASE tool, unless you genuinely, regularly use one, in which case, which? why? strengths? weaknesses?
I’m only asking because this analyst thing came up in conversation recently, and for business systems development in higher level languages* I think this role separation is ridiculous. Sure plenty of people don’t have the full set of business and technical skills to cover both roles. IMO those people should be developed where possible to enable them to cover the full lifecycle. Not compartmentalised and forced to communicate via the 2 cans and a string that is specs written in Word.
[* by higher level languages, I’m thinking of the stuff business systems are generally built with, thats most of the stuff we discuss here, C++ I’m willing to concede may be out of reach for some business analysts, but I don’t think SQL or C# should be].
I think the analyst being a separate person from the dev is pretty unusual in Excel/VBA. Have you seen it? I’ve worked from specs before rather than users, its crap, and you always end up going to sit with the users anyway. WOT. (hint)
Do you think it would work? Does it make sense to split the roles?