This web application will be very simple. My goals lean more towards using the technologies of interest, namely, Google Web Toolkit + Spring MVC + Hibernate. Nonetheless, every project must start with a set of requirements.
Timetrak will be a multiuser application targeted at independent contractors that regularly participate in others' projects and desire to keep track of their tasks and hours spent doing project work. I'm one such software developer.
The application will support the following roles: an administrator, project supervisors, developers, and clients.
The administrator is charged with creating and managing user accounts, and resolving access/rights issues.
The project supervisor creates projects and assigns developers to the projects' tasks. He also sets the various hourly rates or contract terms for the project, and is responsible for inviting the project's client to participate. Supervisors also approve invoices posted by developers, at which point they are visible to clients.
The developer performs actions according to the tasks assigned to him, keeping track of hours worked. A developer can create new tasks in the projects he has access to (which will automatically be assigned to him). At any time, a developer can generate a bill for a particular project on completed tasks.
The client can review projects and see progress reports. Project details (such as task activity and which developer did what) are hidden from him. The client can review and pay invoices online, posted by managers.
Whenever a task gets some action, a daily email is sent to the client detailing what was done, and how long it took. If the client has multiple projects, only one email will be sent.
When a task is included on an invoice (billed), it cannot be modified. It can never be modified again after the invoice is paid, but can be activated again if the invoice is cancelled for whatever reason.
Tasks will have status that depict which development stages they are at: ready (not assigned to a developer), assigned (no actions done on task), in progress (some actions posted), and completed. Only completed tasks are billable.
I'm sure there are a lot more requirements that could be discussed, but the above are the crux of the project. It's cumbersome to try to adapt traditional SRS documents for a web application, and Agile methodologies will not provide the kind of documentation needed for a typical SRS, so the best strategy is to marry the two. I use a stripped down IEEE-recommended SRS with all kinds of web-specific sections depending on the project.
Write SRS's to focus on what the application will do only, who is involved, and the definition of the various entities you mention (for the benefit of the database developer). From this one document, system designers should have no questions about what to do. Even for web environments, you want to avoid discussing technologies in the requirements doc, unless the customer requires it (the document should be technology- and language- agnostic = a design or implementation decision). For this application, my SRS is only 11 pages long front-to-back - that's how simple it should be.
Typically, solicitation of information and clearing up ambiguities, and finally writing the document takes 2-3 days, depending on how quickly people are responding to emails or returning calls, or how often requirements meetings are held.
Requirements gathering is a billable activity: a lot of clients assume that you do it for free. I think that as long as they can use the specific information and your interpretation of their needs to develop a product, you should be paid for it. You may choose to charge a different rate - this activity is typically done by a consultant.
