Classification of non functional requirements

Non functional requirements can be classified as:

  • Business Requirements
  • Strategic Requirements
  • Monetary Requirements
  • Time based Requirements
  • Technical Requirements

Now let's look at each of them in detail.

Business requirements and its influence on system architecture/design

Business Requirements are mostly for business systems and typically point to the Business Objective behind the existence of a behavior or a subsystem with in a system.

Can you think of any business system which is developed for charity or think about a behavior offered by a business system developed for charity.

I hope you will understand neither business systems nor their behaviors are developed for charity but are for satisfying different business objectives of the system.

Every business system and their behaviors are developed for satisfying different business objectives of the system.

Many times it so happens is that when a customer is giving the requirements, he gives you a lot of requirements that he doesn't need. But he gives it to you because you asked for requirements and actually even he doesn't know which should be given and which shouldn't be given.

I am sure you must have experienced this while gathering requirements from your customers. Those who haven't will see it very soon.

Now is there a way to find out which requirement is valid and which is invalid? Or can we find out what is it that the customer actually needs?

Business requirements are the only way which can help us sieve valid requirements from invalid requirements.

It is considered that "every behavior and a subsystem within a system should have a direct or indirect association to a business objective or a business stakeholder".

If the customer is unable to show the direct or indirect association to a business objective or a stakeholder, it means that either the customer himself doesn't know the value of the behavior/ subsystem OR the information has just crept within the requirements.

This is a very effective technique that can be used by analysts and architects to sieve away invalid requirements from valid requirements.

Business objectives are of two types:

  • Monetary Objective
  • Strategic Objective

Monetary Objective means there is a monetary expectation by the customer from the behavior/subsystem offered by the system.

Strategic objective means that the customer does not have any intentions to make monetary benefits from the associated functionality/behavior; but he wants a behavior/subsystem for strategic gains like increasing the customer base or beating the competition.

Strategic requirements and its influence on system architecture/design

Let's first discuss Strategic objectives and their influence on design and project plan of the system.

Can I say that Strategy is a function of Time?

OR

Can I have a strategy which is not time bound?

Many times in my training programs, my participants ask me that what have architectures/ Designs/ Planning got to do with business and strategic objectives of the customer?

Let me explain this to you with the help of an example.

I am a Customer and you are a Technology service provider. I want a system with 10 functionalities to be developed by you.

Out of the 10 functionalities to be developed by you, I say that functionality F5 is of Strategic importance to me and should be released in the fifth month of the project inception because my competitor will be launching some new features during that time and I want to offer something new as well.

This means that if you don't release the functionality F5 in the fifth month and release it in the 6th month, even if functionality F5 works properly it will be considered to be a failure by the customer because his business objective is not satisfied in this case.

Failure of a system does not necessarily mean technical failures. If it does not satisfy the business objective of the customer, it will be considered a failure as the very objective of the need is not met.

If we look at the industry statistics, the success rate of software systems is as low as 10%. This means 90% of the software systems are a failure. When I say that 90% systems fail, it doesn't mean that the system doesn't work or function improperly. Technically majority of the time the systems fail in meeting the business objective of the customer.

Software engineering is a stream of engineering wherein the estimations go haywire ateleast by 100% ranging to 300-400%. This in turn means all the estimation wrt various resources gets multiplied by a factor of 300.

If estimates are so skewed it is impossible to meet the strategic requirements of the customer. This probably highlights how strategic requirements are the most important reasons behind failure of systems.

Why the estimations in this industry are so off the mark is very interesting topic by itself which will be discussing separately.

If architects and project managers are not capturing the strategic requirements then no way they will be taking care of the same in their respective designs and project plans and the resultant systems will always result in a failure.

Understanding monetary requirements and their influence on system architecture/design

"Monetary requirements are those business requirements where the customer intends to generate money from the functionalities or from the subsystems within the system".

My participants ask me what does an Architect or Designer got anything to do with the money that the customer is able to generate using the functionalities or the cash flow of the customer.

Like in the case of strategic requirements again a lot of my participants asks me as to what an architect/designer has anything to do with money the customer is able to generate using the functionalities or the cash flow of the customer.

Let's take an example for it.

You are an entrepreneur and you want to launch a product in the market.

Will you include all the features in the first version of the product?

When I ask this question, my participants very quickly respond with 'NO' in unison.

And why will you not do it? Why will you not put all the features in the first release version?

