Non Functional Requirements are People too!
I started writing this blog in order to explain what software engineering is. I have noticed that most people use the words "software engineer" to describe a person who is basically a programmer. Unfortunately, that is a misguided definition of software engineer. I have attempted to clear that fog in my previous post. However, no matter what definition is used, what is it that we really need? A software engineer or a programmer?
This post, however, will take a tangent into one aspect of Software Engineering: Requirements Engineering. You can learn more about requirements engineering here - http://en.wikipedia.org/wiki/Requirements_engineering
Requirements can be divided into two broad categories: functional and non-functional. Functional requirements are those details which form the basis of the software being built. This consists of the main reasons why the particular product is being developed. As an example, one of the functional requirements of the Amazon Kindle reader is to open e-books. Another one would be to display the pages in the book.
Non functional requirements are those properties required from the software product which the functional requirements to execute smoothly. These do not form the core requirements of the product but are essential to the performance. With the example of the Kindle, we can say that displaying the pages at different resolutions clearly is a non-functional requirement.
If we can recall the chart from my previous post, functional and non-functional requirements can be mapped as verticals and horizontals respectively. This is a similar diagram for an e-book reader:
I have observed this general notion: People automatically assume "Non-Functional Requirements" as "Non Requirements". We conveniently drop the word "functional" and treat NFRs (Non-Functional Requirements) as trivial elements.
These do not affect the business logic of the software directly. These do not form the core functionality of the application. So, we assume them to be unimportant. DANGEROUS!
I would like to emphasize that NFRs are very important to the system being developed. In fact, in some cases, they are more important than the functional requirements themselves.
Consider a banking application. If we do not provide adequate security, citing that security is non-functional, we might as well go bankrupt. Many argue that in this case, security is a functional requirement. However, I maintain that the main requirements from the bank are to store one's monetary assets and enable transactions on those assets. Having them do that securely is an extremely important, yet non-functional requirement.
I think that I have repeated myself enough on this. However, I would like to summarize that the importance of the requirement is not evident from the categories of functional or non-functional. This depends upon the nature of the product and the priorities set by the software engineer. Security is generally an important requirement from most products (esp. on the internet). However, security is a non-functional requirement in most cases.
NFRs are people too!
This post, however, will take a tangent into one aspect of Software Engineering: Requirements Engineering. You can learn more about requirements engineering here - http://en.wikipedia.org/wiki/Requirements_engineering
Requirements can be divided into two broad categories: functional and non-functional. Functional requirements are those details which form the basis of the software being built. This consists of the main reasons why the particular product is being developed. As an example, one of the functional requirements of the Amazon Kindle reader is to open e-books. Another one would be to display the pages in the book.
Non functional requirements are those properties required from the software product which the functional requirements to execute smoothly. These do not form the core requirements of the product but are essential to the performance. With the example of the Kindle, we can say that displaying the pages at different resolutions clearly is a non-functional requirement.
If we can recall the chart from my previous post, functional and non-functional requirements can be mapped as verticals and horizontals respectively. This is a similar diagram for an e-book reader:
I have observed this general notion: People automatically assume "Non-Functional Requirements" as "Non Requirements". We conveniently drop the word "functional" and treat NFRs (Non-Functional Requirements) as trivial elements.
These do not affect the business logic of the software directly. These do not form the core functionality of the application. So, we assume them to be unimportant. DANGEROUS!
I would like to emphasize that NFRs are very important to the system being developed. In fact, in some cases, they are more important than the functional requirements themselves.
Consider a banking application. If we do not provide adequate security, citing that security is non-functional, we might as well go bankrupt. Many argue that in this case, security is a functional requirement. However, I maintain that the main requirements from the bank are to store one's monetary assets and enable transactions on those assets. Having them do that securely is an extremely important, yet non-functional requirement.
I think that I have repeated myself enough on this. However, I would like to summarize that the importance of the requirement is not evident from the categories of functional or non-functional. This depends upon the nature of the product and the priorities set by the software engineer. Security is generally an important requirement from most products (esp. on the internet). However, security is a non-functional requirement in most cases.
NFRs are people too!
Comments
Post a Comment