Advanced Search
Blogger Info
Name: Joy Hidden
Location: Hidden, Hidden
Last login: 7/31/2008
Member since: 5/16/2008
Personal Information
Country: Hidden
City: Hidden
State: Hidden
IM:
View Full Profile >
Joy Beatty
Recent Posts
Blogroll
iRise Product Blog
updated 7/9/2008
iRise Product Definition Team Blog
updated 5/9/2008
iRise Online Blog
updated 2/12/2008
iRise on the Rise
updated 12/4/2007
How Organizations Find iRise: A Documentary
updated 11/30/2007
Current Wisdom
updated 7/30/2008
Thoughts from a Couple of CBAPs
updated 7/14/2008
IxD: The Art of Interaction Design
updated 7/21/2008
How to Work
updated 1/20/2008
Better Projects - Catalyze Edition
updated 6/6/2008
Momentum
updated 4/27/2008
IIBA Senior Leadership Blog
updated 7/8/2008
Advanced User Interface Specification
updated 5/30/2008
thought catalyst
updated 9/24/2007
GrayMatter
updated 6/28/2008
Nouns and Verbs - What's in Your Box?
updated 2/16/2008
Business Analysis Insight
updated 12/9/2007
The Product Development Blog
updated 7/11/2007
User Experience and Cognitive Engineering
updated 12/4/2007
Emergence of the IT Business Analyst
updated 9/9/2007
New Blog for David Rodriguez
updated 10/10/2007
Communication, usability, eye tracking and all things helping people
updated 3/11/2008
Human Experience Design
updated 4/8/2008
Patrick Neeman's Blog
updated 6/18/2008
I WANT TO FIND PEOPLE JOBS!
updated 5/13/2008
Requirements Defined: A Software Requirements Blog By Seilevel
updated 7/31/2008
Ed Taaffe's Blog
updated 6/26/2008
Executive Perspectives
updated 9/14/2007
Facilitation TIPS (Tools, Insight, Planning, and Skills.)
updated 8/23/2007
Silicon Valley
updated 4/22/2008
Agile and JAD - How they can work together for better application development
updated 9/5/2007
The Design of Big Things
updated 6/8/2007
New Blog for Michael Rawlins
updated 10/10/2007
New Blog for Kevin Parker
updated 10/10/2007
Engaging designs – Should they be instruction or interaction?
updated 11/21/2007
Archives
Requirements Defined: A Software Requirements Blog By Seilevel

Seilevel is a professional services company that creates software requirements documents for Fortune 1000 companies. Leading companies turn to us to identify and delineate their needs because of a proven approach to software requirements that saves you development dollars and maximizes resources. Seilevel gets the requirements right, so our clients get their software right.
No tags found.
Blogs Home: Requirements Defined: A Software Requirements Blog By Seilevel
     
 Subscribe

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

7/9/2008 | posted by
Name: Joy Hidden
Location: Hidden, Hidden
Last login: 7/31/2008
Member since: 5/16/2008
Personal Information
Country: Hidden
City: Hidden
State: Hidden
IM:
View Full Profile >
joy.beatty

 

Last time we talked about organizing your time.

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!


 

 
 
 Add Tag

 
Please login to post a comment.