1. Feasibility study of the new product/service

2. Requirements analysis; implying understanding of the application context, collection of requirements from the product planner, sorting and grouping the requirements, and prioritizing the same to fit into the project plan and budget

3. Requirements Specification – both from the point of view of user (to facilitate testing) and system developer (to facilitate development), and

4. Requirements validation for realism, consistency and completeness

All this results in a Requirements document (System Requirements Specification (SRS)) and it is circulated among the development and testing teams for their perusal. Such a requirements document must essentially contain:

1. HW configuration for which said SW product/service is being built

2. Conceptual model i.e. high level view of the product/service

3. Functional requirements i.e. services provided to the end-user of the product/service

4. Other requirements i.e. speed, size, ease of use, reliability, portability, etc., and

5. Maintenance/evolution i.e. provision of anticipating changes due to HW evolution, changing user needs, etc.

Here, it is important that the Requirements Engineer differentiates between the SW product and SW development. The requirements are supposed to address the SW product, not the development process. And hence any details about the design or implementation should be avoided. In case, the scope of the product/service is too broad, Requirements Engineer may opt for going for separate SRS for different functions of the product/service. However, care must be taken to have clear interfaces among these SRSs (communication interfaces, SW interfaces, DB interfaces, etc.).

Aseem is a Product Requirements Coordinator in Tokyo at a mobile communication and entertainment devices provider ranked among the global top 5. In his spare time he likes to watch movies and occasionally play with his camera. Visit him at his photo blog at http://metsuki.tumblr.com

If I correctly understand the term “expert”, then it means being someone who has very deep understanding of the domain. Industry usually refer to BA’s as domain experts. BA’s are the responsible people who understand the requirements from clients/stake holders and then communicate with technical team regarding the requirement in detail. However, even this is true that BA’s usually keep on changing projects and with every project, usually their domain area changes. Now in this situation how many BA’s can “actually” have the confidence to call themselves as “Subject Matter Experts”???? So if this is the condition, then how can a BA ever have Project Ownership??

By Rishi Srivastava

Knowledge areas do not necessarily represent, or need to align with, phases of a project.  There is no specific order in which tasks from various knowledge areas must be performed by the business analyst, as long as the necessary inputs for each task have been completed and are available. 

The seven knowledge areas are:

1. Business Analysis Planning and Monitoring
2. Elicitation
3. Enterprise Analysis
4. Requirements Analysis
5. Solution Assessment and Validation
6. Requirements Management and Communication
7. Underlying Competencies

In broad terms, the Problem Domain describes the area undergoing analysis. The scope of the problem domain needs to be identified upfront by the business analyst.  The size and scope of the problem domain can vary greatly depending on the goals of the project being undertaken.  The scope may align with the boundaries of an entire organization or it may be much more granular, aligning with a single organizational unit, a specific business process, or a particular system.

Even when the scope of the problem domain aligns with the boundaries of a particular group or system it may also include stakeholders outside of the process or organizational group such as customers, suppliers, or any other stakeholder which provides an input or accepts an output of a process, organization, or system.

In short, the Problem Domain is anything and everything that is needed to define the area under analysis, fully understand the inputs and outputs of its processes, and achieve the goals of the area under analysis, but nothing more.

Browsing net, today I came across a poem..  For the first time I felt it’s not just a poem.. but a very meaningful poem.. Specially from the perspective of a Business Analyst!

Poem by Walter Foss:

Once upon a time there was a calf.
One evening he walked home through a thick jungle.
The distance to his home was only one kilometre but he walked three kilometres since, like all calves, he wandered here and there, left and right, up and down.
The next morning a shepherd’s dog passed that way and saw the calf’s hoof marks, and followed the path of this calf through the woods.
Shortly after, the first sheep of a flock followed the path and behind him all the other sheep. Thus a path was made through the woods
Men began to use that path, cursing its twists and turns as they did, but doing nothing about it.
The path gradually became a lane, the lane became a road and horses and bullock carts followed it – followed the steps of the wandering calf.
A century later the road became a street, and then a city’s crowded thoroughfare, with thousands following in the footsteps of the wobbly calf.
Three centuries later the road became the main street of a very large city. Buses, lorries, trams and cars followed the zigzag path of the calf.

“A hundred thousand men were led
By one calf near three centuries dead
They followed still his crooked way
And lost one hundred years a day…
For men are prone to go it blind
Along the calf-path of the mind
And work away from sun to sun
They follow in the beaten track,
And out and in and forth and back,
And still their twisting course pursue
To keep the path that others do,
They keep the path a sacred groove,
Along which all their lives they move.”

The above poem captures the essence of what and how a Business Analyst is responsible for leading any project right from the scratch and make the way for everyone to follow!!

I found this poem highly inspiring……….

Memories of my initial days of being on the profile of a Business Analyst, gives me a strange feeling.. After completing my masters in computer application, I worked as a programmer for sometime. Later, as I got inclined more towards the requirements and analysis part of the projects, I was given a chance to be a Business Analyst with a not so well known company in Pune. My task was to understand the requirements of the ongoing projects and map the business processes and document them as requirements. After some experience working for this company in Pune I moved on to a company in Mumbai with a shiny dream to work on broader level requirements and bigger projects.

Now here started the problem.. I felt that the techies who were into the programming side started looking at me as a competition. Weird.. isn’t it? Why competition with a BA? I still wonder.. was it because of the perception that a BA does less of technology and more of business or was it the requirements I used to jot down in use case documents? Can requirements be annoying for a programmer? I guess so… while working on the requirements for a product based company I often felt the heat and had to redefine the requirements of an in-house software product. (If you are working for an in-house software product with internal requirements, be ready to change the requirement multiple times.) In fact many times the requirement process is actually driven by the Team Leads and Project Managers.

With the job description of a “Business Analyst” I somehow always felt excluded from the so called techie group of the company. Since a BA bridges the gap between Business side and Technical side, my ownership in the projects I worked on was always confusing.

If it’s the technical guys who own the project, business side treats you like a techie who hardly adds any extra value to the project. If business side has the ownership of the project, techies make it real difficult for a you to make them work as per the requirements provided. (Not to forget the time factor!)

By – Rishi Srivastava