|
Focus on Features
The biggest trap with requirements is to dive into too many details.
This is the place to list features you require without getting into how
to build them. You don't want to write anything down
that will limit creative thinking on the project. If you say, "We
want a content management application (CMA) built in ASP.NET," that
is exactly what you will get. Instead, say, "We need the
ability to securely update content from remote locations," which leaves room for less expensive solutions.
The functional requirements document describes the way your project
will behave. Will your web site require registration? Will your
application have user rights management? Who will use your project? What
will they want to be able to do? What action do you want them to take?
You're trying to think of everything.
In the technical requirements, you list all the technical limitations
and preferences for the project. If you're an Oracle house and database
compatibility is critical, then document that. If you need a shopping
cart solution that integrates with your existing SKU management system,
then document that. Just remember that you don't have to get into the
steps yet.
The benefit of thinking only about what you require the web project
to do is that you naturally begin to prioritize those requirements. You
see how different features may work together, and you can easily start
to define logical phases for development.
|
