What <IS> the role of a Business Analyst
Business analysis, traditionally, has included among other things the following broad objectives -
1. Ensure client requirements are all captured
2. Ensure the developer understands it
3. Ensure the code meets the aforementioned requirements
There are different schools of thought on how these are performed. In general though, traditionally, analysis demanded these objectives be met through the following activities:
Objective: 1. Ensure client requirements are all captured
Activities:
a. Elicit requirements through Questionnaire, Workshops
b. Detailed documents or Use cases/diagrams to capture requirements
c. Traceability to ensure requirements don't get dropped
Objective 2. Ensure the developer understands it
Activities:
a. Capture system/data flows
b. Capture requirements as use cases/test cases
Objective: 3. Ensure the code meets the aforementioned requirementsActivities:
a. Perform and sign-off functional tests
What <SHOULD BE> the role of a Business Analyst
As the role evolved, especially in the Agile world (coincidentally not consequently, I think) , business analysis has also acquired the following objectives/activities, and dropped some of the above as a result:
Objective 4. Ensure the requirements are right
Activities:
a. User stories: Get close to the end-users, and think from their perspective and their goals - look at user value, not business value - hence ensure, the real requirements are captured -> This has received a whole new infusion of ideas from Human Computer Interaction/Cognitive and behavioural science -> this also meant use cases, which were still partly systemic rather than completely user-centric, became user stories. And then, user stories became better defined when BAs realized "users" should be real end-users, not the system. Thus, non-functional requirements became cross-functional requirement or just plain requirements worded differently to ensure the delivery team doesn't loose focus on how the user experiences it
b. Task Analysis/Story maps: We started looking at requirements as necessary to perform a user objective. This ensured we optimize software for the best user experience, and not just add better UI or throw better hardware to take care of it. More importantly it e
c. Get user feedback: Plan to release often, showcase and get continuous feedback
Objective 5. Maximize ROI
Activities
a. Identify MMF (Minimum marketable features) - Ensure requirements are not just prioritized, but packaged in such a way that value is realized at the earliest. And minimum time is spent on what is less valuable
b. Split stories/Release planning - create independent, negotiable, valuable, estimable, small and testable chunks of requirements that will flow through the development pipeline smoothly, and can beget immediate feedback
RSS Feed