Using EA for Work Breakdown estimation

[NoPuck4You]

So here is the goal (2 parts) I'm trying to achieve:

Part 1:

1. Catalog all requirements in EA model.
2. Create Use Cases against the requirements.
3. In some fashion identify tasks against those use cases. Currently I'm using a sequence diagram to determine the flow which creates my "tasks". However, I'm quite open to alternate approaches.
4. Assign LOE estimates and resources to tasks.
5. Generate documentation that can be imported into Excel that will show Scenario (Use Case) + All associated tasks with estimates and resource names assigned to them.

Part 2:

The ultimate goal is to create Team Foundation Work items of type Scenario for each use case and create work items of type Task that link back to the scenario work items. The Tasks should have the "Hours Remaining" field value imported from the LOE esimate in EA and the person assigned to the task should also be coming from EA (potentially).

---------

So I've been playing with the RTF document generator and the MDG link and I've not been able to achieve either goal so far. The first on is achievable by breaking UML standards (read HACK) which I do not like.

Does anyone have any suggestions/recommendations on how to achieve either approach? Example instructions would be nice.

[sargasso]

WTGPR

Part 1:
 
1. Catalog all requirements in EA model.
2. Create Use Cases against the requirements.
3. In some fashion identify tasks against those use cases. Currently I'm using a sequence diagram to determine the flow which creates my "tasks". However, I'm quite open to alternate approaches.
4. Assign LOE estimates and resources to tasks.
5. Generate documentation that can be imported into Excel that will show Scenario (Use Case) + All associated tasks with estimates and resource names assigned to them.

1. OK
2. Use cases don't come "against" the requirements, they come from a detailed understnding of "how the system will could meet the requirements".  There are many ways that the chicken could have crossed the road.  What is important is what posible outcomes there are of: actor-chicken objective-otherside scenario-(a)semi-trailer@160km/h | scenario-(b) no-traffic-at-all | scenario-(c) wrong-road | scneario-(d) wrong chicken |etc...
Consider, delve, consult - formal requirements these days are at best a squallid redintion of what the (real) users DONT want the system to do.  
3. See 2.  Task 1 get the real use cases, if you don't you will design, and with a bit of bad luck, implement the (those) requirements.
4. Think of a number and multiply it by 6.73
5. HAHAHAHAHAHA!

bol
bruce

[thomaskilian]

Bruce seems to be one of the few guys that comes back from holiday with improved sarkasm. But basically he is right.

Additionally you could read from the tea leaves to achieve what you want.