Architecture-First Functional and Non-Functional Requirements
Architecture-First Functional and Non-Functional Requirements
Overview
Requirements are important. Without requirements a project team doesn't know what to build. It is necessary to help the project team determine how to create the desired application.
Requirements always exist, but they are in the mind of the stakeholders. The challenge is to extract those requirements. They are difficult to discover. Some users only know their part of the application and from their point of view. The requirements gathered from them may describe what they are doing now, but not what they need.
Unfortunately, the users are busy and generally only offer responses to questions since they have to focus on their current job responsibilities. Therefore, the quality of the requirements is a factor of the questions asked. If a question is not asked the item won't be addressed during the application build and will cause problems if discovered late in the project.
Previous Documentation
Random questions asked will end up with requirements as bullet points that cover only a part of the application. The alternative is to acquire and read a large document representing the current application. While this is good in some sense, it only describes the current system and not the desired new one. It is like describing specs for your current old car in order to buy a new car. You will end up with something similar to your old car.
The document of the current system may be too detailed to comprehend or may miss parts of the system added after the initial build. In this case, the documentation will not be enough to build the application.
Solutions Instead of Requirements
There is also a case where what appears to be a requirement is actually a solution masquerading as a requirement. For instance, there may be a requirement:
Users should be able to page through a number of products to find what they are looking for without timing out.
This requirement implies that the system has a paging screen where users will page though hundreds or thousands of products. In an e-commerce retail application, this requirement produces a terrible experience and can actually lead to a loss of sales. What the user really needs is the following translated requirement in better form.
Users should be able search for products based on criteria to find what they are looking for.
If the system is built with the wording of the former requirements the users will realize the mistake as late as UAT. That will be very costly. Unfortunately if not careful, the real requirements can come as the system is being built and may require difficult changes.
The Wrong Application
The worst thing you can do is to build the wrong application. This can happen if the requirements are not complete or are solutions masquerading as requirements. As in the previous solution as a requirement example, all the code related to the paging solution is wasted effort, time and money. QA ends up testing code that should not have been written at all.
There are two significant types of requirements: Functional and Non-Functional Requirements. Identifying these requirements is the key to building a good and cost-efficient application.
Functional Requirements
Functional Requirements describe the behavior of the system. They contain the requirements related to business-related features. For instance, the following is a Functional Requirement
Users should be able to track their orders.
These requirements are often gathered during user sessions where the information is recorded based on questions. The key participants in this process are the BAs and Subject Matter Experts (SMEs).
As discussed earlier, it is important that the requirements do not contain solutions. The solution portion of the project is done after the requirements are analyzed.
In the Architect-First approach, it is recommended to create Use Cases to mentally exercise these requirements before coding. The Functional Requirements lead to the Business Architecture. It is an essential part of the project and is considered an upstream activity as opposed to the downstream activity of coding.
Non-Functional Requirements
A set of buildings
Non-Functional Requirements represent technical features of the application. They are often represented as sizes or durations. They often pertain to the '-itys'
Examples of Non-Functional Requirement categories are
Performance
Security
Availability
Capacity
Compatibility
Scalability
Regulatory
A Non-Functional Requirement may be written like the following
The application should be written to handle more than 20,000 concurrent users.
The application should respond to user requests within 5 seconds.
The Non-Functional Requirements lead to the Technical Architecture. The Architect role is important here, because the Architect will primarily derive the Technical Architecture from the Non-Functional Requirements.
Following, are examples of how Non-Functional Requirements greatly affect the end product and project planning. They are essentially examples of small, medium and large applications.
Single Family Home
Small Single Family Home
A small single family home takes ingenuity and effort to build, but is the easiest of the three projects. Among others, it has the following attributes:
minimal complexity
standard pipes and wiring
standard weight-bearing structure
low roof
do it yourself modifications capability
shorter to build
fewer people involved
A project of this size has more room for error and supports more successful workarounds. The end user will see the results sooner and it is less difficult to make modifications near the end of the project.
An analogous application may have few users and only require a single server to host the process.
Two Family Home
Two Family Home
A two family home takes more effort to build and requires a larger stable land base than the single family home.
Among others, compared to the single family home has the following attributes:
moderate complexity
potentially double the piping and wiring
larger and more complicated weight-bearing structure
high roof
double kitchens
more powerful HVAC
need specialists for modifications
longer to build
more people involved
The project plan for this endeavor is larger and requires more resources. There is more surface area for mistakes. Those mistakes are more painful to fix.
An analogous application might require multiple servers and communicate with external processes with a higher volume of data.
Townhouse
Townhouse
A large townhouse is significantly more difficult to build than the other two examples. There even needs to be a plan to successfully get items to the higher floors in order to finish the building.
Among others, a townhouse has the following features:
high complexity
significantly different piping and wiring
highly complicated weight-bearing structure
very high roof
multiple kitchens
industrial strength HVAC network
need specialists for all modifications
has so many parts needed that a location is needed to store materials
multiple deliveries
large number of people involved with coordination
This requires the most complex and elaborate project plan. A problem, such as feature misalignment or miscalculation of required power becomes a huge problem. Certain mistakes are devastating. Miscalculation on structural issues could cause the building to collapse.
An analogous application may be an e-commerce application with thousands of customers and products requiring multiple servers with high throughput. This application would also communicate with external processes with an extremely large volume of data.
Summing up
Requirements are way to describe the system. Without them it is highly unlikely to build an application that meets the users' needs.
Properly identifying the Functional and Non-Functional Requirements is very important. If the Functional Requirements are missed then the project team will build the wrong application. If the Non-Functional Requirements are missed then it is possible to build an application that fails in production under load.
If an application needing the "Single Family Home" (small) solution is instead built with the "Townhouse" (large) solution it is more expensive than necessary and will have failures running unnecessary code.
More devastating, is if an application needing the "Townhouse" (large) solution is instead built with the "Single Family Home" (small) solution because it will not perform properly and fail when heavily used. A failure under load is one the worst things that can happen. It is when the product is doing the most important work or hosting the most users. There is a potential to drive many customers away.
A project that starts off with a "Single Family Home" (small) solution is often a mistake where the intention is to eventually build up to the "Townhouse" (large) solution. It is often difficult if not impossible to retrofit the small solution into the large solution. It is important to understand the entire vision before determining if it is a small, medium or large application.
The Architecture-First approach is focused on identifying and building the proper level of application. The application of Use Cases greatly help with this.
Further reading
Attributions
House drawings from unDraw.