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
 
    View my profile on LinkedIn
    RamRam

    Intro

    The author of this blog goes by many names in different places. But, the one that seems to have  stuck for now is... RamRam


    Archives

    August 2013
    November 2012
    April 2012
    December 2011
    September 2011
    December 2010


    Categories

    All
    Agile
    Business Analysis
    Cognitive Science
    Economics
    Life
    Product Management
    Psychology
    Social Justice
    Software Consulting
    Systems Thinking