Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Requirement Elicitation and Documentation.
Previous Previous
 
Next Next
New Post 7/31/2008 9:52 PM
User is offline Raj
5 posts
10th Level Poster


Requirement Elicitation and Documentation. 

Hi All,

I am a Business Analyst, I have recently started working on a Core Banking project where my role is to gather requirements and document it. The biggest hurdle, indeed a challenge is that I have to documet all the requirements from the books and docs without any interaction with end users. The worst part of the story is that even I dont have any friends (network) in banking domain.

Now, In the document I have to cover the detail usecases i.e, user system interaction which sometimes is very challenging & very very difficult to understand from the books because the banking books only covers the business rules/norms etc.

I wish if someone could give me some suggestion which help to accomplish my job in these circumstanses.

Regards,

Raj Sharma.

 
New Post 8/1/2008 12:21 AM
User is offline Guy Beauchamp
257 posts
www.smart-ba.com
5th Level Poster




Re: Requirement Elicitation and Documentation. 

Hi Raj,

This does not sound like a very happy assigment and I hope that things will soon change.

In the meantime, it would be a very unusual change project that had no user requirements. If your project does have user requirements then you MUST have the opportunity to elicit those requirements from relevant users or you CANNOT complete the analysis of user requirements. This is not a 'nice to have' thing, you MUST have it.

If you are being restricted and told you cannot have user access you should

1. raise the issue that you are not being given the resources to do your job

2. raise the very high impact and very high liklihood risk that the project will fail to deliver any benefits as you are not able to uncover the user requirements that will deliver the benefits

These should be escalated to the Project Manager and/or sponors as the issue threatens to fatally damage the project.

If this is not done then when the project fails (and it almost certainly will be 'when' and not 'if' unless the issue is resolved), sponsors will want to know why the requirements weren't right.

While rasing the issue and risk, by all means use the documents to identify potential requirements that you can get users (when you have access to them!)  to change and verify as neccessary.

I hope this helps!

Guy

 
New Post 8/1/2008 5:32 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Requirement Elicitation and Documentation. 

Hi:

You are obvisously in a very difficult situation:  Text based requirements doc's, if not backed up with rigorous models, are going to be very disjointed.

At the least, I would strive to have frequent reviews and  ask for a requirements sign-offs.  You want to bring issues up as sooner - not later.  Who knows, this may cause them to see what you are up against.

Frankly, I would first use data flow diagrams as these make "holes" in existing documentation glaringly obvious.  Use cases do not.   You want to clearly demonstrate that you have not been given  key information - and the sooner you do such, the easier it will be in the long run . 

Tony

 

 

 
New Post 8/1/2008 1:09 PM
User is offline Dave F
4 posts
No Ranking


Re: Requirement Elicitation and Documentation. 

I have to agree with the other posters that without access to the users you risk creating inaccurate, perhaps wildly inaccurate, requirements due to no fault of your own.  May I ask the reason you cannot access your end users?  The bottom line is that the people doing the work are the experts at operating the business and should always be a primary source of requirements.  Things written in documents do not reflect what's actually going on in the work.

Here's a thought:  find out how user acceptance testing is done (I assume it involves users!) and see if you can "steal" that process to test paper UI mockups with users.  Is that a possibility?  We're talking about doing a UAT for requirements if you will.  From your documentation analysis, take your best shot at the functional requirements and then make a paper mockup UI using post-it notes to represent windows, dialog boxes, buttons, and menus.  Then, test the mockups with users to change the UI on the fly based on their feedback (and you'll get a LOT of feedback).  If they're remote users that you can't get to, it does get trickier but I've had success using a camera and LiveMeeting.  What you're really doing is a sneaky way to evolve your functional requirements and use cases based on user feedback!

Some hints on paper mockups if you haven't done them before:
- Hand draw each screen on a sheet of paper where buttons, windows, menus, etc. are written on cut up postit notes.  This lets you change the prototype in the moment when testing with users
- Sit down with your user, at their workspace, and have them to look over the entering page and ask what they'd do next.  If they point to a button, then change the appearance of the screen with new postits or show them a new screen that you designed the button to activate (you're acting like the computer).  If they ask what a UI function does, instead of telling them your answer ask them what they think it means or what it should do - then make any changes so it does what they say it should do.
- Anything they don't like or wonder what it's for, find out why and change it to their liking
- Iterate this with a set of representative users and you'll end up with a pretty stable design with user-tested requirements
- Then take the changes in the mockup and map them to changes in your requirements doc.

 
New Post 8/1/2008 10:04 PM
User is offline Raj
5 posts
10th Level Poster


Re: Requirement Elicitation and Documentation. 

Hi Guy,

Thanks for suggestions. 

Raj.

 

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Requirement Elicitation and Documentation.

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

 



Upcoming Live Webinars




 

Copyright 2006-2024 by Modern Analyst Media LLC