Successful EDM Implementation:

Requirements Analysis

by Rainer Hoff, Ph.D., P.Eng.

September 1998

© 1998, Gateway Consulting Group, Inc.

Introduction

This is part 5 in a series about successful EDM implementation. Part 1 and the methodology diagram are given in the Jan/Feb 1998 edition of Document Management. An information systems project ("the Project’), either in the realm of electronic document management ("EDM") or product data management ("PDM"), is usually intended to satisfy many, diverse needs. In order to ensure the success of the system, these needs have to written down. This is the essence of the Requirements Analysis phase.

 

Do We Need a Requirements Analysis?

Yes.

Many studies show lack of or inadequate requirements are a major cause of system failure, where "failure" is defined as not meeting predefined expectations, often those of the person sponsoring or using the proposed system. This was stated quantitatively by Boehm, as the result of analyzing about 100 software development projects in major corporations. Boehm showed that if the cost of fixing an error is 1 unit at the Requirements phase, it rises to 10 units during coding and 40 to 1,000 units during operation. This is very similar to the "cost of quality" statistics, popularized during the international quality movement, over the last decade.

 

Writing an article about requirements analysis is a daunting task. For a larger EDM/PDM project, there can easily be over 100 subtasks during the Requirements Analysis phase, so it’s tough to present these, plus explanatory discussion, in a reasonable length article. That’s why a comprehensive treatment of this subject is better suited to textbooks, such as those listed at the end of the paper.

However, I would like to:

• discuss why requirements analysis is important,
• discuss some of the key content,
• discuss some of the current issues in requirements analysis.

Requirements are statements of WHAT a proposed system is supposed to do. This is separate from HOW the function is to be accomplished: the HOW being a design issue, not a requirements issue.

For example: "The system shall allow Work-In-Process files to be accessible to all users", is a requirement. On the other hand, "Work-In-Process files will be stored on N:\DATA\WIP\", is a statement of HOW something might be accomplished, and is therefore not normally a requirement.

I had the pleasure of working with an engineer who had years of experience writing system requirements for government electronics projects. His rule of thumb is that if the sentence starts, "The system shall…", then it’s probably a requirement. If a sentence starts in any other way, then it’s not a requirement—it’s descriptive information.

One of the greatest challenges is to avoid designing the system during the Requirements phase. For every requirement that is identified ("The user needs to A, B, C"), a technically inclined person is tempted to offer a solution ("Well, we should X, Y and Z"). Don’t do that! Wait until the totality of requirements is known, before designing.

The high level technical activities during the Requirements Analysis phase are:

• elicitation
• system modeling
• analysis
• documentation
• validation

Elicitation

Armed with the high level project scope, determined during the Initial Study, and the financial information, determined previously or concurrently during the Business Case, you should have a reasonable idea of what the system is supposed to do. It’s now necessary to obtain more detailed information from prospective users and other stakeholders. Normally, this takes place in during meetings and interviews.

Should you interview "everybody", who might be a prospective user or stakeholder? Should you interview a "statistical sample" of users? I would start with the sample (it’s cheaper to interview fewer souls), and then "augment" the initial sample with additional people who contribute some unique functional, technical or political perspective to the project.

 

System Modeling

During the Requirements Analysis phase it is necessary to document the various data elements and business process elements that comprise the mission of the proposed system. An effective way to communicate our understanding of the data and process elements is through models and diagrams. As Teorey notes:

You might need several, complementary approaches:

• Entity-Relationship diagrams: to identify the data elements and illustrate their relationships
• Data flow diagrams: to identify what operations take place on what data. The highest level is often called the context diagram and shows the interconnections with external systems
• Object class/inheritance model: to show which entities have characteristics in common or derived from other entities
• State transition diagrams: which illustrate the range of permissible state changes.

Each of these diagrams models the proposed system in a different way—yet they all contribute to its understanding and communication.

A timesaver to is to automate the creation of these diagrams using a CASE tool. Many use VISIO™ for simple diagramming; others use EasyCase (www.easycase.com) for diagramming, modeling and some database generation. For larger projects, Oracle™-CASE is more common.

As well the system architecture should be modeled, which can start at the block diagram level and work up to the sophisticated diagramming techniques described in the previous, I.T. Strategy, article

The system modeling deals with issues that tend to be quite data-centric. Many additional concerns and activities need to be analyzed, including:

• Performance-related analysis: Designing a system for 1 transaction/minute, 10 users and 100 documents is quite different from a system with 100 transactions/minute, 1,000 users and 1 million documents. Do the requirements reflect the anticipated system size?
• System boundaries: It’s necessary to define what is in the system and what isn’t.
• Grouping: The individual requirements ought to be grouped in some logical way to enhance the clarity of presentation. Affinity analysis often works here.
• Prioritization: The grouped requirements should be prioritized, so that resources can be expended on the more important ones. Prioritization requires some logical analysis as well, since there may be physical constraints. For instance, it’s difficult to effectively implement workflow without having first implemented an electronic vault. So, even if workflow is a higher priority, the vault must be implemented first.
• Complexity analysis: You should assess the complexity of the proposed system. Ask yourself if your company and your industry is typically successful at implementing systems of this level of complexity. If not, a different project management approach is obviously needed.
• Risk analysis: Assess the potential risks of implementation and establish a risk mitigation strategy.

Documentation

The requirements must be documented.

The requirements document must be written clearly and concisely. Words must be used consistently. This is especially true for acronyms. If EDM means "Electronic Document Management" in one section, it should not mean "Engineering Document Management" elsewhere. If you use both the terms EDM and PDM, be sure to provide your own definitions, since the marketplace has sent conflicting messages about what these terms mean.

The level of detail in the requirements document is a compromise. An overly brief requirements document (say 10 pages) doesn’t convey sufficient information about the proposed system. Too many questions are unanswered, there is too much ambiguity about what is wanted, and evaluating vendors’ offerings is impossible without sufficiently detailed requirements. An overly detailed requirements document (say 1,000 pages for typical EDM/PDM implementations) is expensive and time-consuming to produce. Furthermore an overly detailed requirements document might be partially a system design document, which is not desired at this point. Obviously there’s a happy medium between these two extremes.

 

Validation

Once the requirements document is prepared, the requirements must be validated with the various stakeholders. Note that the purpose of reviewing the document is to ensure that the requirements are valid, and not to assess the style and writing ability of the author.

A helpful way to validate the requirements document is to devise test cases, and check to ensure that the necessary requirements are included. Such test cases might be:

• marking up a drawing, which is sheet 5 of 10,
• remote document search (using full text search) and access across the Web,
• printing of a list of documents, without viewing them.

System Size

It is extremely important to obtain and document volumetric information during the requirements elicitation process. Some vendor product offerings cannot demonstrate that they can successfully handle large volumes of users, documents, database tables, etc. You must set the volume targets early, since EDM/PDM systems are only scalable within limited ranges.

 

COTS

Commercial-Off-The-Shelf software is generally procured for EDM/PDM implementations. Such software seems "complete" and some wonder why requirements are even needed since the COTS application "does it all". Requirements are vitally important in the COTS world for two reasons:

• Without detailed requirements, it’s impossible to evaluate and compare vendor product offerings,
• Today’s high end EDM/PDM products are feature rich and can be used for many applications in your organization. It’s still necessary to know what applications will be implemented, or you may end up in a never ending series of "pilots".

RAD/JAD/Prototyping

You may have heard that system development can be accelerated through the use of techniques like Rapid Application Development, Joint Application Development and/or prototyping.

These techniques are very useful, especially during the System Design phase, and especially for developing the user interface. These techniques are not a replacement for developing system requirements.

 

Additional References

For further information on this very involved subject, please refer to the following references: books by Simsion, Firesmith, Booch, Sommerville, Gause & Weinberg, and Boehm.

I would like to acknowledge the substantial contribution of my colleague Glen Alleman, for providing the material for this and other papers. This has been a brief treatment of a very vital subject. Feel free to e-mail me at rhoff@gatewaygrp.com if you’d like more information or elaboration.