Try using the following RAM:
It's the last one "O" that I draw your attention to. In your meeting agenda you assign "O" to the developers and designers. They are invied to the workshop but as observers only. This keeps them in the loop while freeing up the meeding for a true needs assessment. This must be socialized with the stakeholders, the team, the PM and the sponsor.
Perry
Guys,
Many thanks for your valuable input.
I had to delay my response as I took a few days to read more about what you have recommended.
I think the Context diagram is a very good advice which I will try to implement. Not sure about DFDs though as it seems too complicated for what we're doing which is mobile apps. 90% of them do not even have a back end. Activity diagrams should, in my opinion, be sufficient
We have a list of models for RML that is pretty comprehensive from a requirements point of view. We organize the models into people, systems and data models. People models organize information from a user point of view. System models organize information about the ecosystem and individual systems. Data models organize the flow of data through the system and individual data elements (from a business not technical point of view).
http://www.seilevel.com/wp-content/uploads/RML-Language-for-Modeling-Software-Requirements1.pdf
Here are some articles on how to prep sessions. If you search the seilevel blog you will probably find more.
http://requirements.seilevel.com/blog/2008/07/how-to-prepare-for-requirements-sessions-with-your-users-tip-1.html
http://requirements.seilevel.com/blog/2006/04/jad-sessions-part-1-the-need.html
http://preview2.seilevel.com/2006/04/jad-sessions-part-2-roles/
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: