Hi aussie_tn

The standard would be to use MySQL as the database engine with PHP as the server-side programming language. This environment is by far the most commonly used one, in fact the combination of LINUX, Apache (web server), MySQL and PHP is commonly referred to as a "LAMP" server.

I work on the receiving end of this type of transaction - I'm a programmer and online application developer, so I can tell you what I would need to see to get an accurate idea of what you wanted so I could make a bid:

1 - I'd want to know what the business model is - what do you need your database or application to do? Not "it needs to have a grid and two buttons" - thats the interface design. I'd want to know what function or service the application is expected to perform. Something like "it will let everyone on my softball team track their performance" is more like it.

2 - On the same note, a flowchart of how you envision visitors using your site. A real flowchart diagram works best for me but you can also do a step-by-step document that illustrates how a visitor moves through your application. Like "step 1, visitor logs in; step 2, visitor selects his/her name from a list of players... etc etc).

3 -What features do you want to provide your visitor? Can they search for things, can they edit things? Can they download or update things, and if so what and in what format? In the softball example you might want a performance report to be available.

4 - For a database project a list of fields that you see being required. The softball team example might have Players Name, Position, Batting Average, Home Runs etc.

5 - Are there any pre-existing requirement that the developer will need to cater to? Is there an existing database that must be interfaced to, or an existing web site that he application needs to be integrated with?

6 - The timeframe for the deliverables, project milestones.

I know it's not a formatted list, I actually wouldn't mind standardizing one myself one day so I'd be interested to see what other responses your thread gets.


Best of luck with your project, let me know if I can be of any assistance.

Bill

If it's the wording of your specifications that you're after, one approach that I think would work is to read up on the feature lists of existing software and see how these are composed. Most of them would have descriptions of 'human friendly' features. Looking at the feature list of Wordpress itself here:

wordpress.org/about/features/
(Add http colon slash slash to the above line. Sorry, I can't post links yet this posting thing says so.)

I see very few techie details, and I find that the listed features (specifications) are very clear and succint.

Maybe try going through user manuals or other user-oriented software documentation (as opposed to programmer oriented documentation) and you might find ideas there too. Lots of open source software out there with good documentation.

Hope that helps.

Well, were I bidding on a database project, I'd want to know in fairly good detail what is wanted.

Personally, I look at:
1) What is the high level functionality you want?

For example, to use mywebworks example:
a) What kind of performance are you looking to track?
b) Would you want performance by inning? game? season? shorter or longer periods?
c) What kind of reports would you want for performance?
d) What kind of non-performance related data would you want to track? Player level data? Team level data? League level data? etc.
e) Would this be for one person to manage or many? And would you want a changelog stored in the database noting any updates, additions, and deletions as well as who made them?
f) Is there anything else at all that you would want the system to be able to do?

2) What are the core actions that end users would need to be able to carry out?
e.g...
a) View their own stats by time period
b) View their teams stats, etc.

3) What are the core actions that administrators would need to be able to carry out?
a) adding players?
b) adding teams?
etc.

When dealing with databases, I prefer to know in as much detail as possible what functionality is wanted and what kinds of data should be involved.

With those two things, creating a solid database that will handle everything wanted is fairly easy...

As someone looking to hire such work done, I'd caution that you might want to be sure and spell out all of the functionality you want and give it some thought...some database programmers will stick to letter of the deal and you might well find yourself with something that does exactly what you state but is not at all what you were looking for.

From a buyer standpoint, I would focus on describing:
1) The types of data you want tracked with specific details where possible ( players, teams, etc ).
2) The actions that should be available to end users ( view something, sort things, etc )
3) The actions that should be available to the administrator, if any ( add things, edit things, delete things, view reports, etc. )

[DELETED]