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

Samuel02
Samuel02
With the advent of modern-day cloud infrastructure, many business-critical applications like databases, ERPs, Marketing applications have all moved to the cloud. With this, most of the business-critical data now reside in the cloud. Now that all the business data resides on the cloud, companies need a data warehouse that can seamlessly store the da...
0 Responses
BPM_online
BPM_online
Bpm'online, a global business software company leading in the space of low-code, process automation, and CRM, will be soon announcing their new company name. The new name will be launched in the sky via a breathtaking skydiving performance involving 160 bpm’online employees, including the CEO. The new name of bpm’online is to be fo...
0 Responses
Heta Raval
Heta Raval
In a current scenario, when you are eliciting software service-based requirements then, you may be able to derive requirements in certain varieties. In the beginning, they can be just functional or non-functional requirements. But when you come across many other requirements as time goes, you can conclude requirements into several categories and wi...
0 Responses




Latest Articles

What’s Missing from Agile?
Oct 20, 2019
0 Comments
John Seddon launches an attack on the value of Agile as practiced and charts a better way to analyse and design for improvement, making information te...
Copyright 2006-2019 by Modern Analyst Media LLC