Simple^4 Xiaoming Wang

Recently, there was a thread in e-mail talking about why BA (Business Analyst) is needed in a software development project. The reason is that some of our client have concern why they need pay such a relative high rate for a BA. The argument is what the value of BA is? There are three crucial expertise that BA has.

• Requirement Management
• User Interface Design
• Domain Knowledge and Experience

I am not going to talk about why domain experts and UI designers are important in a project. BA also take the responsibility of managing requirement in an agile project. In some projects, we called the role Requirement Manager.

So how does BA manage requirement? We group the activities into these four processes.:

• Requirement Gathering
• Requirement Analyze
• Requirement documented
• Project planning

I will talk them through with some examples.

Requirement Gathering

There are so many ways and tactics to gather requirement. Such as end user interview, expert interview, questionnaire, observation, experiment, brainstorming, and etc. In many case, a project choose a unefficient process to gather requirement although they might use many good methods and tools. A typical diagram of project requirement hierarchy is

As we can see, the cost of communication is big, also the bad impact of this hierarchy is that lots of requirement were lost or misunderstood by the team during the transportation. It is even worse, the team might understand the requirement in different way, finally what we developed might not be what end user really wanted. The team member could get different information and decision from PM, BAs or QAs. It is a nightmare for a team in a tough schedule. What we can do in order to solve the problem is to bring the three layers in the middle into one. And organize them as one requirement management team.

With this way, business analyst, domain experts and project manager can work together to help the customers and end users understand their problems well with their expertise.

Requirement analyze

There are some basic tricks for requirement analysis. Such as 5W1H (What, Who, Where, When, Why, How). My colleague Chris Stevenson taught me another trick (5Why, alway ask 5 why when user want a function) which is quite useful to dig out the real value of the story and find out the root cause of the problem. Let’s see a real case of how to figure out a right design to solve a problem.

Once, I got a requirement from a BA, said that customer wanted to show build number, type and deployment date on the main window of the application (Client-Server application). It will be a simple implementation but I still push back because I don’t see the business value of the “requirement”. Then the BA provide a couple of scenarios in order to help us to understand the problem better.

Scenario: A trader came to office and found out that the application did not work. He called the support people who asked him a couple of questions. The trader provided the build number, then the support people still could not figure out the problem. In the end, the trader complaint that the application did not work. Actually the root cause was that the user was using a wrong version of application. The support complaint that he could not get enough information from the user to help him solve out the problem.

We can tell one option of solving the problem is to have rich information on client side to help support and end user communicate. However, the solution does not solve the ultimate problem. Indeed, what the support people and user need to know was that “user is using a wrong version of application”. The simplest solution is to show a message on the main window of application “Wrong version of application”. If the user passes the information to support people, he can re-deploy the right version of application to this user. Then problem solved. Did the support or end user care about the build number, type or deployment date? NO. They did not.

It is not too easy to identify the problem however BA need find the root cause and give the solution to solve the ultimate problem.

Requirement documented

In most of the agile project, stories are used to document requirement. However, it is not enough according to my experience. Personas, scenarios, business diagrams, and data mapping diagrams are also good documentation for the team to have the same understanding of the requirement.

Project planning

When we have enough prioritized requirement for a couple iterations or releases, we can start planning the project. The project plan will be justified in terms of the changes of the requirements. Certainly the project plan contains a set of prioritized stories.

Requirement Management is not easy. BA need also have psychology knowledge to get and analyze requirement more effectively.

Bookmark on del.icio.us

Trackback URI | Comments RSS