Connecting customer requirements to the features and capabilities of the final solution through the system architecture is a key component of a successful project. However, the architecture more closely relates to the implementation than the requirements. (Hofmeister, Nord, & Soni, 2005) While some software architecture techniques, like use cases, focus on requirements more than the final solution; the tendency is for the architectural tools and approach to focus on the solution. (Hoffer, George, & Valacich, 2010) As Hofmeister, Nord, and Soni state, “although software architecture functions as a bridge between software requirements and detailed design, its concepts, languages, notations, and tools are much more closely related to those of detailed design and implementation than to those of requirements.” (Hofmeister et al., 2005) Hofmesiter, Nord, and Soni’s 2005 article, “Global Analysis: moving from software requirements specification to structural views of the software architecture,” reviews the development and usage of a technique called Global Analysis that, “serves to reduce the magnitude of the gap between requirements and architecture design.” (Hofmeister et al., 2005)
Hofmeister, Nord, and Soni begin their discussion with a review of the architectural challenges that motivated the development and a brief summary of the project work that led to the creation of the Global Analysis methods. In terms of the history of Global Analysis, the authors explain,
The development of Global Analysis began informally, during the architecture design of an image acquisition and processing system. Our goal was to make the architecture more flexible and evolvable, describe architecture design decisions along with their rationale, and communicate and manage their use. After the project was complete, we generalised our experience and began a more formal and rigorous description of the approach. (Hofmeister et al., 2005)
In describing the motivations behind the development of Global Analysis, Hofmeister, Nord, and Soni state,
This leaves documenting rationale and traceability a free-form task left to the architect, and the task is often overlooked. If instead the architect receives guidance and a model for capturing the results, this will improve his or her ability to document rationale and traceability. (Hofmeister et al., 2005)
While many architectural paradigms and methodologies generate artifacts that describe how to build and implement the final solution, few provide documentation of the design decisions and rationale. However, the design decisions and rationale are precisely the elements required to provide traceability between the requirements and the implementation.
Following the discussion of the problem background and the history of the development of Global Analysis, Hofmeister, Nord, and Soni provide a summary of the Global Analysis methodology. As the authors describe, there are two logical concepts behind Global Analysis,
The forces influencing the design are captured as a set of Factors. Because factors are not necessarily independent, architects rarely consider a single factor at a time but instead look at sets of related factors. The architect may also group a set of factors together because they contribute to some larger design problem, which we call an Issue. (Hofmeister et al., 2005)
In support of these logical concepts, Hofmeister et al describe several artifacts that may aid an architect to utilize Global Analysis, including a table for describing and tracking factors (factor table) and a template for documenting issues and their solutions (issue card). (Hofmeister et al., 2005)
With the background, history, and summary of Global Analysis complete, Hofmeister, Nord, and Soni proceed with the meat of the article – a review of the actual use of Global Analysis in four systems development projects as compared to the intended use. Based on the review of Global Analysis usage in the four projects analyzed by Hofmeister et al, several potential improvements to the methodology are presented. The authors find several aspects of the actual use of Global Analysis that enable refinement and improvement of the methodology, including a recommendation to parallelize the work to document factors and issues. Also, the challenges associated with managing large amounts of data related to issues and factors are observed as an ongoing problem area. (Hofmeister et al., 2005)
Hofmeister, Nord, and Soni’s 2005 article, “Global Analysis: moving from software requirements specification to structural views of the software architecture,” provides a qualitative investigation of the use of the Global Analysis methodology to improve traceability of requirements in the software architecture process. Hofmeister et al’s analysis of the findings provides several recommendations for improving Global Analysis. As Hofmeister, Nord, and Soni state,
Global Analysis provides a way of capturing what good architects are already doing and provides some insight into how to do it better. Global Analysis helps the architect make the conceptual leap from the requirements to architecture design by analysing the impact of requirements on important technical and business issues that affect design. (Hofmeister et al., 2005)
The Hofmeister, Nord, and Soni article provides a useful overview of the Global Analysis methodology. Software architects seeking to improve the traceability of the software development lifecycle would be advised to read Hofmeister et al and implement Global Analysis as an architectural tool.
Hoffer, J. A., George, J. F., & Valacich, J. S. (2010). Modern systems analysis and design (Sixth ed.). Upper Saddle River, NJ: Prentice Hall.
Hofmeister, C., Nord, R. L., & Soni, D. (2005). Global analysis: Moving from software requirements specification to structural views of the software architecture. IEE Proceedings — Software, 152(4), 187-197. doi:10.1049/ip-sen:20045052