Requirements Management and Traceability for Implementations

  • by D. Russell Sloan, Implementation and Governance Specialist — SAP Solution Manager, IBM Global Business Services
  • July 27, 2015
D. Russell Sloan explores different techniques for managing requirements and creating traceability of requirements to test cases. Learn how to create a traceability matrix using document links as well as a technique using customer attributes.

Learning Objectives
Reading this article you will learn:
  •     The different types of requirements and how to manage them in Solution Manager
  •     How to use document types
  •     How to use customer attributes
  •     The advantages and limitations of the two options
Key Concept

In the context of a solution implementation, traceability is the following of the life of a requirement from idea to implementation. In order to confirm that a solution meets the requirements, a traceability matrix is used to document the journey from the idea (requirement) to implementation (tested and approved by the business). For more details on traceability in the context of solution development see this IBM developerWorks blog at

The definition of a requirement is multifaceted and needs to be clarified as you prepare to explore techniques for capturing and managing it. Some examples include business, business controls, functional, non-functional, and test requirements.

Business requirements describe what the business intends to do to deliver value. They should be system independent, concise, and measurable. For example, a catering company may have a business requirement that states, “We will establish and maintain the capacity to serve three-course meals to up to 400 guests with a start-to-finish serving time of 20 minutes or less.” This requirement is stated in terms of what the business must accomplish in a system or technology with two clear measures of the requirement being met.

Business controls are predetermined standards for measures used to ensure compliance to requirements, both internal and external, and to ensure quality. Using the example above, one business control could be, “All hot food items must be maintained at a minimum temperature of 140° degrees on all serving and preparation lines.” This establishes the standard for the control and defines a clear measure to establish compliance.

Functional requirements provide specific things a system or solution must do to support business requirements. For example, to support serving 400 meals in 20 minutes or less, the solution must provide for replenishment of food items upon request from plate-preparation personnel.

Non-functional requirements define quality attributes of the defined system or solution. They cover all the remaining requirements that are not covered under functional requirements. Continuing my serving example, a non-functional requirement would be “The system must provide for replenishment of food items within one minute of request.”

Test requirements are very technical- or solution-specific requirements. They help to assure system integrity, continuity, and performance. They define the answers to “What happens if” or “The system must.” For example, if the business requirement is to be able to enter a new customer, what should the system do if there is a database update failure? Requirements could be that “The system must not lose data entered upon failure” or “The posting program must support restart and continue upon posting failure.”

Understanding the different types of requirements is important in order to manage them. In Solution Manager, you have options for how to deal with the different types of requirements. The two primary ways are with document types and customer attributes.

Using document types to manage requirement types enables you to have different status values and processes for each type of requirement, as well as to independently define when requirements are put under change control through document locking. (Document locking is covered in my upcoming article on status schema configuration.)

Using customer attributes to manage requirement types allows you to report on the requirement types independently while managing all types using the same process or life cycle.

Both options have advantages and limitations. I explore some of these in this article.

D. Russell Sloan

D. Russell Sloan is a specialist in project and program governance for IBM. He focuses on the use of SAP Solution Manager for global rollout projects for IBM’s largest customers, having worked with SAP software since 1996. Russell has degrees in accounting and information systems and has been a team and project leader for SAP projects for more than 14 years. He has been developing and deploying software systems for over 30 years.

See more by this author


No comments have been submitted on this article. 

Please log in to post a comment.

To learn more about subscription access to premium content, click here.