Non-functional requirements

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: 

• Availability
• Scalability
• Reliability
• Stability

Besides these -abilities the following are also non-functional requirements:

• Cost/ licensing
• Security
• Uptime
• Robustness
• Documentation
• etc

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!

LEAP - Microsoft Lead Enterprise Architect Program

Tuesday 04 September 2007

This year I will attend the LEAP 2008: Microsoft Lead Enterprise Architect Program.

The purpose of LEAP is to extend the knowledge and insight of Microsoft's software portfolio for the business market of experienced and aspiring IT architects. Not only the most important Microsoft technologies are discussed, but also the relationship between the technologies and the business issues that they can address. Apart from technology available today, Microsoft's vision, mission, strategy and roadmap are part of the program.

LEAP is not an architecture program, but a program for IT architects. It is meant to extend the knowledge of architects with relevant knowledge of Microsoft technologies.

The LEAP-program consists of five masterclasses. Each masterclass zooms in into a business theme, and the technologies available to implement the theme.

The program is ended with a week's visit to the Microsoft campus in Redmond, Washington. There, the future roadmap and the architectural challenges are discussed with- and presented by Microsoft architects.

I am not a Microsoft expert. My roots are mainly in the UNIX world. Therefore, this seems like a good opportunity to gain knowledge on Microsoft technologies. These technologies are present at virtually all clients I work for.

The program starts in September with a one day workshop every month.

The Redmond visit will take place in January 2008.

Through this site I will publish my experiences in the program. Here is a link of someone who attended the LEAP previously.

I am looking forward to it!

UPDATE: Here is a post on how it went...