When I say that you are in the process of launching the first version of your product, it indicates that most probably yours is a start up entrepreneurial venture.

Every functionality or a subsystem demands certain resources like money, manpower, time, efforts etc.

It would be an extremely ideal case if you have all the above resources needed to develop and support all the features in the first version of the product.

But even if you had the luxury of all the resources needed to develop all the functionalities, it would be an extremely foolish decision to release all of them at a time. We are in a highly competitive market and the moment we release all the features at one go, we will be dead in the next month with no features to compete with the ever competitive market.

Understanding Cost based requirements and its influence on system architecture/design.

"Cost is one of the monetary requirements which can single handedly change the Architecture/Design/Project implementation plan of the system, irrespective of whether the functional requirements are the same or different."

Every Functionality/Subsystem will hog certain set of resources and will have its associated cost.

Let us understand the same with an example.

Let's say Euro Rail, Canadian Rail and Indian Rail all want a passenger railway reservation system with nearly the same set of functional requirements for the system.

All of them have the same set of functional requirements, but Euro rail is willing to spend 10 million dollars for the same, Canadian rail is willing to spend 5 million dollars and Indian Railways is only willing to spend 50,000 dollars for the same.

The fact that each of them is willing to commit different amounts of money, will ensure that the system that we will deliver to Euro Rail will be different from the system that we will deliver to Canadian rail and from the system that we will deliver for Indian Railways. This is irrespective of the fact whether the functional requirements are the same or different.

The Design/Architecture/Project implementation plan for each of these systems can be or will be completely different.

This example gives us a very good idea about how cost can single handedly change the dynamics of the system.

You all know what CMM is? I am sure some of you must be working for CMM Level 5 Company. Most of the technology service providers are CMM Level 5 certified.

What do we understand by a company being CMM Level 5 certified?

CMM stands for Capability Maturity Model and when I say that a company is CMM Level 5 certified, it means that the Company has the capability of developing systems which are of a particular level of maturity or are capable of developing systems which are of a particular level of quality.

Different levels signify different levels of maturity or different levels of quality.

There are many Technology Service Providers who are CMM Level 5 certified. Because they are CMM Level 5 certified do you think that they always create high quality Software/System?

The answer is 'No' and the definition of CMM takes care of the same.

The definition of CMM strictly says that the company only has the CAPABILTY of developing systems of a particular level of quality but it doesn't guarantee that the company will always deliver high quality software/system.

Whether the company will deliver high quality system/software actually depends on the amount the customer is willing to spend for that particular system.

I will deliver high quality system if the customer is willing to pay the associated cost.

If CMM as a standard was forcing the companies to create high quality systems irrespective of what the customer was willing to pay, then the definition of the standard would have been flawed and it would have never worked.

I have come across a lot of customers who get trapped by the definition of CMM. They think that just because a company is CMM Level certified it means they will get a high quality system.

This shows how standards like CMM takes care of the fact that cost can single handedly decide the resultant system irrespective of the functional requirements of the system.

Understanding Time based requirements and its influence on system architecture/design

Every requirement that goes into describing a system is a function of time.

If I say I want a particular functionality and if I don't tell you the time at which the corresponding functionality is needed then the requirements are incomplete.

Similarly when I say I want a particular level of performance or a particular response time, I will also have to suggest the time when I need it.

This is true for Flexibility, Security, Scalability, Extensibility etc.

If we don't capture Time along with the related requirements then our requirements are incomplete.

Like cost, time is one non-functional requirement which can single handedly change the design/architecture and the project implementation plan of the system.

Let me take the same example of Euro rail, Canadian rail and Indian Railways. Since Euro rail is willing to invest 10 million dollars, they also tell us that since they are pumping in huge money for this system, they want this entire system to be up and running within one year, Canadian rail is fine with three years and Indian Railways if OK with 6 years.

Given the different requirements wrt time, for us to deliver the entire system within one year, we will have to design our system and the project plan for Parallelism. This means we should be able to design the system in such a way so that multiple developers can start developing different functionalities in parallel. Similarly the front end and back end should be developed in parallel and the development and testing should happen in parallel as well.

Now if as a designer/architect I don't design the system for parallel development and if the manager doesn't design your project plan for parallelism then we cannot deliver the system to the customer at the right time.

Time and Cost are two non functional requirements that can single handedly decide the Design/Architecture/Project Plan of the system.

 
Hemant Jha
Founder - VPlanSolutions
Researcher, Trainer

www.VPlanSolutions.co.in