Just confirming: The person that acts as a Software Architect should think in non-functional requirements (performance, scalability) in the first days of the project too. Doesn't it? I think that Software Architecture is like building architecture: we can't change the building structure in the middle or in the end of the project easily. I am not talking about Big Design Up Front. I am talking about the responsibilities of a Software Architect.

closed as unclear what you're asking by gnat, 8bittree, Thomas Owens Oct 14 '17 at 13:18

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Would you mind to say what kind of non-functional requirements? – Laiv Jul 26 '17 at 20:54
  • Performance, scalability – Alexandre Arcanjo de Queiroz Jul 26 '17 at 20:56
  • Is there a SLA? – Laiv Jul 26 '17 at 20:58
  • 2
    The purpose of software architecture is create possibility to make changes in minimum cost. – Fabio Jul 26 '17 at 20:59
  • No, there is not a formal SLA – Alexandre Arcanjo de Queiroz Jul 26 '17 at 21:02

Yes. Performance and scalability requirements may have a big impact on the overall architecture so should definitely be taken into consideration.

But be careful. Architectural decision for the sake of performance and scalability are sadly often based on superstition, and can seriously hamper a project. Like "Obviously we need a distributed NoSQL database, otherwise it won't scale!". In my experience, bad architectural decisions made for the sake of imagined performance gains is just as big a problem as the lack of performance considerations.

  • Define realistic and quantifiable requirements. Not just "as fast as possible".
  • Do not introduce a technology unless you have positive proof it will actually improve performance/scalability.
  • Do not introduce a technology unless you actually need it. Eg. a certain pattern might improve performance of a subsystem 10x - but if the area is not a bottleneck anyway the overall improvement might be negligible.
  • Always weigh performance benefit against cost in developer time and agility. E.g. a web app written in C++ will most likely be faster than one in Python, but will also be much more costly to develop and perhaps more significantly, will take more time to adapt to changing requirements.
  • Avoid micro-optimizations like the plague.
  • Plan in terms of what should be possible over time. I.e. you might not need say a distributed cache from the get-go, but you should design the architecture so don't preclude introducing a distributed cache at a later point. Here YAGNI enters the picture: If you design the overall architecture with a clear layering, separation of concerns and so on, such measures will be much easier to implement when necessary.
  • Thank you. This is a way more sensible answer than the accepted one. – T. Sar Jul 27 '17 at 13:52

I would say the non-functional requirements, performance, scalability, security, data protection etc are the key things a software architect should be thinking about on day 1

The customer isn't going to request them, the developers can probably handle any problems with the functional requirements without your help and if you leave these things until the end they can be a pain to put in.

The architect should be planning things out so the system will work well when its finished. not just work.

Thinking ahead and anticipating the hard problems beyond the simple 'it works on my machine' is what the job is about.

For example; in a meeting with the customer or PM, I would expect the architect to be leading on non functional requirements with questions like :

  • "how many peak users do we expect?"
  • "what user data do we need to store?"
  • "I suggest this security setup, are we happy with that?"

And really to have the answers ready before they ask.


Non-functional requirements should be elicited from the customer just like functional requirements are. All non-functional requirements should be represented in user stories or the system specification. In that way, the architect must consider the requirements (functional and non-functional) when architecting the system. It is not explicitly the software architect's role to elicit these requirements.

That said, often requirements are missed in elicitation (functional or non-functional), and probably non-functional requirements are missed more often. All stakeholders are responsible for voicing concerns about missed non-functional requirements. The architect may be more familiar of the common non-functional requirements, and the architect should make sure that the non-functional requirements for the system are not missed and that they are represented in the spec. The non-functional requirements will impact the project schedule just as much as the functional requirements will, so it's important to enumerate them and treat them with the same importance as functional requirements. The architect shouldn't architect for non-requirements.


It is interesting to read the variety of different answers here on the role of a Software Architect and how Software Architecture plays into the project. It just goes to show how many different schools of thought that actually exist on the concept.

System Quality Attributes

The typical "ilities" come to mind when discussing the concept of system qualities. They are the qualitative attributes about a system that an Architect strives to optimize to. These are inherently subjective and difficult to define. This also makes them difficult to test for as the outcome is not always perfectly clear. To make things even more complicated, optimizing for one quality may be a detriment to another quality, so often tradeoffs and rationale must be provided why we are deciding to architect for one over the other (Eg. Performance vs. Security). These fall in the larger category of Non-Functional Requirements.

Architecturally Significant Requirements

These are a subset of all Functional and Non Functional Requirements that have some kind of influence or affect on the architectural and design decisions of a system. Some of these requirements may also be Non-Functional Requirements derived from System Quality Attributes, others may be Functional Requirements derived from the business or Product Owner.

Calling these out in an Architecture is important for traceability of design decisions to requirements. An architecture is more than just describing a system from one or more viewpoints, but also a series of arguments and rationale provided for why certain decisions were made over others.

Who is Responsible for Non-Functional Requirements?

This is a burning question that enters many peoples minds and the answer may be different still depending on your organization, how you organize projects and whether you run in Waterfall or Agile methodologies.

The answer ultimately is that Non-Functional Requirements cannot come from a single stakeholder, however must be gathered and elicited from a number of different stakeholders, and then combined into a single document or backlog. For example:

NF1: The ABC service shall respond to requests in no longer than 5 seconds

NF2: The ABC service shall be synchronous and should not respond to or consume messages until a response is formed for the prior message.

