What NEVER to forget when analyzing project requirements

What’s the first thing you get at the beginning of every software project?

The requirements.

A description of how the finished application needs to behave.

Then, you analyze them. And make a wild guess at how long it will take to deliver the completed app.

Those requirements are often called functional requirements.

But there is also another set of “invisible” requirements called non-functional requirements or architectural characteristics.

“Invisible” because they are rarely explicitly mentioned.

But you still need to define them. Why? Because they affect the overall user experience and operational sustainability of the system.

And ensure that the final product meets all expectations regarding performance, security, and other quality attributes.

There are numerous architectural characteristics (non-functional requirements) that can influence how your system is shaped.

But here are some most frequently used:

• Security- how secure the system is as a whole.
• Availability - what percentage of time does the system need to be online (e.g. 99.999%)
• Scalability - how well the system performs when the number of users increases.
• Performance - how fast is the system?
• Reliability - does the system need to be fail-safe? Is it mission-critical or impacts lives?
• Testability - how easy is to test the system.
• Deployability - how easy is to deploy the system.
• Modularity - how separated are components.

Now, how do you define which architectural characteristics your app architecture needs to have?

By analyzing requirements.

To make this as practical as possible, let’s analyze some requirements to come up with architectural characteristics.

“We expect a burst in website visits while the offline event takes place.”

• Architectural characteristic: Scalability - The system must be able to respond to a sharp increase in users visiting the site.

“We want to store the users’ credit card information.”

• Architectural characteristic: Security (with compliance implications, e.g., PCI DSS) - Sensitive information like credit card details must lead to increased security of the system.

“We need to release the app to market in 6 months. However, the budget is limited.”

• Architectural characteristic: Simplicity - If the project has time and money constraints, the architecture of the application should be as simple as possible to satisfy those constraints.

“Customers shouldn’t have to wait more than a second for their order details to load.”

• Architectural characteristic: Performance - It states how fast the system processes a request coming from a user.

​Even if you are not a software architect, here’s why it’s important to be aware of architectural characteristics:

• They directly impact the user experience and system performance, guiding your code to meet critical standards such as security, reliability, and efficiency.
• Understanding these requirements ensures the decisions you make align with the overall quality goals and sustainability of the project, leading to a more robust and user-friendly product.

If you want to make better software architectural decisions, my upcoming “Zero to Architect Playbook” course will be the right resource for you.

It contains a separate module, “Module 2: Identify the Right Non-Functional Requirements,” that focuses solely on analyzing non-functional requirements. If that’s a skill you would like to possess to be a more confident senior developer, join the newsletter and you’ll get updates on the course.

Have an amazing weekend.

Kristijan