In previous posts (here and here) I downplayed the importance of functional requirements (vs. quality attributes) on the architecture. Nevertheless, the functional requirements do have a 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. Let’s 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 talking 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 meet architectural decisions. When there are extreme/hard/important requirements, there are many times when 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. My decision 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 who followed me took 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 up this post
- Functional requirements manifest themselves as part of the utility tree (as the scenarios)
- It can also be important to view the architecture from a functional perspective.
- Significant/important functional requirements 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)
