How to Prepare for Software Requirements Sessions with Your Users – Tip 2

ArgonDigital - enterprise automation experts

Share This Post

Last time we talked about organizing your time. Tips on how to organize your information are here or here.

Today’s suggestion: Prepare Your Requirements Models In Advance

Prepare draft requirements models in advance of the meeting. The reality is that good requirements analysts do in fact know quite a bit about the business processes and requirements. There is a misconception that they should remain unbiased; however, these individuals become experts in the systems they are capturing requirements for and that expertise should be utilized to its full advantage.

As an example, if you are going to cover a topic with a user about how he or she does a task, then you can try to come up with the obvious use cases in advance. You can then take it one step further and actually try to write the header information and normal course for the use cases. Similarly, you may find it valuable to draft state diagrams, where you capture the states and transitions that are obvious and highlight the unknown ones for completion in the meeting. Virtually all requirements models can be pre-drafted if you know a little bit about the business.

In doing these models ahead of time, you will find yourself jotting down lots of questions in the margins, like “What really happens at this step?” or “Should they do X instead of Y?”. Even if you throw away the draft model because it was all wrong (which rarely happens), there is still a value from the time investment because you came up with a list of detailed questions. Essentially this is a brainstorming tool for you.

Starting from a blank slate can seem like a daunting task, so once you have draft models, in the meetings with users, you can use these models to work from. Similarly to the authoring experience, reviewing the models will spur questions in the reader’s mind. Therefore they make an excellent tool with which to facilitate a user meeting.

See another great post on how to choose a requirements model.

Come back for part 3 next!

More To Explore