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
454 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
454 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

Fabricio Laguna talks Business Analysis and AI
I recently connected with Fabricio Laguna, aka The Brazilian BA. Fabricio is a passionate and pioneering business analyst from Brazil. During our conversation, we had a thought-provoking discussion on how artificial intelligence stands to shape the field of business analysis in the years ahead. While AI promises to transform many aspects of busines...
Business Architecture, Ontology and More with Terry Roach
It's been a privilege meeting Terry Roach, a visionary in the field of enterprise architecture and business architecture. Terry's insights into the evolution of business models, the importance of ontology in architecture, and the potential of AI to shape our future were not only thought-provoking but also a reflection of his extensive exper...
Today I had the pleasure of chatting to Jignesh Jamnadas, Chief Operations Officer at Mosaic, about his Blueprints for Success. As a Senior Finance and Operations Executive, Jigs (as he is known to many) has a holistic understanding of all facets of business and a flair for managing both people and processes. Having worked with Jigs, I was struc...

 






 

Copyright 2006-2024 by Modern Analyst Media LLC