Software Architecture: The Matrix
Brent Arias

(updated Mar 20, 2006)

A principle concern of a software architect is delineating the scope of a system to be built.  To pin down that scope, the architect will need every technique or "device" in his bag of tricks.  And once that scope is established, the architect needs more such devices to aid his team in fulfilling the vision of that scope.  Here I will elaborate on one such significant device that can help with both of these needs. 

There is an identity relationship between the requirements of a project and the scope of a project.  Thus, any device that helps discern requirements is a device that helps define scope.  Architects, system analysts, and others involved with requirements elicitation often brain-storm categories of requirements to ask probing questions, such as "have we addressed requirements from the category of accessibility?"  Unfortunately, all too often the outline of categories is reinvented for each project despite the genericness of such categories.  Perhaps this is because industry defined and suggested categories, such as FURPS from the Rational Unified Process, are inadequate or insufficiently defined.

However, experience suggests that the problem does not necessarily stem from the uniqueness of any given project.  In other words, it should be possible to elaborate and standardize an outline of requirements categories to serve as an architect's device with readily repeatable or duplicatable benefits in requirements elicitation.  To this end I will suggest an outline that could potentially be used with  all projects as a solicitous device for defining scope.  And to foster acceptance of this outline, I will capitalize on the existing FURPS+ model and simply elaborate, comment, and extend it as follows:

• Functionality
  • The justification for the existance of a system
  • The solution to the primary problem or business need
  • Usually embodied by Use Cases
  • Interactions, validations, algorithms
  • Typically captured as use cases or business rules
• Usability
  • Human Factors Engineering - ergonomics
  • Look and Feel – platform or application standards
  • Accessibility - from where and how the system can be accessed
  • Interoperability - open architecture (e.g. Eclipse plugin?)
  • Connectivity - communication options (e.g. RS-232 networking?)
• Reliability
  • Accuracy - the correctness of output
  • Availability - meantime between failures
  • Recoverability - from partial system failures
  • Verifiability - (contractual) runtime reporting on system health
  • Survivability - continuous operations through disasters (earthquake, war, etc.)
• Performance
  • Efficiency - of space (bandwidth, RAM, etc)
  • Speed - time constraints
  • Scalability - well handling under increasing load
• Supportability
  • Maintainability (i.e. "build-time" issues)
    • Testability - at unit, integration, and system levels
    • Buildability - fast build times, simple build process, versioning robustness
    • Extensibility/Expandability - inexpensive to alter and does not break when changed
    • Portability - Minimal Vendor or platform dependency
    • Reusability - ease of isolating and transferring significant components
    • Internationalalization / Localization
  • Serviceability (i.e. "run-time" issues)
    • Continuity - administrative downtime constraints
    • Manageability – of fielded product
    • Configurability/Modifiability – of fielded product
    • Updateability - mode of distributing/installing updates
    • Deployability - mode of installation
    • Restorability – from archives
    • Logging - of debug data
• Security
  • Integrity Verification – seal of no tampering
  • Confidentiality Preservation – of data
  • Authorization/Access Permission – seal of proper user administration
  • Identity Verification – e.g. digital certificates
  • Authenticity Permission – e.g. logon paradigm
  • Availability of Service – seal of unblocked communication
  • Nonrepudiation Evidence – seal of proper origin or destination of data
  • Auditing Evidence – of sensitive operations

Whatever the tool for tracking requirements, whether a spreadsheet or RequisitePro, I suggest not requiring the analyst(s) to categorize beyond the main headings; a fine-grained categorization becomes too subjective and unacceptably slows requirements triage.  On the other hand, if a requirement seems to fit two main categories such that its placement is a coin-toss, this is probably because the requirement is overloaded.  Overloaded requirements are hard to test and difficult to cost, so steps should be taken to break it into two distinct requirements.  On the other hand, special accomodations for requirements of the Security category (particularly "Authenticity Permission") are usually needed, since typically they weave into functional requirements.  For example, logon steps are usually described in the use cases that are the domain of functional requirements.  Finally, care should be taken to distinguish between "ilities" that are formal requirements, and "ilities" that are architectural goals.  Requirements of the Supportability category often fall into this latter group and so probably should not be found in requirements documents.

So now the concern areas of a software architect, regarding the software itself, have been summarized in a handy outline.  But the value of this outline device increases when it is standardized across projects (or extended if necessary).  Assuming that costs are attached to requirements, patterns of development costs could now easily be assessed across projects in a relatively meaningful fashion - and thereby aid the costing estimates of future projects.  There would be cadveats of course since, for example, the security costs of PDA projects might always run lower than security costs of ASP.NET projects.  Ergo, the intersection of "FURPSSS" to "project type" produces a cost matrix that aids with estimates and resource planning for future related projects.

Another application of the FURPSSS outline would be for technology and product comparison reviews.  Imagine the benefit if articles that compared technologies, such as J2EE against .NET, would always use the above outline for product evaluations.  Furthermore, imagine having an online version of the "FURPSSS to Project Type" or "FURPSSS to technology type" matrix in which employees spontaneously contribute or insert comments.  For example, an employee might know that J2ME has a particular serious shortcoming in the area of performance - a shortcoming that is then briefly described and stored in a corporate accessible interface.  Granted, it is not necessary to have such a matrix if employees submit articles that are accessible with a search tool - but busy employees are likely more willing to write "matrix size" soundbites rather than full articles, and the matrix helps employees recall relevant factoids simply by its solicitous nature.

For collecting employee input, perhaps tapping the matrix is handled subtely through an appropriately configured trouble ticketing tool.  Or perhaps the matrix is given an express, high-profile web interface.  Either way, the organization that offers a cookbook of requirements categories has notably aided its software architects in making informed decisions to implement and fulfill the scope of a currently running project.  And since software architecture as a discipline is often too big to depend on the skills of a single individual or local team, perhaps one day "the matrix" could be offered on the Internet to permit architects across corporate and business sector boundaries to implicitly collaborate and share knowledge on the gamit of categories that constitute the architecture of a system.

If you feel there is a category or subcategory missing or poorly qualified from the above listing of "ilities," please send me a note suggesting the addition or alteration: panoply@att.net.

The copyright notice below applies to the reproduction of this article. The actual FURPS+ described herein, extended or otherwise, I do not copyright. Use or modify them freely.

Copyright © 2002-2003 Brent Arias. All Rights Reserved. Please read our Terms and Conditions.