The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

We've found it more productive and cost effective to just have the client sign off on each phase of a project...rather than spell out or try to predict up front all the specific requirements that will be needed for a site. Sure, we go into the project with the full understanding of the ultimate goal, but they aren't looking to us to teach them what is required to get what they are asking for. They hired us because we know what they don't.

One book I would suggest for project planning: "Getting Things Done" - David Allen. His premise is simple...concentrate on the "next thing" that needs to be done.

While this process you've described works well for smaller projects such as websites, it fails when it comes to multi-departmental software/application work where there numerous teams involved and many types of business processes and impacts. You can't just know the ultimate goal, you need to record all of the needs (both known and hidden) plus be aware of all the risks and how to mitigate those risks.

You have to do the research and requirements gathering up front or otherwise you end up with a failed project. Intense requirements gathering isn't static - you need to constantly go back and forth with new revisions - but it helps lay a solid groundwork on the really big stuff.

On one hand, there are those that don't document anything and get straight into code, there are others that cover absolutely everything in detail at the start. Both have their problems. The smaller the project, the less risk there is in not capturing requirements. In larger projects, the risk is increases dramatically.

However, develompent is not an exact science and often requirements, even if written well can change due to unknown or unforeseen circumstances which makes you wonder why you bother in the first place! This is where common sense has to prevail. The amount of detail put into the requirements will depend on the scale and nature of the project.

I am definitely in the latter group for the big projects. The small stuff I make sure to at least get a bare bones BRD/URD together. Requirements evolve yes, but that's why you have change documents :)

For small projects it might be expected that requirmnets define every little detail expected, but from experience working on a huge project that tackles new areas in the industry requirmnets become more or less a guidline for expecations and hence several intermediate steps are required from the date you finalize the requirments to the date you finalize your archetictire. These steps will help your clients (and yourself) understand what is needed in much more detail.
Several other session of progress and alignement should be executed while implemenation and prior to initial relaese.

Don't expect a big project to close nicely like small ones usually tend to do.

Worst case scenarios should be considered as well. What will happen if one of the parties quits or dies. Written contacts may not be enough to fix damages. Payments should be made gradually from the start date and continue after project is finished.

Most of requirements gathering articles that I read are for when you have a client. To be honest, most of my projects are not client driven, more organisational driven, if that makes sense. I.e. improve former software etc.
-Do you have any good ideas of how to make requirements gathering easier when no specific client exist.

This is a really good point. I find that internal projects often get treated different than commercial projects where a client is paying for the work and wants to see tangible results for their money.

The simply answer is to find a client. Or in your case, a project sponsor, ie. someone who will make the decisions for you. If there's no-one to do this, how can you assess if what you're doing is right or not? Ofcourse, finding that person might not be an easy task but there's often more than one way to get things done.

So, what you might need to do is write the requirements yourself. Literally make up what you think the organisation needs and then find someone to read it and hopefully approve it. I suggest this because often people won't give you details up front but they will give you feedback if they see something wrong. I find that there are even cases where a prototype has to be built to get people to pay attention when they won't read requirements (happens all the time).

A project sponsor, or what in our enterprise we call a Business Prime, is exactly what you need in cases like this.

Good suggestion also on writing your own requirements.

Writing requirements helps you as a developer (and an information architect) get a better grasp on what the real world needs of an application are - often developers think too much about the code and not enough on the business functions, processes and issues surrounding how the application could benefit or detract from everyday usage.

Start moving around the office, ask questions of appropriate personnel and gather feedback on how they do their work and what sorts of problems they encounter - this will help you realize and document opportunities. It also helps raise the profile of your work and your role in the company. This is especially important if you're looking to impress your superiors. Be polite and proactive - it can go a long way.

Thanks for your comments. I have now 2 sponsors that are willing to act as test-users. (both from different departments, and "head of departmetns") I have also started to make and write UML use-cases together with the head developer. I hope that this will give me the tip of the sword in the quest for a more user friendly/focused application without having a real client.

Thanks again

Mike

Visit my site: Site|Cosmos
Build Your own website that you can be proud of!

Client is usually not good (and not interested) at abstracting engineering details, so the communication is crucial. As Martin said, you want to accept the clients' terminology and use diagrams, pictures and such.

Another extremely usefull technique is to use static prototypes ("mockups" or "wireframes") of your application. Use the screens to resolve the requirement ambiguities and populate them with controversial data to deliberately provoke clients' response.

Web Project

Yes this web project job will need monitoring

I suggest to use the requirements tracability chart, where each requirements is track by a start, complete dates, done by which developer, problems, modules related to, testplans completed (you can add in more)