ANSWER

Few analysts are brought on to a project at the very beginning.  For those that are, they will often have a hand in creating some of the important documents that other analysts should reference when they first join.

First, get your hands on the project charter.  The project charter, while high level, will provide critical information on the project such as:

• the reasons for undertaking the project, including the high level business goal or goals that are to be satisfied by the project and a calculation of Return on Investment (ROI),
• objectives and sub-goals of the project as well as major constraints due to current business processes or existing technology infrastructure,
• the high level vision and scope of the project outlining the initial direction for the solution being developed,
• major risks which need to be avoided while developing the solution,
• the important stakeholders involved which should include not only a project sponsor and steering committee members but also the business representatives that will have final sign-off on requirements.

Find out as much as you can about the project management processes that are being used to manage timelines, risks, communications, costs, etc.  Ideally, these processes are outlined in a formal document.  If not, be sure to talk to the project manager(s) on your project to fully understand the processes that should be followed.

The same goes for the analysis process and artifacts being used.  Understand the methods that will be used for eliciting and documenting requirements.  How will these requirements be communicated? How will they be captured and translated into functional specifications?  Being an analyst, this is something that you will be taught at some point on the project, but the sooner you learn the details of the analysis process and artifacts being used the better off you will be.

If requirements elicitation has already begun, review the existing requirements documentation.  Reviewing requirements will bring you up to speed rapidly.  Record any questions you have regarding the system requirements and get answers to them.  If a prototype has been created as a method for identifying and clarifying requirements, understand the prototype inside and out.  Take the time to understand why each screen was designed a particular way.  Was it to support a business requirement, or was it merely a design decision that could have been handled in a different way.