Wave of Technology
Whether you’ve heard it compared to a bus line or an ocean wave, new tools and processes are always changing the way organizations operate. With these tools always coming out and new developments being made everyday, it can be easy to get lost in new technologies. It’s easy to “ride the wave” or “hop on the bus,” but deciding which requirements to use when switching is the more interesting question I plan to answer in this post.
Functional and Non-Functional Requirements
It’s common to look at the functional and the non-functional requirements when making a software change or upgrade within your organization. These two types of requirements form the foundations to making decisions about new systems and both should be considered when making any changes or introductions into the organization’s software systems. As a quick reminder, functional requirements are those that are related to the technical functionality of the system and non-functional requirements are those that judge the operations of the system as opposed to its behavior.
Boiling functional requirements down to the bare basics, they are described as the mandatory parts of the system that describe a function of the system. Essentially they take inputs and give the proper outputs. Functional requirements are easy to describe and can be modified to fit systems based on user feedback. They are often more clear cut when compared to non-functional requirements.
The functional requirements should be taken into account, but they play a smaller role on some of the architecture choices that can be made about a system.
Non-functional requirements are often the non mandatory attributes of the system, most often considered to be the properties. They are often hard to capture because they are unseen and don’t play a functional role in the system. This doesn’t mean they aren’t important. THEY ARE!
The non-functional requirements that come to mind within the scope of IT Operations include security, efficiency, and reliability. Although these requirements seem simple capture, they can become very complex very quickly. Ensuring a system is secure using the CIA triad (confidentiality, integrity, and availability) can be time consuming and seen as a waste of time for systems that don’t appear to need security. The same can be said for efficiency and reliability as it’s hard to measure these when you don’t have to meet related objectives for these metrics.
The non-functional parts of any system should be heavily considered when making an upgrade or a software switch as they can make or break the maintenance costs of the future.
While the functional requirements of any system must be considered, there is no reason to merely glance over the non-functional requirements. The non-functional requirements are just as important as the functional requirements when considering changes to any system. Long term plans must be considered when making software changes, and all options should be reviewed before making a switch. Documenting changes and how decisions were made is also critical for making better decisions in the future.