Hi Dean,
If its just a maintenance function for the user you can probably just write one document. Record what the business requirements are, any business rules and the business domain (data). Define your use cases or user stories and then prototype your screens.
Its unclear from your post if there is more than one screen. If its a small number you can probably just draw up a prototype on the whiteboard. Maintenance functions are often very similar - standard CRUD functionality with the only difference being the data being maintained.
Kimbo
The whiteboard is just the medium for capturing the discussion, usually with some sort of graphical representation. Whiteboards are good for not only creating mock-ups of new UI features, but you can also create context and data flow diagrams which help center the discussion and put up the so-called rails around the feature: What are you inputs and outputs? Who are your users? If you're trying to elicit details about process you might look at workflow/process analysis or possibly state diagrams for your data or UI.
More important than the "whiteboard" you need to go into the discussion knowing what your goals are, which questions need to be answered, and how you know when to stop. Also don't be afraid to be not done at the end of your allotted time. Discussion invariably raises additional questions which either need more time or investigation. Sometimes you can defer those, but sometimes they demand a follow-up discussion in order to meet the needs of your product.
Good luck!
Jenny:
Some really great comments about creating Data Flow Diagrams (including Context Diagrams) at the Whiteboard! DFDs, especially for the first few iterations on a more complex projects, require rapid iternations. No time for pretty diagrams using Visio or other software tools. A BA needs to get up to the Whitboard and quickly iron out his/her more gross misunderstandings. Thats how a BA makes a significant contribution to an Agile project!
"What are your inputs and outputs?". THATS the $64 K question to ask that is over the head of the BPMN, Use Case, and Activity Diagram crowds.
Tony
brought to you by enabling practitioners & organizations to achieve their goals using: