Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  My Approach to requirement gathering in a fast paced project
Previous Previous
 
Next Next
New Post 12/10/2012 7:37 AM
Unresolved
User is offline Nitin
8 posts
10th Level Poster


My Approach to requirement gathering in a fast paced project 

 Dear All,

Currently I  am working on business analysis of CRM. For successful implementation in this very fast paced environment I am following below mentioned approach:

1)    After first meeting with stakeholder I develop a prototype which highlights application flow. This basically shows  what happens on screen when user performs a particular function.

Benefits: Initiates users thought process, you may get detailed picture of application.

2)    Once a prototype for a module is finalized then I start working on use cases for that module.

Benefits: covers all the cases of a particular functionality. It is reviewed by coder so that he can understand the document well.

3)    And once use case document gets over I start working on prototype document where it clearly defines how system will behave for a particular screen. This document is developed with a technical lead.

Benefits: All integrations level aspect start coming into picture in this document. Plus what values need to be captured.

Please share your feedback on same approach. Negative views are more welcomed J

 
New Post 12/10/2012 12:49 PM
User is offline dldelancey
61 posts
8th Level Poster


Re: My Approach to requirement gathering in a fast paced project 

Hmm, I'm wondering if there is a tester or QA specialist of some sort who ought to be included?  To determine if you're covering the details they will need for testing the completed product.  Otherwise, if the stakeholders have been identified properly and they are okay with the approach, and the developers are okay with this approach, then it doesn't matter what the rest of us think.

 
New Post 12/11/2012 10:49 PM
User is offline Kimbo
438 posts
5th Level Poster


Re: My Approach to requirement gathering in a fast paced project 

Nitin,

Sounds like you jump straight into screen detail without working out what the actual business requirements are. Therein lies potential disaster. You're quite likely to deliver stuff that your business users don't want. 

Pull yourself up out of the detail and work out your requirements first. Once you have that worked out, then get into the solution.

Kimbo

 
New Post 12/19/2012 8:54 AM
User is offline Phil
1 posts
No Ranking


Re: My Approach to requirement gathering in a fast paced project 

I've got to agree with Kimbo - You need to at least get your high level requirements established first, what are the business trying to achieve, why etc.  I would also suggest, that you create the use cases at the same time as the prototype - even it's a wireframe, as the use case scenarios should help with the path through the system (alt paths etc).

 
New Post 12/20/2012 12:41 PM
User is offline Tony Markos
493 posts
5th Level Poster


Re: My Approach to requirement gathering in a fast paced project 

Nitin:

On the real plus side, you are focused on getting things done, not on creating needless documentation.  But remember, Agile is about creating minimal but quaility (i.e., essential) documentatioin.   As Kimbo mentioned,  it appears that you are largely skipping requirements analysis and  jumping into design.    The one analysis artifact you mention is use cases.   But use cases by them selves lack an integration mechanism.    

If your app is small enough, I guess you can makeif work.  But if you have a larger scale app, you need to scope things out (Context Diagram), and concentrate on the fact that it is not so much the stand alone requirements that need to be discovered, but the essential  interrelationships between them (ie. the data flows).  Do you hav a  need for modeling data requirements?

Your approach:  Screen shots and Use Cases are all that is really needed.  My approach:  Some essential data flow diagrams, entity relationship diagrams, and screen shots is all that is really needed.   

Tony

 

 

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  My Approach to requirement gathering in a fast paced project

Community Blog - Latest Posts

Ekaterina Barabash
Ekaterina Barabash
I address my thoughts to those who are in IT management for whom the terms such as quality of project implementation development and profitability indicators of the company are important.  And it is also addressed to business analysts whose daily routine is the process of communication with Customer. A little about myself first. The last 8...
1 Responses
Dan Tasker
Dan Tasker
I have long been a believer in the saying “Context is everything.” As a business analyst dealing with business users, understanding the context of the topic of discussion is essential. In thinking about what constitutes quality requirements it occurred to me that there are a number of additional contexts that play a role. Examples inclu...
2 Responses
Alexey Kiselev
Alexey Kiselev
We are writing User Stories to fix the scope and describe - what our application should do when implemented.User Stories are great, because the are: Short, Defining Roles, A great connection of the requirement itself and a business need. User Story declared as a high level definition of the requirement, but it could be used to s...
0 Responses




Latest Articles

What Does a Technical Business analyst do?
Feb 17, 2019
0 Comments
The function of a technical business analyst is to bridge between business and technical teams. This can be undertaken in various forms. First, the br...
Featured Digital Library Resources 
Copyright 2006-2019 by Modern Analyst Media LLC