In previous posts (here  and here) it seems I downplayed the importance of functional requirements (vs. quality attributes) on the architecture. Nevertheless the functional requirements do have few  important roles in shaping/looking at  the architecture. One aspect of the functional requirements role was demonstrated in the scenarios that describe the instantiation of quality attributes within the system. Lets look at a couple of other aspects.

As I mentioned in a previous post no single structure is the architecture - this means that in order to present an architecture it is needed to describe it from several different angles or viewpoints (I'll spend some time taking about these in the next few posts on SAF). One of these has to do with the domain architecture for the solution. This can include identifying business areas trying to identify services (in an SOA), identifying major components for a component based architecture, or even identifying major use cases in a "use case view" (as part of a Unified Process 4+1 approach )

Listening to "Almost Cut My Hair" by Crosby, Stills & Nash, in the background kinds of brings me to the 3rd area where  I see functional requirements meets architectural decisions. When there are extreme/hard/important requirements there are many times where you have to decide whether to cut your hair and  bend the entire design to answer that requirement (i.e. make that a global decision - hence an architectural one) or satisfy it by a specialized local solution (i.e.  Postpone it to the design phase). For example, I once worked on a system where we identified one area of the solution that needs a (relatively) high update rate (low latency, high throughput for updates coming from an external system, processing it within the system and  all the way to the user's workstation window). While this was both predicted to be frequently used and an essential requirement for the success of the system the majority of the system's functionality did not have these characteristics. The decision I've made was to treat it as a local issue (to be given a specific solution @ design time). (Unfortunately ?) I moved to another company before the project ended, and the architect the followed me took the decision the opposite decision (i.e. to make the solution for that problem an architectural solution for all the system's "entities") - which resulted in making all the interactions within the system (even the simplest ones) asynchronous. I recently  had a chance to see the effects of this decision on the system's schedule, robustness and complexity, well let me just say that the lesson here is that while cutting your hair (making an architectural decision) is not an irreversible decision, you cannot just undo it instantly and it can take quite a long time (=money) to correct things.

To sum things up

• Functional requirements manifest themselves as part of the utility tree (as the scenarios),
• It can also be important to view the architecture from the functional perspective
• Significant/important functional requirement should be weighted for their influence on the system's architecture (should they get a local treatment (as part of the design) or affect the system globally)