What is the difference between functional and nonfunctional requirements? Why do I need both?
Refer also to the question What are requirements types for details. Basically, functional requirements directly support the user requirements by describing the "processing" of the information or materials as inputs or outputs. Nonfunctional requirements generally support all users in that they describe the business standards and the business environment, as well as the overall user's experience (user attributes).
|Product features||Product properties|
|Describe the work that is done||Describe the character of the work|
|Describe the actions with which the work is concerned||Describe the experience of the user while doing the work|
|Characterized by verbs||Characterized by adjectives|
The functional requirements specify what the product must do. They relate to the actions that the product must carry out in order to satisfy the fundamental reasons for its existence. Think of the functional requirements as the business requirements. That is, if you speak with a user or one of the business people, they will describe the things that the product must do in order to complete some part of their work. Keep in mind that the requirements specification will become a contract of the product to be built. Thus the functional requirements must fully describe the actions that the intended product can perform. I also relate it to a product you might purchase at a store -- if you look at the bullet features list on the back of the box, it is describing the functionality of the product.
Nonfunctional requirements are the properties that your product must have. Think of these properties as the characteristics or qualities that make the product attractive, or usable, or fast, or reliable. These properties are not required because they are fundamental activities of the product -- activities such as computations, manipulating data, and so on -- but are there because the client wants the fundamental activities to perform in a certain manner. They are not part of the fundamental reason for the product's existence, but are needed to make the product perform in the desired manner.
Nonfunctional requirements do not alter the product's functionality. That is, the functional requirements remain the same no matter what properties you attach to them. The non-functional requirements add functionality to the product -- it takes some amount of pressing to make a product easy to use, or secure, or interactive. However the reason that this functionality is part of the product is to give it the desired characteristics. So you might think of the functional requirements as those that do the work, and the nonfunctional requirements as those that give character to the work.
Nonfunctional requirements make up a significant part of the specification. They are important as the client and user may well judge the product on its non-functional properties. Provided the product meets its required amount of functionality, the nonfunctional properties -- how usable, convenient, inviting and secure it is -- may be the difference between an accepted, well-liked product, and an unused one.
Let's take a look at another real example. Anyone who has purchased a car, whether they were aware of it or not, made their final decision based on which car met both their functional and nonfunctional needs. Functionally, the car had to be able to transport passengers from some starting location to a particular destination (that is, get me from point A to point B). A variety of nonfunctional attributes or characteristics were likely considered: security and safety, maintainability (ease of repair), reliability (probability of failure), scalability (ease of expansion), efficiency and performance (gas mileage, engine size, capacity -- both in number of passengers and cargo space), portability (ease of transport -- can it be towed easily or can it tow a trailer), flexibility (ease of change -- can it adapt to changes in weather/road conditions), and usability (ease of use -- comfort, handling, stereo sound quality).
This was first published in January 2008