Requirements Checklist - An aid to writing requirements documents

I have been gathering some requirements recently and I have done this a few times but quite sporadically so when it comes to writing the document, I am often have the problem known as Blank Piece Of Paper Syndrome. What I usually do is read previous Requirements Documents but although this gives you an idea it doesn't always help you with the current Requirements Document you are writing because they are focused on different projects and different requirements.

So I decided I would write a document which I could use which would help ask the right questions to help me write a requirements document. So I came up with this Requirements Checklist. It is inspired by the Code Complete 2nd Edition but the list in there I didn't really find that useful to the projects I do but I did certainly steal a couple of ideas and then changed them.
Here's the checklist

Checklist: Requirements

• Limitations - Are there any known and agreed limitations of the application.
• Assumptions - list any assumptions that have been made regarding this project
• Unknown - are there any areas which might not work, any areas which a new technology or programming technique is being used.
• Prototypes - will there be any prototypes; proof of concept or screen layouts shown to the user before coding begins
• Servers - What is operating system is the server running and what is the setup going to be e.g. one server for the database, one server for the web server etc.
• Database - Is a database being used, whatÂ?s the flavour and the version
• Third party software - is there any third party software being used
• Technology used - what are the various types of technology, programming languages used in this project. Technology to consider Browser support, Database type and version, Java version, Application server, Web Server, Operating System.
• Data - Is there any data being used, what it is and where it is. Is it likely to change in the future?
• Error Handling. Is there any value validation to ensure the correct values are inputted before going forward or are any value put in and then an error is thrown later.
• Handling error messages Â? are the errors messages shown to the user or merely logged in the log file or is it both but with different messages. Is this an application wide specification or do certain parts of the application behave differently.
• Default values - Are there any areas where we specify default values and what should the default values be.
• Users- will there be different types of users, if so what are they.
• Security - is there any need for security and if so to what extent and where in the application. E.g. passwords, restrictions.
• Documentation - what level of documentation is needed for this project
• Configuration files - where are the main ones and what do they do.
• Input files - are there any files imported into the system. What information do they contain and what is the format. What is their source and frequency.
• Output files - Is anything outputted. Can this be in more than one format. What is the data being outputted. What is the output format(s), output destination and frequency.
• Future Change - What is likely to change in the future or is anything going to be added on. Is the architecture built with these changes in mind. Is this phase one of a project.
• Are all the tasks the user wants to perform specified?
• Is the expected response time, from the user's point of view, specified for all necessary operations?
• Is each requirement testable? Will it be possible for independent testing to determine whether each requirement has been satisfied?

On a completely different note, please checkout my new funny IT blog called Amusing IT Stories , it has an edition every friday and so far there has been one edition and the next installment is in two days time.