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

Hosted by Deirdre Caren on Agora Insight's Blueprints for Success - Business Architecture and AI In our recent conversation with Joseph Edward, we explored the transformative power of business architecture (BA) and technology as tools for uplifting communities. Joseph, with his rich background spanning from education to IT leadership, shared...
Hosted by Deirdre Caren on Agora Insight's Blueprints for Success - The AI Business Analyst I recently had an engaging discussion with Maria Becerra, a passionate advocate for AI and an accomplished business analyst, on the AI Business Analyst. Maria is a respected name in strategy, business analysis and AI. Her path from Colombia to Canada ...
Hosted by Deirdre Caren on Agora Insight's Blueprints for Success - Business Analysis. I'm happy to share insights from my recent conversation with Kingsley T. Ihejirika, PhD, an ICT Business Analyst at the Ministry of Justice in New Zealand. Kingsley's unique blend of academic theory and practical expertise sheds light on the path t...

 






 

Copyright 2006-2024 by Modern Analyst Media LLC