Thursday 13 September 2007
Every system has requirements, that the system must comply to. Creating a list of these requirements for a new system is not a simple task. There are special applications on the market for documenting an correlating requirements for development- and test purposes.
Most requirements are functional requirements. They state what the system should do, like "After inserting a new customer order, the system must print a order confirmation".
Besides functional requirements, there are non-functional requirements. These requirements are sometimes called the "-abilities". Some examples of non-functional requirements are:
Besides these -abilities the following are also non-functional requirements:
- Cost/ licensing
Users of systems usually don not state these requirements explicitly, but they do have expectations about them.
It is the task of the IT architect or requirements engineer to find these implicit requirements. This can be very hard. Things that are obvious to the customers or end-users, are not always obvious to others. Not to forget the non-functional requirements that system administrators have, like the existence of backup windows.
A large part of the budget of building the system can be determined by non-functional requirements ("The system obviously must work seamlessly with the existing systems" or "The website should always be available"). Therefore it is very important to quantify these requirements to make them explicit: How bad would it be if the website was not available for 5 minutes per day?" What if it will take $500.000 to satisfy this requirement? Is it still important then?
It is important to remember that the acceptance of a system is largely dependent of the implemented non-functional requirements. A website can be very beautiful and functional, but if loading the site (a non-functional requirement) takes 30 seconds, your customers are gone!