In the two examples above, they may be derived from different sources. The first requirement may have come from the business. They are interfacing with a clearing house that has a strict SLA requirement on the network participants.

The second example is more of a technical detail but none the less defines some attributes of the system that must be followed. The specific design decisions for how this requirement can be fulfilled are left open, merely the requirement is described. This requirement may be realized by the Architect when considering system qualities regarding the Integrity of data in the system. Alternatively the Architect may realize attributes, constraints, and limitations of an interfacing system to where the architecture must account for and guard against. In that case perhaps the mandate for synchronicity comes down to a failure for messages to be properly transacted when interfacing with another backend system.

The business or customer may not have realized this requirement without the assistance of the Architect.

What Comes First? Architecture or Requirements?

Knowing that Functional Requirements are typically derived from the business or customer, and that Non-Functional Requirements may come from many sources, and considering that Architecturally Significant Requirements are important to defining the Architecture, it is clear that requirements, at least at a high level, are an important input to Application Architecture and Solution Design.


Non-functional requirements would not normally be at the forefront of my mind at the start of a new project, my focus would be on productivity and establishing a fast feedback loop, specifically:

  • Help the Product Owner figure out the quickest way to get fast initial customer feedback. The Product Owner might want to start with a mockup or prototype, or a this might mean defining a mininmal cut-down feature set for the initial version.
  • Start building the Ubiquitous Language and describe high-level concepts, so that everyone on the team can clearly communicate requirements.
  • Establish high-level architecutre so that everyone one the team is clear about how features will be implemented.
  • Work with Ops to build an automated deployment pipeline with any environmen(s) needed.

This is sometimes referred to as Sprint Zero. This isn't just the architects job - architecture should a responsibility shared with all developers on the team.

Its worth being aware of non-functional requirements (e.g. scalability, availability, security) at the start of a project, however they are really a secondary concern at this stage, with the main goal being to avoid "painting yourself into a corner". The primary value of software is the ability to quickly improve the software over time - if you are able to rapidly make changes then you can defer implementing non-functional requirements until the point at which they become valuable.

  • 1
    Non-functional requirements define how your high-level architecture will look. They are the difference between a monolithic desktop app and a distributed microservices platform. If put them to the background at the start of your project, you will end up failing on your design for the big picture architecture. – T. Sar Jul 27 '17 at 13:54
  • 1
    @T.Sar Building a Desktop vs Webapp is very much a functional requirement - non-functional requirements are things like encryption of data, resilience and DR process, performance and scalability. Your architecture needs to be able to accommodate changes to these requirements - baking these decisions into your architecture from the start means your only options are to over-engineer from the beginning, or at some point face not being able to handle increased load, customers with specific security requirements etc... – Justin Jul 27 '17 at 14:07
  • Desktop vs Webapp is a platform requisite, which is one of the textbook examples of non-functional requeriments. A functional requisite says "what" should be done, not "how". "Must run on a browser"/"Must be Linux-compatible" are non-func reqs as much as those you gave on your comment. And, well, yes - you should bake them on your architecture. What happens if you develop a very pretty WPF webapp, and them discovers that you should deploy it on a isolated linux workstation? Nah, I'm not buying it. Also, not every requirement is as easy to change as the others - – T. Sar Jul 27 '17 at 16:04
  • 1
    - You can't suddenly tackle "Must have real-time precision" or "Must log every user action" down the line. Requirement changes can, and should, be refused if their impact is too big. – T. Sar Jul 27 '17 at 16:09

For a software arcitect, functional requirements are just details. At the architectural level we are thinking in abstraction, and non-functional requirements become more important.

That's not to say that the architect doesn't pay attention to the details...they inform the overall design of the solution.

By focusing on and designing to the abstraction, it's certainly possible change out components at the detail level. Case in point, I once designed a system that used message queues to manage data flow, and months later had to switch to database tables due to a client having trouble with licensing. At the abstract level I was just moving data from one spot to another in the system, and whether that was by queue or by table was just an implementation detail.

  • Agreed. Non-functional requirements are as important as functional requirements from the customer expectations point of view. The system could be functional but insufficient if It doesn't performs as expected. So the earlier you care about these details, the better (for you and for the customer) – Laiv Jul 26 '17 at 21:29
  • 2
    I don't understand how this answers OP's question. What does your anecdote have to do with non-functional requirements? – Samuel Jul 26 '17 at 21:57
  • There were two parts to the question. The first was about thinking of non-functional requirements in the early days of the project, and I pointed out that they should be the driving requirements early on. They're going to move your design in one direction or another regardless of the functional requirements. The second was about changing design midway through a project...my point was (and the anecdote about) that if the architecture is done at a high enough level of abstraction you can change implementation details without significantly affecting the architecture. – PerryD Jul 26 '17 at 23:07
  • I think you were a bit unlucky with the downvotes due to bad phrasing. "just details" then backtrack with "they inform the overall design" – Ewan Jul 27 '17 at 12:03
  • 5
    "Functional requirements" are not "implementation details". They aren't things like what language or what database you would use. A functional requirement is what the hell the system is supposed to do. Storing cooking recipes. Scheduling appointments. Sending e-mails. Those things are the functional stuff. If you consider the main functionality of the software "just a detail", you have absolutely not a drop of an idea what you are doing. This answer is infuriating! – T. Sar Jul 27 '17 at 13:40

Not the answer you're looking for? Browse other questions tagged or ask your own question.