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 article "Solution Manager Document Status Schema Tutorial.")

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.

Managing Requirements by Document Type

The document-type approach to managing the different requirement types requires setting up a different document type for each requirement type, assigning them status schemas, and assigning the document types to your project.

This approach allows you to define a life cycle or process for managing each type of requirement differently by allowing each type to have a different status schema. Each schema can have different combinations of status values with different rules for how the status sequence can be driven, as well as different authorizations as to who can set or change the status values. Additionally, if required, each different requirement type can have a different digital signature procedure assigned.

While this approach provides for greater flexibility and control over each requirement type, it can become quite complex. Care must be taken when designing this type of management approach as increases in process complexity have significant implications for project team training and ongoing data auditing in Solution Manager.

Managing Requirements via Customer Attributes

The customer attribute approach is much easier to set up as you need to configure only one document type and a status schema. Configuring digital signature procedures is optional. A simple customer attribute can be set up to define the requirements types. This attribute facilitates reporting of the different types independently.

Tests and Test Results

Before I move into traceability management in Solution Manager, you need to understand a few key concepts relating to documenting testing. I cover some techniques that fit into virtually every testing approach and style used to test enterprise applications.

The term test in this context is a documented series of specific instructions (test steps) to be performed in the system to confirm the system is meeting requirements. They describe the specific actions to be taken, inputs used, processing, and expected results or outputs. As with requirements, there are many types of tests. They range from unit tests to user-acceptance and experience tests. They are technical, functional, and non-functional in scope and are performed by different roles throughout the project.

Test results are the documented actual results of the test steps. If the results match the expected results, the test step is passed. If not, the test step has failed.

Tests and test-results documents serve an important role in the delivery of enterprise applications.

First, the tests provide a structured and repeatable way of methodically testing all aspects of the system. The tests (or test scripts) can be reviewed by business and technical team members to confirm thoroughness and completeness prior to executing tests, or even prior to developing the solution. (See “Test-driven development.”)

Second, the test results provide documented proof that the system was tested and that it met stated requirements. This proof is valuable during preparation for solution delivery, IT and business audit procedures, and preservation of the knowledge of the results in a formal way.

Other advantages of tests and tests-results documents are beyond the scope of this article.

Traceability Matching Requirements to the Proof-of-Solution Function

Traceability is another broad subject; therefore, I touch upon only a few concepts and approaches for using Solution Manager for traceability.

The key tenet of traceability is a formal way of proving that the solution meets all the stated requirements. To do this, it is advantageous to establish a traceability matrix.

A traceability matrix is a report that shows the relationships of the stated requirements through to the test result that proves the individual requirement was tested and meets the expected outcome for the requirement.

Building the Trace Matrix in Solution Manager Using Document Links

If you choose to use different document types for each of your requirement types, then you can use the Document Links feature in Solution Manager to map the tests and test-results documents to the requirements documents. The next few figures illustrate how to link documents in Solution Manager using the multiple document type approach.

Navigate to a node on the Business Process Hierarchy where your business requirement document is stored. Open the Proj. Documentation tab and select the document (Figure 1). Click the attributes icon to open the attributes for the document (Figure 2). Then click the Link tab.

Figure 1

Select a business requirement document and click the attributes icon

Figure 2

Select the Link tab

In the Link tab, click the insert link icon  to open the Add Document pop-up screen (Figure 3). The Add Document pop-up screen allows you to create new documents that are linked to the chosen document or to link to existing Solution Manager documents. For my example, select the Link to a Solution Manager Document radio button.

Figure 3

Use the Add Document pop-up screen to link to an existing Solution Manager document

Press Enter and the Find Document pop-up screen appears (Figure 4). In my example, you want to link both the Test Script and the Test Results to the Business Requirement. Click the multiple selection icon  for the Documentation Type field. This action opens the Multiple Selection for Document Type pop-up screen so that you can request both Test Script and Test Results document types (Figure 5). The Test Script and Test Results document types are ZTSR and ZUTR, respectively.

Figure 4

The Find Document pop-up screen

Figure 5

The Multiple Selection for Document Type pop-up screen

Click the execute icon  in the Multiple Selection for Document Type pop-up screen to return to the Find Document pop-up screen. Click the execute icon again and run the search for the Test Script and Test Results documents.

Figure 6 shows the resulting list of documents that can be linked to the Business Requirement document.

Figure 6

Documents found that can be linked to the business requirement document

After you double-click the first document in the list, the document is linked to the business requirement document (Figure 7). Multiple document selection is not supported, so you need to repeat the steps described in Figures 1 through 6 to select any other documents you wish to link to the business requirement document.

Figure 7

The Test Script document is linked to the business requirement document

Using the Documents and Links Report to Generate the Trace Matrix

After you link your documents appropriately, you can use the Documents and Links report to generate the Trace Matrix report. To use this report, execute transaction code SOLAR_EVAL.

After you execute transaction code SOLAR_EVAL, a list of reports is displayed grouped by Project or Solution, and within Project, the reports are grouped by project phase. The Documents and Links report can be found under Assignments in both the Business Blueprint and Configuration phases. Figure 8 shows the report (e.g., Documents and Links) under the Business Blueprint phase.

Figure 8

The Documents and Links report in the Assignments section of the Business Blueprint phase

Double-click the Documents and Links report option to open the selection screen (Figure 9).

Figure 9

Documents and Links selection options

The Project field should default to the project you were using when you linked the documents. If it doesn’t, enter the project name in the Project field (ZPROJTEMPL in my example).

Because the trace matrix in my example establishes a relationship between the business requirement through to the test results, you can enter the business requirement as the document type in the Documentation Type selection option (boxed in Figure 9).

Click the execute icon to run the report. Figure 10 show the report results.

Figure 10

Documents and Links report results

Note that the BREQ001(Business Requirement) is linked to TSR001 (Test Script) and UTR001 (Test Results). From this one report, you can navigate to each of the documents to review the contents and understand how the Business Requirement was tested and the results. 

Building the Trace Matrix in Solution Manager Using Customer Attributes

By setting up a few simple customer attributes you can build a simple trace matrix using a sorting of reports. (For more details on setting up, maintaining, and using customer attributes, see my article “Use Filter and Customer Attributes to Make Large Projects Easier to Navigate.”

First, set up two customer attributes for documents.

1. Requirement type – Used to identify if the document is a business, functional, non-functional, or test requirement. Use this attribute if you are using only one document type for all requirements.
2. Business Requirement ID – Use this attribute to associate the different requirements documents to each other. For example, on the business requirement, test requirement, and test results documents, assign the same value to this attribute (i.e., BREQ001). Your project will define the standards for creating attribute values.

After you set up the customer attributes and maintain the data on the individual documents, you can run many of the SOLAR_EVAL reports and sort by the business requirement ID attribute.

Although this approach to building a trace matrix is simple, it does rely on maintaining the values of the business requirements customer attribute consistently across all the related documents.

There are many things to consider when choosing how to build your traceability matrix, such as which documents need to be included in your matrix, who can set the status on the different documents, and who will audit and manage the data.

Experiment with these techniques to find the combination of features that are a good fit for your project and that balance the level of effort to set up, maintain, and manage against the detailed requirements of your traceability matrix needs.

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.

You may contact the author at solmanruss@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.