Customer Requirements.

[ahhah]

Is there a checklist or readily available methodology printed somewhere to help me capture all the customer requirements before developing code.  We're about to start something new and I want to make everyone happy and not have to re-do large sections of code.  ?

[smercurio_fc]

---

@ahhah wrote:

We're about to start something new and I want to make everyone happy and not have to re-do large sections of code.  ?

---

Yeah, good luck with that. If you manage to do it I'd suggest going into politics instead of software engineering.

There is no single checklist since software designs are so varied. Plus, the documentation can be affected by the methodology you use. There's lots of sources that you can find on the web. I would suggest looking over this: http://stackoverflow.com/questions/171653/examples-of-requirement-documents

[ahhah]

Thanks.  If you can starve your customers long enough, they'll be happy with much less than perfect.  

I'll check out your link. 

[Dennis_Knutson]

Are you planning on using the Requirements Gateway? It can interface to professional (and expensive) tools such as RequisitePro. You can also write your requirements in Word and use the tool.

[ahhah]

Are you planning on using the Requirements Gateway? It can interface to professional (and expensive) tools such as RequisitePro. You can also write your requirements in Word and use the tool.

No

[Yamaeda]

Ask alot, write alot, go into big and small details and more importantly feel, how it should work in general and concept!

When developing an application you often focus on the function and are happy when most things work. The customer will say: "It doesn't look like word. Why isn't there any autosave function. Where's the undo?" 

None of that was mentioned when you started as it wasn't part of "how do we test this product and write a report".  It would get caught be "how it should work" and concept (word-like).

Still, you'll miss 50% of what they mean.

/Y 

[Snippy_Mudpuppy]

Try to develop usage cases or scenarios. Also, concentrate on acceptance criteria. What will you have to do in order to get the customer to sign off on the software you produce. By concentrating on the exercise and testing that needs to go into acceptance many requirements will be revealed. The list that is developed will allow you to complete the project and still have the customer happy. Just be sure to document every detail.

Software does not break. It either has a feature that has been specified and tested or it doesn't. One big problem of software development is having the customer come back six months after delivery with a laundry list of unimplemented or broken (i.e. untested features). Have an agreement that the project is over after the acceptance testing is complete.

[ahhah]

Thanks very much!

[yenknip]

Modularise your project, prototype the modules - either partially working or fully working - and demo them to the customer. If they are not happy with something, then the looser coupling and tighter definition of modules will make for less work.