How to show that you understand the requirements of the project [closed]

Question

How do you show your clients/employers that you understood their requirements?

What do you recommend to use? Use-Case diagrams? Flow-Charts? Data-Flow-Diagrams? Decision Trees?

I'm not really asking for a very detailed answer. Just something simple to help me communicate with the person who wrote the requirements and to see if both of you are on the same page.

Answer 1

I usually put together a PowerPoint deck fairly early in a project, giving a high-level overview of the project, along with some architectural diagrams (the simpler the better) and screen mockups/wireframes. Then I have a "kick-off" meeting for requirements review, and talk through the business problem and proposed solution.

Answer 2

I simply explain the requirements back in my own language, supplying my assumptions and adding in limitations.

The requirement may be "Button turns green when clicked"

I would ask "Ok, so when the user clicks on the button, the background color of the button turns green, but the text stays the same color?"

Basically prompting the person giving the requirements to explain how THEY envision it working.

Answer 3

My role has a lot of requirements gathering. The best way I find is a two pronged approach, talk through a PowerPoint presentation keeping it all simple and high level, and showing a Proof of Concept or a mock up. Walking and talking the customer through will see them responding with many "what if's" such as "Can I chance the colour?" this gives everyone a broad idea of what they are getting. If you can get something the users can touch and play with that works really well at uncovering the hidden what if.

Then, back this high level up with really detailed low level requirements. Spell out the dotted "i" and crossed "t". Get the users to read through and sign them before anything more than the POC is done. Generally word with a lot of screenshots works well.

Unless the users can bring you UML's and data flow charts, don't use them in anything the customer sees or signs. If it is signed by the customer and you had to regigg the back end to meet a "what if" you have to totally get everything resigned.

The final thing is to ensure that the customers can talk to you in their own words about their requirements and spell out what they are getting. One way to do this is to sit in on any middle management sell to higher management.

Don't try and bamboozle the customer, if they want something changed at the last minute, explain what the cost will be, in time and money, and ask them if this totally required. Doing this, will often stop people making trivial changes, and force them to think about why they want the change.

Requirements are getting what the customer needs from what they say they want.

Edit- To the point about showing screenshots early- this sometimes requires a good PM to let the customer know the time scales and where everything is at. If the PM helps to set some decent time frames and expectations, the customers won't get excited. The good thing of POC and screenshots is people get an image of what it could be like and can often work that inside their minds.

If you want to avoid screenshots do a wire-frame look or use a whiteboard and 20 mins of drawing. Just remember to save the whiteboard as a photo before you whipe it.

Whiteboarding (and the good old OHP) can be a godsend to requirements gathering- developing a good clear style of drawing concepts can save hours in workshops.

Answer 4

Flow charts tend to confuse some non-technical people (ie clients), as well as data flow diagrams. Use Cases are good and understandable, as well as Business Requirement and Technical Requirement documentation, possible some sort of rough wireframe sketches.

Answer 5

It really depends wich requirements you're talking about.

• Functionnal requirements? Maybe that UML is the rigth tool for. But I would prefer a test o test specifications
• GUI requirements? Nothing beats a paper and a pencil.
• Security requirements? By describing the limits of your security, you avoid unexpected deceptions.
• Reliability requirements? Both testing mechannism, and software/hardware backup/recovery plan.
• Other requirements: depends of your client.

But anyway, keep in mind, and explain to the client that requirement WILL change during the development phase and that it will always be a discussion and a compromise between cost and functionnality. Being honnest give more confidence to your customer.

Answer 6

I think that the best way to show that you really understand the client idea is to build prototypes.

By the way I was present in the last edition of the Requirements Engineering conference and in one of the workshops (MERE), Siemens was showing and interesting software based on composing a video of the client idea (it was for projects not limited to software) just to ensure that all the requirements are fully understood.

Any way, the thing is that some times a creative way to show them is better. Don't limit yourself to the standard diagrams.

Answer 7

I have had good experiences with creating a simple vocabulary, with terms from the domain and their meanings and relationships, and then go through it and make sure everybody agrees on everything.

Writing and discussing the vocabulary forces you to think, rather than just thinking that "we'll figure that out later".

It's no silver bullet, of course, and should be used along with other means such as a functional requirements specification and possibly a prototype.