Let’s continue our journey to make better technology decisions! We introduced the topic of technology guardrails, then we dug into technology guiding principles, the broadest of the technology guardrails. Now we are going to discuss a guardrail that provides more precise guidance: non-functional requirements.
Non-functional requirements are requirements that describe how a solution needs to be built, installed, or operated to work optimally in an organization's environment.
They wear many names:
They relate to system quality, including topics such as reliability, scalability, and supportability. They are the less-popular sibling of functional requirements, and are often invited late to the party and sometimes forgotten altogether.
Broadly, functional requirements define what a system is supposed to do and non-functional requirements define how a system is supposed to be.
Wikipedia
Functional requirements are specific to the user needs they are addressing, while non-functional requirements are specific to the environment in which the solution will operate.
All the benefits they provide. That's why! Once you create your initial set of non-functional requirements, you can use them to:
You can accelerate project delivery with a “canned” set of precise non-functional requirements. Business rules, functional requirements, and transitional requirements tend to be specific to the business problem you are trying to solve. However, non-functional requirements align more with the environment in which you will be operating your solution than the business problem, so they will mostly be the same for all projects. By creating a centralized list you avoid having to determine them for each initiative. Having that list shortens project delivery time, saves time for all the involved project stakeholders, and ensures consistency across projects. Not all non-functional requirements will apply to all projects, so some will need tweaking on a per-project basis, but this is less work than creating a new set every time.
With non-functional requirements, you can select better solutions that fit seamlessly into your technology environment. By including the correct requirements for how a solution must be built, installed, and operated, you can choose solutions that work best in your environment with your people. Once components are selected, non-functional requirements guide the implementation and integration of the solution. Ensuring that solutions fit seamlessly lowers both the initial cost and ongoing operating costs. It also reduces architecture risk!
Transformation means taking your organization from where it is now to its idealized future state. As I have mentioned before, since we live in a digital world where technology is a critical enabler, that journey will be paved with technology decisions. By aligning your non-functional requirements not only with your current technology situation but also with your aspirations, you can use them to guide your organization's transformation.
Non-functional requirements improve end-user experience and satisfaction by ensuring solutions fit the environment and integrate into the existing application landscape. While not as impactful as functional requirements, they impact user experience, especially those related to stability, performance, and seamless integration with other systems, which helps users avoid application juggling and manual data entry.
Having non-functional requirements available upfront during planning and vendor selection helps you avoid mid-implementation surprises. Many of them are not optional: they must be satisfied for the solution to run successfully in the target environment. If you identify those non-functional requirements up front, you can account for them in the planning and budgeting. Otherwise, they will arise later as scope changes. By that time, timelines and costs will have already been negotiated, with means these issues will cost more and extend the time to benefit realization when they eventually arise.
Non-functional requirements are the swiss army knife of technology guardrails. You can use them to fix problems all over the place!
The most obvious place to get value from non-functional requirements is on any project adding or changing technology components in your environment. The non-functional requirements can be used to scope, plan, and estimate the project, execute the right activities during implementation, and test compliance before promoting to your production environment. All of which avoids surprises and creates a solution that installs, builds, and operates well in your environment.
Non-functional requirements provide an excellent framework for evaluating existing technology components. We recommend weighting them by importance and using a simple scale of full, partial, and no compliance to score complaints. This results in a more objective assessment process. The one caveat is that those non-functional requirements typically don't provide comprehensive coverage, so they should not be the only quality measure employed. Your architecture review board or whatever other body you use to assess the technical approach for initiatives can also use the non-functional requirements to inform decisions.
Including functional requirements early in product selections and discussions with vendors ensures you don't waste time considering products that don't fit well in your environment or at least informs you early that you may have to ram a square peg into a round hole if you need a specific product.
Non-functional requirements are a mighty lever for solution design, especially the logical-level design performed by a solution architect. They make it much easier for the solution architect to identify when a design decision is not aligned with the organization's direction so that they can document it and request exception approval. As I mentioned above, since non-functional requirements don't provide comprehensive coverage, it won't capture all the issues that require discussion and approval but will accelerate identifying many.
Similar to how non-functional requirements enable better technology assessments and product selection, decision-makers can use them to evaluate options when making technology decisions beyond what product or component to use. These decisions can be broad ones about platform strategies or specific ones like how to integrate two components.
Most professional services contracts or statements of work define the scope and cost up front. That is when you negotiate and ink the deals! How sad to realize after the ink has dried that you need to expand the scope to get the solution implemented correctly in your environment. The time for negotiation has passed, so you are likely playing list rates and re-opening the delivery schedule for modification. Making sure that your non-functional requirements are in scope right from the get-go saves time and money.
If your organization is not already employing non-functional requirements as technology guardrails to drive better technology decisions, you should consider starting. Now that we have covered the basic value equation, we will be continuing next time when we discuss how you get started. In the meantime, if you think we can be of assistance helping you jump start, please contact us!
