Messages - Glassboy

So any insights, pointers, real life experience are more than welcome!

I think it is very simple. User stories shape the design. Requirements are for testing against.

Over the last decade technical projects have come to be almost wholly dominated by project managers, business analysts and change control specialists. I came across a project the other day that had been started and stopped three times and had burnt a couple of years worth of funding without ever having anyone on it that could actually do the job of building the solution to the business problem.

This is the pain that is causing the desire for Agile - even if Agile isn't the solution to the problem.

In your situation I'd just turn things on their head.

So take from whatever you used to do in your Waterfall methodology for requirements (and use cases) only that which the testing team can test against.

For the rest of it, have an honest conversation with your Architects et al about what they just used to ignore. There's probably quite a lot that wasn't a useful input for anyone.

BUT don't skimp on your information models. Understanding your concept domains will help you avoid stupid conversations about things like "bounded context".

That's an interesting question. Given that you're using Archimate and don't have things like instantiation or v13 new time aware modelling available you're limited in what you're going to be able to do beyond your n and n+1 being completely separate models.