Solutions

Analyzing gaps in requirements documents

Business Problem

Correlate separate requirements documents and expose any gaps

The California Department of Justice (CalDOJ) was nearing the development phase of a multi-year project to migrate the legacy Automated Criminal History System (ACHS) off of a mainframe platform. Two separate sets of requirements documents were generated:

• System External Specifications (SES) were developed by the business stakeholders
• System Internal Specifications (SIS) were developed by the technical team maintaining the legacy application

Since the project was primarily deemed a platform migration, it was thought that the two sets of requirements would end up the same. It was also thought that having requirements developed from two separate perspectives would be a reasonable sanity check on such a large project.

Gap determination effort underestimated

It was thought that the effort needed to determine the gaps would be minor. Unfortunately, the two sets were not written using the same approach - one set was developed with pseudocode and the other was written with plain sentences and paragraphs. Furthermore, they did not have the same organizational structure, so information found in one section of one document needed to be cross-referenced in a completely different section in the other.

Solution

SES/SIS Mapping

Divide and Conquer

Since there were over 100 interfaces, with two documents per interface, a lot of documents had to be mapped in a short period of time.

Small teams were assembled to perform the analysis.

Pair Business and Technical Analysts

Each set of interface requirements had a technical version (pseudocode) and a business version (sentences/paragraphs). Because the two sets of documents were so different, it worked best to walk through a pair of documents with a small team of both business and technical analysts. Often the technical analysts would have to translate pseudocode into English, and the business analysts would have to explain the business process behind the sentences and paragraphs.

Raising issues

One thing that became apparent immediately was the fact that the two teams developing the requirements had a slightly different understanding of the project constraints. For example, the output from the query interfaces was known to be parsed by constituent agencies. While one team understood that altering the output could break constituent parsing routines, the other thought it would be a good idea to "clean up" some inconsistencies in the legacy formats.

These output differences had to be determined and altered to reflect the legacy formats.

CloverLeaf Added Value

As an independent third party well versed in software development, CloverLeaf was able to devise a sensible approach to analyze the documents within the allotted time and staffing constraints.

Benefits

• Requirements were aligned
• Issues were raised and addressed