When I was studying more deeply software architectures, I learned about the most important thing to consider in an architecture (after stakeholders), the non-functional requirements. Yes! Not the functional requirements, but the non-functional requirements.
Before I explain this more careful, let me say what “I” call requirements and non-requirements. (I will use requirements from now on, meaning functional requirements and the same applies for non-requirements)
Requirements are the features the final customer wants. Something like, I want an intranet portal where all the enterprise information is presented, where the users can consult news about the company and where the users can request material, etc. Preference, very detailed, the project manager and all the developers thank you for that.
Non-requirements are the “features”/attributes not related with the business, but very important, like performance, reliability, modifiability, security, auditing, transactional, availability, interoperability, testability, usability and others.
Sometimes people mix requirements with non-requirements, and sometimes they are right. If I want to build a race car, probably performance is a requirement.
The non-requirements are also called quality attributes because they give quality to the architecture. You can build an ugly/raw intranet portal with all the requirements in there. You will have all the information and all the requirements you requested to be implemented, but as soon you present the final product to the end users you will find why the non-requirements are so important. Probably you will call soon a designer to bring some quality to the web pages, Usability. Then you will start to hear some complaints about the performance, a user opens a page and all that information takes a long time to appear. It is time to for the non-requirement, Performance. The users they need important information available on the portal, to do their work along the day, so you will want Availability. The portal should access information available in other systems, and then again, Interoperability, and we can go on and on about this.
Why is this important, and really important? These non-requirements or quality attributes change the way something is built. They should be considered before the development, for many reasons: technical, time, resources and financial, to say at least. Technical, because the architect should consider them in the design and development process. Time, because it will take more time to implement them that just code the raw functionality. Resources, because you will need to consider people expert in some areas, like designers, integration, etc. Financial, as a consequence of the others.
For instance, for usability you should consider experts in that area, like designers. For security, one of the most intrusive quality attributes, you probably need an expert in that difficult area, or consider what blocks of code or modules should be protected and how. It can be a demanding task. For interoperability, you will have to consider what information to consume and provide, protocols, security, etc. If you work in financial software, you will surely want to test deeply the software, so the code and the architecture should be testable, the code will be organized for testability, and a lot of extra code will be implemented for testing purposes.
When you buy a house, the attributes you will take into your decision are more about quality than the living ones. If you follow only the living ones, any space with some blocks adjacent to each other will be enough for living! But, you will consider the access (security), how easy is to move around the house (usability), how strong are the house, like walls, material, etc. (reliability), and if the house is custom build for you, most of the time you will be speaking to the architect to consider this and that quality attribute, you will not be telling him that the house if just for living there, sleep, being and eat. You will want more, you will want quality, you will want a house based, above all, in non-requirements, responsible for making your expected requirements richer.
Curiously, the acceptance of any project, will be based on how the requirements were implemented served by the richness brought by the non-requirements. At least if you want a customer happy.
Without the non-requirements, the requirements will, paradoxically, not be “acceptable” by the final customer.