To answer your questions:

1) BCBS stands for Blue cross Blue Shield - one of the biggest health insurer in U.S.

2) the meeting would be attended by PM,SMEs and other analyst with 6 people in all.

3) I was given entity relationship diagram by my PM depicting flow of information b/w entities. He expects me to make a DRD out of it.( after meeting with SMEs)

4)He gave me a ' key project milestones and deliverables' document which gives it a 3 months time. My work( Developing data requirement definitions& then building data flow diagram) is 2 weeks long and then later 'initial requirement gathering' 's time length is to be decided.

5) All i know of , is that he has a project scope and project charter document.

6) I work directly with my PM and unfortunately he travels a lot. So virtually i am left all alone to figure things out.

ajmarkos wrote Hi: Sounds like management realizes that they have a big integration problem.     You want to as soon as possible identify scope (i.e. the extent of the system).   A context diagram is a speciall data flow diagram for identifying scope.  It shows the system as one big circle with inputs from and outputs to external entities (other systems, people, etc.)   The problem with creating a context diagram first-thing is that someone has to already have the "big picture".   And no one ever does.   So, what I typically do is create some rough-cut lower level diagrams and then summarize them up into a context diagram.  So, first thing, focus on data flow inputs to and outputs from the system, high-level functionality, and - especially - the data flows between functions.   This is not an easy task.  People (SME,s end-users - and even most BA's) like to get into the details way to soon.   Letting this happen can really derail your efforts.  Your job is to steer them away from the lower-level stuff, especailly the implementation details, and guide them towards discussing DATA FLOWS at as high of a level as possible.    Make you diagrams as simple to read as possible.  Your first iterations will probably be a mess.   But, "pretty them up" , and then get back with the users and  walikthrough, walkthrough, walkthrough. Tony

Three thumbs up for the context diagram!

Actually, this story has me a little riled.  So I have to write more.

There are about a billion articles and studies available on the net demonstrating how critical requirements management is to project success.  David Wright (of IAG Consulting) might be able to point you to reseach by his comany on the topic.  It says something like 80% ^{(warning: PDOOMA statistic)} of project failures can be traced to poor requirements practices.

There is also a stack of info to demonstrate that project managers who make up estimates without consulting the actual 'do-ers' get what they deserve.  Schedule overruns almost immediately, which are never ever recoverred.

Maybe gather some of this info together and present it to your PM along with a better requirements plan. After all - he/she dfiniely cares about a successful outcome.