Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Usually a scenario like this is caused by 2 things. The ones that are supposed to give you the requirement specifications are either don't put their hearts into the project because they have no interest in it, or because they really have no idea what they want.</p> <p>Agile programming is one of the best ways, but there are other ways to do this. Personally I usually use a classic waterfall method, so spiral and agile methods are out of the questions. But this doesn't mean that you <strong>can't</strong> use prototypes.</p> <p>As a matter of fact, using a prototype would probably be the most helpful tool to use. <a href="http://www.joelonsoftware.com/articles/fog0000000356.html" rel="nofollow noreferrer">Think about the iceberg effect.</a> <a href="http://img134.imageshack.us/my.php?image=icebergbelowwater.jpg" rel="nofollow noreferrer">The secret is that People Who Aren&#39;t Programmers Do Not Understand This. http://img134.imageshack.us/my.php?image=icebergbelowwater.jpg</a></p> <blockquote> <p>"You know how an iceberg is 90% underwater? Well, most software is like that too -- there's a pretty user interface that takes about 10% of the work, and then 90% of the programming work is under the covers...." - Joel Spolsky</p> </blockquote> <p>Generating the prototype takes time and effort but it is the most effective way to gather requirements. What my project team did was, the UI designer was the one that made the prototypes. If you give the users a prototype (at least a working interface of what the application is going to look and feel like) then you will get lots of criticism which can lead to desires and requirements. It can look like comments on YouTube but it's a start.</p> <p>Second issue:</p> <blockquote> <p>The customer casually mentions after a quick glance that they want it changed. They have no understanding of all the usability / consistency issues you were trying to avoid in your very carefully thought out approach.</p> </blockquote> <p>Generate another prototype. The key here are results that the users would like to <em>see</em> instead of advice that they have to <em>listen</em> to.</p> <p>But if all else fails you can always list the pros and cons of why you implemented the solution, whether or not the particular solution they like is not the one you insisted on. Make that part of the documentation as readable as possible. For example:</p> <p>Problem:</p> <p>The park is where all the good looking women jog to stay in shape. Johnny Bravo loves enjoying "mother nature's beauty", so he's lookin to blend in... you know... lookin all buff and do a little jogging while chasing tail.</p> <p>Alternative Solutions:</p> <p>1) Put on black suede shoes to look as stylish as you can.</p> <p>2) Put on a pair of Nike's. Essential shoes for running. Try the latest styles.</p> <p>Implemented Solution:</p> <p>Black suede shoes were top choice because... well because hot mommies dig black suede shoes.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload