Chris:
We basically agree. But there are probably 5 people on the planet who can intelligently position the major RA techniques relative to one another.
Per your last sentence: Analysts really dislike doing analysis. Analysis: Patitioning an entity into its components and then examining how the components interrelate. The 'P' word (partitioning) in systems is the killer.
Tony
Hi Chris,
I'm being pedantic here but "Functional descriptions of how the systems UIs should behave."
suggests you do this before defining the logical functions i.e. you do your solution before properly defining the problem. Now I'm sure as an experienced BA you don't do this but for others visiting the forums I think this is a very important point to get across. Mostly because its THE major recurring problem I see with business analysts.
Kimbo
Tim, pick that technique that your audience is most comfortable with. You are not doing post-requirement-elicitation for your own consumption. You are doing it to explain certain things to certain people. You may create a beautiful process flow diagarm but your audience may not have a clue as to what it is. You may create a UML use case diagram, but someone might not know what that means and may instead have been looking for a workflow diagram. So ask the end-users what they'd like to see and then create that.
In addition, make the stakeholder's elicitation and communication preferences part of you stakeholder analysis.
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: