Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Planning for requirements gathering and elicitation
Previous Previous
 
Next Next
New Post 1/17/2013 5:21 AM
User is offline sp_key
7 posts
10th Level Poster


Planning for requirements gathering and elicitation 

Dear all,

I am currently, working on a project that needs requirements gathering. I do not have previous experience in collecting requirements and as such, I would like to summarise my thoughts in the hope that you may have some valuable advice to offer.

I have already started with a joint interview session with all stakeholders. The aim of this interview was to get a general appreciation of what the system does and the 'actors' that interact with it. I found out that the system has three user-types, two internal and one end-user while there are also a couple of external systems that need to integrate with it.

Now, my plan is to run individual discussions/workshops with each stakeholder separately so tha to run through each scenario. More specifically, I am planning of listing the activities each role should be able to accomplish and run through the journeys. I am hoping of capturing all this with Activity Diagrams and possibly some wireframe sketches on the whiteboard in order to help stakeholders with visualising this service. Then, I am planning of writing a requirements list, prioritise it (according to moscow) and write the use cases (diagram and specifications).

Is that a good plan? Not sure what should happen next. Do I involve our Designer here by asking him to design a few high level wireframes? Do I need to create an ERD too?  

Many thanks in advance

 
New Post 1/19/2013 12:31 PM
User is offline Kimbo
450 posts
5th Level Poster


Re: Planning for requirements gathering and elicitation 

sp_key,

Looks llike you have decent approach.

Couple of comments:

1. Instead of individual meetings I suggest you run a workshop. Its best to have all stakeholders and decision makers in the room at once, so they can agree the requirements as you are eliciting them. This will save you rework later.

2. Recommend you hold of the wireframes until after you know the requirements. Best to understand what they want before providing a solution.

Kimbo

 
New Post 1/21/2013 12:46 AM
User is offline sp_key
7 posts
10th Level Poster


Re: Planning for requirements gathering and elicitation 

 Hi Kimbo,

 

Many thanks for your valuable input.

Should I also include the developers early in the process? I am concerned that if I do I'll be putting constraints straight away as they'll be approaching the problem from a development point of view. On the other hand, if I don't I may be missing important information.

 

Once again, many thanks for your advice

Sp.

 
New Post 1/21/2013 10:24 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Planning for requirements gathering and elicitation 

Hi:

In addtion to Kimbo's suggestion, I suggest that you formally identify the project's scope with a context diagram.  Could save alot of costly changes later.

Do you need an ERDs?     It depends on how complex your project, but, from my experience yes, at least a few.  Key question here is what are you going to use as inputs to creating your ERDs.   In the ideal (which is very seldom actually done) you would first create data flow diagrams, which would then be used to create a logical data dictionary, from which you would then create ERDs.   Again, few create a logical data dictionary, but, knowing what one is - that is knowing the ideal - is very helpful, as with that knowledge, you are much better prepared to pragmatically do what you can.

Tony

 

 
New Post 1/21/2013 2:27 PM
User is offline Kimbo
450 posts
5th Level Poster


Re: Planning for requirements gathering and elicitation 

Sp,

I try to avoid having developers in requirements meetings. In my experience, they will always try to limit the business's requirements to what they imagine they can build easily. This stops the business from saying what they really want. I like to promote some blue sky thinking early on, so people think outside of the box - it can produce some very creative results.

If you are forced to include developers than try to only have them in there as observers. If that doesn't work, escalate to your project manager. If that doesn't work, get another job :)

Regarding ERDs, as part of defining requirements, functionality, business rules, I often come up with a business domain definition. this is a set of classes that I define using a UML class diagram. ERDs are the old fashioned way but they work too.

Kimbo

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Planning for requirements gathering and elicitation

Community Blog - Latest Posts

The cloud-native application development has helped enterprises all around the globe reduce time-to-market, enhance performance, and develop agility and flexibility. Several enterprises are achieving these results by migrating their systems or traditional monolithic applications to the cloud. But to gain from the real benefits of cloud technology, ...
So you’ve found the perfect time and place to study and you’re ready to finally get some work done. You’ve pulled out your laptop, your textbook, and your notes, and four different highlighters. After five minutes of reading your textbook, you start zoning out and thinking about puppies. Then, you go on Tumblr and look at cut...
Elicitation involves bringing out or drawing out information. Elicitation is a key task in business analysis as without proper elicitation the requirements for the solution to the business needs cannot be identified. 1. Not understanding underlying business need Organization’s business environment keeps changing with respect to Customer...

 






 

Copyright 2006-2021 by Modern Analyst Media LLC