Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Document analysis for requirements
Previous Previous
 
Next Next
New Post 1/14/2009 11:53 PM
User is offline Navi
5 posts
10th Level Poster


Document analysis for requirements 

HI guys, i was wondering whether any of you would be able to give me some advice...

As part of my work experience i have been assigned a new project. Pretty much i have been posted at a marketing agency which uses a massive CRM software.

As part of my requirements gathering, my project manager has told me to analyze the user guide of the CRM system they are using to gain requirements, as the employees are very dependant upon the system. 

I was wondering when performing this whether i should look into alternative comparable software packages and if so what kind of criteria i should use to analyze the strengths of the software.

tPS this is my first requirements gathering using Document analysis so any help would be great

Thanks everyone,

Kind Regards, Navi

 

 

 
New Post 1/16/2009 12:01 PM
User is offline Adrian M.
732 posts
3rd Level Poster




Re: Document analysis for requirements 

Hi Navi,

I'm sure most experienced business analysts would agree that gathering requirements from user manuals is not the ideal way to go.  Having said that, given the direction you've been given, here are a couple of things to consider:

  • It is possible that understanding the features of the current system is just the first step in the requirements gathering process - so try to find out from your manager what will happen once you complete your tasks; that is, find out who will be the consumer of your findings.
  • If the business units and the users are happy with the features they have but a new system must be created for reasons other than missing features/functionality then gathering the requirements from user manual is not a bad start.
  • The thing to consider is that user manuals do not generally specify what specific business rules or logic the system uses to perform its tasks.  For example:  the user manual might say: "To find out the APR for the loan, press the 'Calculate APR' button in the Loan Details screen."  This is good enough for the end-user but it is not good enough for you if you need to build a new system which computes the APR since you need the logic and formulas for doing so.
  • In most cases, gathering requirements from the user manual will only be but one step of the larger requirements gathering process.

Hope this helps!

- Adrian


Adrian Marchis
Business Analyst Community Blog - Post your thoughts!
 
New Post 1/16/2009 2:52 PM
User is offline Irvine Analyst
3 posts
No Ranking


Re: Document analysis for requirements 

I also agree that you'll need to do more than look at the user manual to find the requirements of the current CRM, but it can be a good first start. I would begin to document the features that i could find from the user guide and then meet with the users to document the rest. I would use a context diagram to identify the scope of the current CRM to identify all of the major functions and external systems. If the users have any pain-points or features that aren't present in their current CRM system, then I would document them and create a 'to be' model. Lastly I would prioritize the list with the users and use that list to go shopping for a new CRM. Before you can shop for a vendor package, you need to know what are the important functions the business is looking for.

 

 

 
New Post 1/16/2009 3:22 PM
User is offline Navi
5 posts
10th Level Poster


Re: Document analysis for requirements 

Hi guys, thanks alot for your responses they have defenitely helped me. I am quite sure that the reason for this document analysis is the stubborn mindset of the companies upper management. Little allowance in terms of scheduled time for analysis has forced our team to gain requirements in every way possible before engaging in user interviews and focus groups.

If anyone could suggest  pre-interview requirements gathering methods that would assist us in focusing our interviews and minimizing the time required within interviews that would be great.

thanks again everyone

Kind Regards,  Navi

 
New Post 1/16/2009 6:42 PM
User is offline Craig Brown
560 posts
www.betterprojects.net
4th Level Poster




Re: Document analysis for requirements 

Reading the documentation is actually  useful step, but like the others have said - it won't be enough.

If you can't access real users you should go to a system administrator or programmer and get them to talk you though the system's main functions.  They may not be usre about what value functions add but you can posibly use your won judgement.

Poentially try to cme up with a "features and benefits" list.

 

Other places to go include;

  • Fault tickets
  • Change requests/enhancement requests to the system
  • Original requirements specs from when the system weas first introduced

Lastly - you should be able to get the time of someone who knows the system.  Go have lunch with them and discuss it there.  That's part of teh BA' arsenal of tools - getting things done via the unofficial channels.

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Document analysis for requirements

Community Blog - Latest Posts

Gen1us2k
Gen1us2k
Most of the IT projects imply constant cooperation between the team members and customers. Although it might be often overlooked, the role and the importance of the client within the project is very crucial. Thus, it is in your interest to build a strong relationship based on trust. However, gaining trust on a single occasion is not a dealmaker &md...
0 Responses
emorphistechno
emorphistechno
Introduction In today's world, most enterprises work aggressively to achieve a higher level of business growth, which is made possible by leveraging one of the best automation technologies. One such technology is Robotic Process Automation (RPA) that plays a vital role in streamlining the customer experience in the most profitable manner.&nb...
0 Responses
Nick Stowers
Nick Stowers
Introduction   When I was introduced to scrum, the burndown chart was a tool that was highly emphasised however I feel the purpose has changed from it being a tool to predict (to a certain level) timescales for delivery to a tool that measures a team’s productivity…..in other words, the focus is on the number of points clear...
0 Responses






Latest Articles

Top Metrics for measuring Agile Project’s success
Aug 01, 2020
0 Comments
Good news is that the adoption of an agile approach is increasing with more and more projects being successful. As a business analyst / project manage...
Copyright 2006-2020 by Modern Analyst Media LLC