1.10 Non-Functional Requirements

It is the IT architect or requirements engineer’s job to find implicit requirements on non-functional attributes (the non-functional requirements—NFRs). This can be very hard, since what is obvious or taken for granted by the customers or end users of a system is not always obvious to the designers and builders of the system. And do not forget the non-functional requirements that other stakeholders have, like the existence of service windows or monitoring capabilities, which are important requirements for systems managers.

It is important to remember that the acceptance of a system is largely dependent on the implemented non-functional requirements. A website can be very beautiful and functional, but if loading the site (performance, a non-functional requirement) takes 30 seconds, most customers are gone!

A large part of the budget for building an infrastructure is usually spent in fulfilling non-functional requirements that are not always clearly defined (“The system obviously must work seamlessly with the existing systems" or "The website should always be available”).

Most stakeholders have no clue how hard it can be to realize a certain non-functional requirement. It sometimes helps to quantify these requirements; to make them explicit: “How bad would it be if the website was not available for 5 minutes per day?” or “What if it will take $500,000 to implement this requirement? Is it still important then?”

Many of the non-functional attributes of an application are delivered by the infrastructure. An application using an IT infrastructure built with several single points of failure will probably not reach very high availability figures, no matter how well the application is built. And when the IT infrastructure is not designed to be scalable, the applications built upon it cannot introduce scalability as an afterthought.

The other way around is also true. When an IT infrastructure is setup to be highly available, a badly designed application can make the end result highly unreliable. Similarly, security flaws on the processes level can undo all security measures taken in the infrastructure.

This makes it very important to consider all design decisions when it comes to non-functional attributes.

It is not unusual to have conflicting non-functional requirements in a system. A classic example is security versus user friendliness. Users expect highly secured systems, but really don’t want to be bothered by password changes, smart card authentication, and other annoying security measures. The same goes for performance and cost. Getting a high-performance system usually means getting more and faster hardware, and using strict implementation rules. This leads to higher cost, which is usually not in line with some requirement about the cost of the infrastructure.

It is the infrastructure architect’s responsibility to balance these conflicting non-functional requirements. The architect must present the stakeholders with these conflicting requirements and their consequences, so they can make well informed decisions.

In the following chapters the three most important infrastructural non-functional attributes are discussed in more detail: availability, performance, and security. Each of these topics are too complex to fully explain in this book. Many good books and articles are written about them, some of which are recommended in the appendix. In this book, I only describe those aspects of availability, performance and security that are strongly related to IT infrastructures.