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

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.