Gathering Business Requirements is an art – Learn it

How will u go ahead in gathering requirements?

Solution.) I make sure that the project scope is clear and complete before I can begin actual detailed requirements gathering.

In some of the projects, Sometimes the scope is defined by the project sponsor or manager or by stake holders for some projects. But, I was responsible for defining and documenting the scope as part of the requirements gathering task in my last project.

In that case I started with creating high level vision document before actually defining the scope of the project.

For creating vision document

* I interviewed the business users to determine functional requirements of the software system

* Analyze interview results to identify NFRs, risks, and constraints

* Create a project Vision document from the results of the interviews and risk analysis

My role as Defining and documenting the project scope started with

(i) Why the project has been initiated (project statement of purpose) and

(ii) The goals of the project (project objectives).

(iii) Names of all the organizations that will be involved with the project; this included people, systems, internal departments, and outside organizations (project external interactions).

(iv)Other important components of the project scope documentation included the project viewpointproject assumptions, and business risks.

The project scope should include a high-level description of the business processes that will be included.

It sometimes also includes a list of items that specifically will not be included in the scope. This gives the entire project team a complete understanding of the work that I will be doing as we move into detailed requirements gathering.

These components gave me the information necessary to prioritize and focus their requirements gathering.

Don’t forget to read our 100 Business Analyst Interview Questions.

I use to elicit the Requirements through various activities such as interviewing, brainstorming, conceptual prototyping, and using questionnaires.

The result of requirements elicitation is a list of requests or needs that are described textually and graphically and that have been given priority relative to one another.

We used to gather user input during application development in a number of ways: –

*surveys (usually for large organizations);

*on-site workflow observation;

*one-on-one user interviews;

*focus group, multiple-user sessions;

* Or combinations and variations of all of these.

The Main Goal was to – Understand the business process.

Di you read our How to Gather Requirements ? Step-by-Step

Leave a Reply

Your email address will not be published.