It’s Not Overkill: Diving Deep to Get Requirements Right
By Peter Keers
Tuesday, April 07, 2009
OnApproach employs a two phase process in requirements gathering. First, there is the Discovery phase, a comprehensive sweep of all relevant requirements sources:
- Technical review – hardware, software,processes, and people
- Identify top level reporting requirements andreport owners
- Interview Report Owners and other Subject Matter Experts (SMEs)
- Document and validate all reporting requirementsinformation including tracing report elements back to their source tables
- Perform preliminary analysis of datarelationships
This objective of the Discovery phase is to gather initial requirements.
The second phase is Requirements. In this phase the requirements gathered in Discovery are expanded and enhanced.
This iterative requirements gathering process is intended to make sure data in the project is thoroughly understood. Comprehensive data knowledge by the Design and Development team is the number one success factor for completing the project as intended.
The Deep Dive
Despite the considerable amount of work undertaken in the Discovery phase, it is a mistake to avoid the “deep dive” of the Requirements phase. This phase results in critical enhancements to requirements already uncovered and frequently uncovers important new requirements.
In the Requirements phase several of the activities of the prior phase are repeated. Report Owners, SMEs, and other stakeholders are visited again to review in detail the Discovery documentation. Clarifications and amplifications by these individuals are encouraged in order to correct and refine the requirements.
At this point in the project meetings with larger groups of stakeholders may be necessary. Sometimes interviews with one or more SMEs are not adequate. Problem-solving meetings with a larger group may be the most effective way to answer tough,complex questions that have been raised in one-on-one discussions. Such meetings also serve to create consensus and keep the larger constituency within the organization aware of the progress and direction of the project.
Evolving Toward ETL
It is especially important that the Data Objects Analysis Matrix (DOAM) is reviewed in detail by the appropriate stakeholders. The DOAM documents each data element specified in existing or proposed reports and queries and traces them back to the tables from which they originate. Final validation of the DOAM is a clear indication that stakeholders agree that the requirements for the project have been properly captured.
The Requirements phase then takes the information from the DOAM and begins to develop the first draft of the Source-to-Target (STT) document. In the ETL process (Extract/Transform/Load), source data is extracted, transformed as necessary, and loaded into the target tables in the data warehouse. While the DOAM addresses some of the of the “T” issues in ETL, the process of evolving it into a Source-to-Target document focuses more specifically on how the source system data will be transformed (cleansing,calculations, aggregations). While the STT will be refined in the Design phase,a first pass at what will be the ETL roadmap is an important part of the final requirements.
Scope Changes
Sometimes new information is revealed in the Requirements phase of such a magnitude that scope is impacted. In these cases, a change order must be prepared and approved. Such changes can have a negative impact on the timeline if they are not handled effectively. There needs to be a mutually agreed upon change management process, quick identification and documentation of scope changes,and swift decision making on whether or not to approve a change.
Determining Cardinality
An additional document produced in the Requirement phase is the Cardinality Diagram. This document spells out the one-to-one, one-to-many, or many-to-many relationships in the data. Capturing knowledge of these relationships is central to understanding the underlying data. The Cardinality Diagram needs to be validated by the appropriate Subject Matter Experts since erroneous assumptions about cardinality will profoundly affect the effectiveness of the subsequent Design phase.
Preliminary Star Schema
As a precursor to the Design stage, a preliminary star schema is developed by the Data Architect. Under the heading of “floating a trial balloon”, a preliminary star schema gives the Design and Development team an idea of what the possible architecture might be for the final deliverable.This preliminary design is then used to create the final Requirements phase deliverable prototypes.
Creating Prototypes
In the Discovery phase, the Data Analyst tested sample source data for quality and to determine if basic data joins could be accomplished as expected. In order to finalize requirements, the Data Analyst and Data Architect build simple report prototypes. The objective of the prototypes is to further test the data todetermine if the requirements to be handed over to the Design and Development team truly reflect the needs of the project. Clients are especially interested in seeing a prototype since it not only provides them with a more “user-friendly” way to visualize requirements but it also creates a concrete sense that the project is progressing.
If the set of reports to be delivered is large, then a smaller set of reports that cover thewidest variety of data is selected for prototyping. Also, the prototyping tool does not need to be the same as the one to be used in the final deliverable. All that is required is a rough representation of how the final product might look.
It’s Not Overkill
Employing a two-phase process to gather requirements may seem like overkill, especially when project timelines are tight. However, our experience has shown if requirements are not sufficiently detailed and clear, a project has a much higher risk of exceeding its time and cost budget. Spending the time and effort up front to make the Deep Dive will greatly enhance the project’s prospects for success.
|
