Alter Your Requirements Process

We all could improve our requirements analysis. Conferences, books, and magazines offer some great schemes that we'd all love to implement; unfortunately, with the reality of budget, time, and tools, not many of us can hope to fashion a completely new requirements process from scratch. But that doesn't mean that some well-placed alterations wouldn't make what we already have better. And isn't better—well—better?

The problem we have is knowing where to make changes and which changes to make. Knowing where to make changes is easy if you pay attention to the elements of your project's SUIT: Scope, Understanding, Instability, and Traceability. (Symptoms that help shine light on which SUIT elements are plaguing a project can be observed and quantified in the form of metrics.

Scope is the line separating what is included in a system from what is excluded from a system. Improperly defined boundaries, requirements that are too complete, or a lack of prioritization can yield disarray throughout the software development lifecycle.

Ambiguous, unclear, and/or untestable requirements result in gaps in understanding. For example, a requirement reading "The page should load quickly" is problematic because "quickly" means different things to different people. If the system isn't adequately understood, it won’t matter how well the boundaries are created and documented.

Problems in scope and understanding often result in excessive requirements rework, causing changes to occur faster than they can be maintained, or instability. For example, version 3 of a requirement exists, but developers are still using version 2, and testers are on version 1.

Problems due to instability are magnified by poor traceability. Traceability is important for ensuring that all requirements are met and tested, and for doing an impact analysis on proposed system changes.

I suggest seven small alterations that are easy to implement and will greatly improve your project's SUIT. Table 1 summarizes these suggestions and details which SUIT area each change addresses.

ALTERATION 1: Assign Risks
Risks are composed of probability and severity, where probability is the likelihood of an undesirable event occurring, and severity is the impact of its occurrence.

Probability may be ascertained by analyzing defects from previous projects. Depending on what information you have collected about defects, you may need to add additional fields to the defect repository for the analysis. For example, a defect spreadsheet, as illustrated in Table 2, may initially appear without the Function column. The Function column should be added to identify how application functionality is related to each defect. Each defect's description provides information to help populate this column.

Once your table is complete, you can produce a graph identifying what percentage of defects occurs in each functional area. Give those areas with high percentages a high probability rating.

While requirements analysts should determine probability, only users, business analysts, managers, etc., should assign severity levels to risks. They should consider legal consequences, inconvenience, failed government standards, potential loss of future business, and what maintenance resources will be required in the event of a failure.

Risk analysis resolves scope issues through prioritization. Developers will develop the highest-priority requirements first, reducing the impact of a schedule reduction. Also, testers will be able to perform risk-based testing by prioritizing test case execution based on requirements risks.

ALTERATION 2: Add a Data Dictionary
A data dictionary provides descriptions of each application data element. Table 3 shows a sample data dictionary and includes the following fields:

ID—Data element identifier

Name—Element name from the domain

Definition—Element's purpose

Type—Data type

Format—Allowable number of characters and default values

Condition—Special circumstances related to the display of the field

Requirements