Practical Use of the Zachman Framework For Organizing Information System Requirements ... Part 1 - Scope

I am doing some pre-project gathering of Requirements for an upcoming Feasibility Study to implement a new systems solution for my employer’s main process for delivery of its services to its customers. The scope and options of this study were drafted, debated and changed, until they basically aligned with my favourite phrase:

“Re-Use before Buy, Buy before Build, Build for Re-Use.”

Some even earlier pre-work to the Study has already identified several alternatives across the Re-Use and Buy options, so the study will evaluate two most ‘popular’ alternatives in order to select one as the recommended solution approach. It is possible, though not probable, that neither of these two alternatives will be recommended, after which we will move on to other identified alternatives.

So, here is what I have in terms of existing documentation to help me draft some Requirements before working with the business;(I hate a blank page as a starting point):

… Detailed Process Maps of the Business Process created by Process Pros in Six Sigma improvement projects.
… documentation on current systems (implemented before I joined the company), and my own experience on a couple of fix and enhancement projects on those systems.
… as an application, the main current system is somewhat unwieldy; I have been told it was developed based on an even earlier system without much user involvement, and was implemented before it was finished, not a great start.
… on the other hand the data model and physical database used by the application is very good, pretty much in 3NF that I can see; it was developed separately from the application, and the application is worse off because of this.; but the detail data requirements that will eventually be needed will be able to draw much from the current model and database, but this will be after the Feasibility Study.

The Feasibility Study will define high-level requirements, considered sufficient to evaluate alternatives. I have often seen such High-Level Requirements delivered as pages and pages of Requirement Statements: “the System/Solution must (do something, store something, etc.)”. The quality of a group of such statement can be very high, but the volume makes them hard to manage.

As a result I am going to use the Zachman Framework (www.zifa.com) as way of , having gathered Requirements in some form, to document them using various models/artifacts, and organize them by the rows/columns (“cells”) of the Framework. I have yet to decide if I will eventually extract a list of Requirement Statements from the artifacts, but it is quite possible I may need to so in order that a wide audience can review the Requirements without having to understand ER Models, for instance.

From a Business Analysts’ perspective, we are talking mainly about Row 2 for Requirements artifacts, what David C. Hay calls the Business Owner Viewpoint. However, if Row 1 (Scope) artifacts don’t yet exist for the business domain to be analyzed, it is best to create them for reference; the Row 1 content may already exist in various places and forms, but gathering and documenting in Row 1 is a good place to start the requirements activities for a project.

That is just how I started, to be continued...