what information to gather when starting a new project

[aztrix]

i would like to know what information you recommend i gather when starting a new contract/project.

i have previously concentrated on developing my own software, however i am getting increasing demand from other (non IT) companies to work on their existing databases and develop software for them. of course i want to look as professional as possible in the first consultation and collect as much useful information as possible without having to ring the next day and say "i forgot to ask you this and that"

your guidance is appreciated.

[Hack]

The first thing I like to do is sit down with the user and have them explain (hopefully in words in I understand) the business process that they want automated. Have them define the business rules they follow when they complete this task manually.

[mendhak]

Have them explain their requirements, pretend like you were coding right then as they were speaking and ask questions that you think may arise. Once you're satisfied with everything you have, ask them to freeze requirements.

[aztrix]

thanks guys this is very helpfull

[Hack]

Once you're satisfied with everything you have, ask them to freeze requirements.

You might as well ask them to waltz around the local park naked.

Freeze requirements is never going to happen.

aztrix: Once you have the requirements, you will actually wind up with two sets of requirements and you won't even know it.

Once set will be what you think they said to you.

The other set will be what they think they said to you.

The next step is for you to put everything you have in writing, and then go back to them and hand them the document you have prepared. Tell them that this is what you understand to be their requirements.

I will be willing to bet you that they will read this and say something along the lines of, "No, no, no....that isn't what I meant. I meant [insert new stuff here]"

[aztrix]

i thought as much Hack

[koolprasad2003]

first U need to relook all the SPM (Software Project Management) concepts.
and read the S/W eng. flow.
go through the software life cycle process..
Try with following sequence,
-Sysytem Analysis
-System Requirement
-Design of system
-Coding Part
-Testing Phase of system
-Implentation of system
- and finally Maintanance


if the concepts are clear then u got what u want
Best Luck

regards
koolprasad2003

[RobDog888]

Go over their task(s)
Get a list of software and version of any apps that your program will be working with on their network.
List out the functions of your app that you will be providing to meet the manual task(s).
Any additional information you will be providing like Help or documentation files.

Then list out your assumption/requirements and if any change, like say they upgrade their db server, then it will invalidate the quote and require extra hours to requote and redo if the code has already been written for that part.
This also protects you from them changing the requirements (after the quote is signed by them) or any other issues that may arise if they upgrade/change software or requirements. For ex. Say you have written code for CR 9 in you app because thats what they are using and then you find they upgraded to XI and it breaks your code. You will be protected since you listed out the app and version and allow you to charge extra hours for recoding to accomodate their change.

[aztrix]

very good advice robdog888,

this is an area that i have little experience in so i guess most of it will come in time. One thing i have learn t is that some clients really have no idea what they want either! I just have to make sense of their pipe dream ramblings

thats why i ask the question, so i can get the info i need and hit them straight to the point.

oh yeah, and for anyone else interested in this thread, make sure you ask what their expected budget is as they probably have no idea of the costs involved. i learn't by example. for all those people out their that want a complete inventory database, stock control, purchase order, financial software package created for $100 forget it!

[Hack]

Often users need a visual to help them with remembering what are little details to them, but often are critical to you.

Whipping together a "mock up" and giving them a run through demo helps with this.

[abhijit]

Gathering requirements is usually the hardest part of the job.

User's are fickle and its best to get some sort of document in writing so they understand what you have understood about the processes that they follow.

A prototype will generally help you do that. If you are building a new system, put mock up screens that the user will see in the system. This gives them an early lead on what you plan to carry out.

I have experienced situations where user expected a "Combo Box" but was given a text field. Then the user refused to sign off on the project.