Tips for Presenting Requirements and Deliverables

A few days ago I found an very interesting blog post on the presentation of requirements. The post gives 5 tips for presenting requirements which came from a business analyst point of view. The tips are:

 

1. Establish and Communicate the Purpose

2. Use Visual Artifacts to Display Requirements and Design

3. Understand your Audience

4. Understand the Business Context

5. No Surprises

http://www.batimes.com/articles/tips-for-presenting-requirements-and-deliverables.html

 

When I read these tips the sound very logic and come back in my daily work.

 

1 in RUP we have an vision document this document describes the vision and it is one of the most important documents there is, and should be agreed opun.

 

A Vision Document is a software process document that describes the overall ‘vision’, or plan, for a particular piece of software

http://en.wikipedia.org/wiki/Vision_document

 

2 visualization is key, who reads and understands use-cases which are 50 pages thick and contain references to many other documentsAan-niemand-vertellen-emoticon. I practice I found out the showing screen impressions in walkthrough sessions (with different view points) gives the users an clear view on the requirements. and in that way the find the missing requirements. Off course the backend stuff such as error handling and interfacing with other systems can be written down with use-cases but the audience for those specifications id different then the user interaction.

 

3 This tip is a bit obvious because if you don’t know the audience how could you give the right information. If you are giving the CEO a detailed UML diagram he will probably nod and pretend he understands what you are saying, but he doesn’t and is afraid to tell you that. And when you show a financial overview a programmer doesn’t care.

 

4 This tip says know what you are telling and how this fits in with the business. When you present requirements but don’t know where they are for, is a bit silly. You usually get a question why is this necessary?? and i9f you don’t have an answer the requirement will be rejected by the sponsor, and you have to tell the users for whom the requirement was crucial.

 

5 tip 5 says be agile share and test the requirements ass early as possible. If you present you’re requirements when the document is finished you put 40 hours in it and the review on the document gives you usually tons of remarks. But when you shared the early versions of the document these bugs in the specs would have been found earlier.

  1. July 16th, 2016 at 22:22 | #1

    I do not even know the way I stopped up here, but I thought this
    submit used to be great. I do not know who you’re however definitely
    you’re going to a famous blogger should you aren’t already.
    Cheers!

  2. July 16th, 2016 at 22:23 | #2

    I do not even know the way I stopped up here, but I thought this submit
    used to be great. I do not know who you’re however definitely
    you’re going to a famous blogger should you aren’t already.
    Cheers!

  1. No trackbacks yet.