Lee would like to thank Glenn A. Stout, a senior functional specialist with The Revere Group, for contributing this month’s column. Glenn has been focusing on requirements and testing methodology for the past four years. You can contact him at gstout@reveregroup.com.

With the unrelenting pace of business change, it is easy to see how the corresponding evolution of our information systems can become overwhelming. Just as business is in a constant state of flux, so are our business systems. One key to keeping our systems in lock step with our changing business needs is to design and code business systems so that at any given point, we can trace how our changing requirements impact our systems.

When IT professionals discuss requirements gathering, the limitations of the "requirements document" are often a major topic of discussion. However, requirements tracing need not be costly or overly complex and, with the growth of Web projects and iterative development, it is quickly becoming a process that should be implemented, at some level, on every software development project.

Why Trace Requirements?

The benefits of requirements tracing are most obvious when the system changes. When high-level requirements change, we know what lower-level objects need to change. For projects that are subject to broad or continual change, this benefit alone may justify requirements tracing.

Testing and system quality also benefit greatly from requirements tracing. If a low-level requirement should fail during requirements testing, it is absolutely clear which high-level requirements will not be met. Also, if there is a defect, all of the areas that will be affected based on the requirements tracing "tree" can be identified.

How to Apply Requirements Tracing: Use Case Methodology

The use case allows for traceability to be an easy addition to the requirements gathering process. Rational Software, a leader in the software development methodology business, offers a best practice for those who wish to employ traceability. In one of their recommended strategies, features are documented in a "vision document," which captures the stakeholders’ views on what the system should do. Any requirements identified, such as non-functional requirements, are then captured in a "supplementary specification document," which describes all requirements that are not in the vision document. Other documents, along with the glossary, round out the document set. 1 (Spence and Probasco, 1998)

An Alternative Approach

Although the Spence and Probasco model is appropriate in some cases, the approach does not offer a level of detail that is needed in most Web-based projects. Let’s look at an alternative approach.

Requirement Types

In this approach, there are several categories of requirements, summarized below. Allowing analysts and designers to record requirements in different areas creates an effective division of labor, as well as full traceability throughout the requirement set. The suggested possible requirement types include:

Stakeholder and High-Level Business Requirements. Stakeholder requirements are often defined by the CEO of the company, and are very high level. They usually focus on a major problem that faces the company. High-level business requirements will fulfill stakeholder requirements, which are usually the creation of an application – i.e., to satisfy a stakeholder need.

Application Requirements. Application requirements drive the development of the application. They fall into the following categories listed. There are fine lines between these types, and the ultimate strategy may be to combine these categories as needed.

  • Use Case Requirements describe the basic flow of the system and define alternate paths through the system.
  • Business Requirements or Rules are specific to the business. These are sometimes listed as non-functional requirements, as they typically do not have a true system function impact. There should be no mention of how these requirement types are to be implemented at this point.
  • Functional Requirements describe how a business rule is carried out or how data is captured, usually in the format of "system shall do this or do that."
  • Technical Requirements are derived during the low-level design process and sometimes during development (e.g., error handling requirements).
  • User Interface Requirements include items such as screen layout, tab flow, mouse and keyboard use, etc.
  • "Look and Feel" Requirements can be categorized as the non-functional user interface type requirements, dealing with how fields look, regarding font, colors, etc.
  • Navigation Requirements are driven and traced from the use case, as the use case lists the flow of the system, and the navigation requirements depict how that flow will take place.

Other Requirements

In addition to the application requirements, the approach will need to account for:

  • Data Requirements – Based on the data needed in the business rules, the database platform, database tables, columns, data types, size and other database attributes can be created.
  • Security Requirements – These encompass all requirements that have to do directly with the application. They mainly will come from business rules.
  • Test (Quality) Requirements/Test Cases – The test cases are traced from all types of requirements. This shows that all requirements can have a test case traced to it
  • Supplementary Requirements – Traced from data and application requirements, these refer to the technology infrastructure and operations type of requirements, such as hardware and network requirements. There are many operations requirements that must also be captured as well.

Requirements Tracing – Next Steps

While requirements tracing is not new, it is a concept whose time has come. Employing an appropriate requirements gathering and tracing methodology results in many benefits to both the system development life cycle and the actual system quality. For more information, please feel free to contact gstout@reveregroup.com.

1. Spence, Ian and Probasco, Leslee. "Traceability Studies for Managing Requirements with Use Cases." (1998). Retrieved April 17, 2001 from the World Wide Web: http://www.rational.com/products/whitepapers/022701.jsp

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access