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

Please follow and like us:

11 comments

  1. My brother recommended I might like this website. He was totally right. This post actually made my day. You can not imagine just how much time I had spent for this info! Thanks!

  2. Hey there! This is my 1st comment here so I just wanted to give a quick shout out and say I truly enjoy reading your articles. Can you suggest any other blogs/websites/forums that go over the same subjects? Many thanks!

  3. Good day! I simply wish to offer you a huge thumbs up for the excellent info you’ve got right here on this post. I’ll be coming back to your website for more soon.

  4. You really make it appear so easy with your presentation but I find this topic to be really something that I feel I would never understand. It seems too complex and very vast for me. I’m looking ahead in your next publish, I’ll attempt to get the hang of it!

  5. Aw, this was a very good post. Taking the time and actual effort to generate a great article… but what can I say… I hesitate a lot and never manage to get nearly anything done.

  6. I’m not sure exactly why but this blog is loading extremely slow for me. Is anyone else having this issue or is it a problem on my end? I’ll check back later on and see if the problem still exists.

Leave a Reply

Your email address will not be published.