Contract-Based Requirements Engineering

Contract-Based Requirements Engineering Brian Berenbach, Ren-Yi Lo, Bill Sherman Software and Systems Engineering Department Siemens Corporate Research, Inc. Princeton, USA {Brian.Berenbach, Ren-Yi.Lo, Bill.Sherman}@siemens.com Abstract — The authors have observed that traditional requirements engineering practices are inadequate to support large projects that are defined by a contract. Unlike a product development effort, contract requirements are not at a uniform level so the typical “V” model for tracing does not work well. Other important attributes of contracts such as penalty clauses, contract options, incentive payments, regulatory codes and standards, cross-cutting and project execution requirements all need to be considered. This paper describes some of the challenges and recommended best practices for the management of requirements on large contractbased projects as described from the perspective of the lead supplier or prime contractor. Keywords-requirements engineering; systems engineering; contracting;

I.

INTRODUCTION

Requirements engineering for contract based systems is critical to the successful execution of projects. We have found that new hires, including those with academic training in requirements engineering, are often unfamiliar with the unique challenges posed by contract-based projects. While there has been some work done on addressing legal requirements in requirements engineering [1][2], the focus has tended to be on semantic analysis. Furthermore, a lack of knowledge can be very costly, as contract-based projects tend to be large: involvement of many subcontractors, complex domains, and demand heavy penalties for mistakes or missed deadlines. We have identified several key requirements engineering practices where there is increased complexity and risk when the project is contract-based, including:  The tracing model  Project execution requirements  Constraints  Cross-cutting requirements  Regulatory codes and standards  Contract options  Penalty clauses  Incentive payments  Requirements analysis  Contract compliance  Subcontractor work packages The complexities related to the topics listed above

force changes to the requirements engineering processes as well as to all other project processes (e.g. quality assurance, testing, and project management). We assume that due diligence [1] was previously completed in upstream processes, and that a contract has already been negotiated and signed. While due diligence has different meanings in different domains (e.g. a real estate contract vs. an infrastructure upgrade contract), several concepts are common across domains, that is, “to obtain and analyze enough information prior to contract award to understand any risks to the seller, the needs of the buyer, sellers contractual obligations including deliverables, procedures and warrantees, sellers obligations regarding third parties, and any confidentiality issues”. Basically the seller needs to fully understand all aspects of the arrangement with the buyer(s). Note that the scope of this paper is limited to requirements processes and deliverables after the contract has been awarded. II.

THE TRACING MODEL

We recommend that a comprehensive tracing model be developed to:     

Determine compliance with the contract quirements and regulations Create trace matrices Determine test coverage Perform derivation analysis Perform impact analysis

re-

The traditional “V” model [4] is an abstraction that defines a development process and alludes to the tracing of tests from the requirements. The “V” model process is shown as a sequence of steps down the left side of the “V”. Tests are shown ascending on the right side of the “V”. Traces are shown pointing (left to right) from the requirements and the developed artifacts to the tests. The “V” model is inadequate to serve as an actual tracing model for the following reasons:  

The “V” model does not include sufficient detail for comprehensive tracing of all the artifacts. The directionality of the traces should always be pointing to the “document of authority” from the derived artifact.

Contract

Component Requirement

System Specification


System Requirement


Traces Choke Point Break Here!

test case to contract requirement. Should the door dimensions change in the contract, the change might not propagate to the component level ( in figure 1 we are looking at the left side of the “V” and the downward traces); much better would be a trace directly from the contract requirement to the component level requirement, but once we do this we no longer have a “V” shaped tracing model as some customer level requirements (the contract) trace DIRECTLY to component level requirements. III.

Subsystem Specification


Subsystem Requirement


Component Specification Figure 1. “V-Model” can break contract traces

 



The decomposition of higher level requirements should be vertically traced. Much, if not most, of the lower level detail constraining the design, which would ordinarily be developed through decomposition of higher level requirements, is provided in the contract. This makes it more appropriate for the component level to trace “horizontally” to the contract rather than tracing “vertically” from a decomposed higher level requirement. The majority of the tracing will be “horizontal” compared to the rather sparse “vertical” tracing. Many requirements in a contract are related to project execution (see section III). We suggest that these be handled and traced differently than developed “system” requirements.

In summary, a contract will have requirements in it at many different levels, as well as cross-cutting and project execution requirements (see the following sections). If the “V” model were followed literally, then a low level contract requirement such as “Each door shall provide a free opening of approximately 863.6mm (34 inch) wide by 1714.5mm (67-1/2 inch) high” might appear describing an aspect of a building structure. This requirement would then be traced to a system level requirement “All exterior buildings shall be equipped with doors”, which would then “fan out” to a low level component requirement “ The door of an exterior building shall provide a free opening of approximately 863.6mm (34 inch) wide by 714.5mm (67-1/2 inch) high.” Note that we have a “fan in-fan out” situation here with the system requirement becoming a choke point that breaks the trace path from

PROJECT EXECUTION REQUIREMENTS

Project Execution (PE) requirements are those that either effect the way the project is executed (e.g. things to do) or are in one of two special categories of deliverables: long term obligations or submittals. Unlike product development, where such requirements may be company policy or guidelines, when working with a contract, PE requirements must be followed scrupulously to avoid being in breach of contract [3]. Many PE requirements are not testable on the final system and evidence of compliance (e.g.: visual inspection reports and photographic records) must be collected during the execution of the project. For example, “Provide backfill and tamp any open trenching as a result of ductwork installation,” is a testable requirement, but not on the completed system itself. Things to do are requirements detailing how a contractor or its subcontractor and developers must execute tasks during the project in order for the final product to be accepted. Typically, these requirements include activities that mandate monitoring, as verification cannot be accomplished on the final set of deliverables. By not being testable at the end of the project, these requirements must be verified and documented during the execution of the project. Examples of things to do include: installation, commissioning, payment of fees, scheduling and coordination, tests and inspections, use of licensed workers, taking pictures and documenting process compliance. For example, the requirement “Use approved wire cable grip when pulling cable,” might be verified by making a video or taking still pictures during the cable pulling process. Long Term Obligations are requirements that describe the contractor’s responsibilities to the client in relation to the system, but do not include the actual properties or functions of the system itself. Some examples are post installation service, maintenance, warranties and spare parts (which may include the spare parts management system and process in addition to the parts). We recommend that PE requirements be managed and stored separately from traditional functional and nonfunctional requirements describing system deliverables. They are of special interest to the Quality Assurance staff, and may be used by internal, government and client auditors. Unlike functional requirements which are traced to test cases, PE requirements are traced to records of evi-

Regulatory requirements can be considered a type of

Figure 2. Tracing to regulatory codes

dence or other proof of compliance. They may also be traced to project milestones to ensure that they are performed at the right time in the project timeline. A potential problem with PE requirements is compliance by subcontractors. While the prime contractor will most likely use a requirements database, support tracing and have quality assurance and requirements staff, subcontractors may be small operations without such facilities or roles. Consequently, traces from project execution requirements are especially important when generating work packages for subcontractors. Submittals are requirements that describe documents or any other item that must be delivered to the client as a part of or as a record of the execution of the project. They can be documents in electronic format, in hard copy or both. Examples of submittals include: plans, manuals, drawings, samples, licenses, and requests for approval. We recommend that submittal requirements be tracked and executed like any other requirement. For example, the requirement “The new traffic light design shall be approved by the department of transportation chief engineer prior to the actual ordering of any of the signals” must be traced to a project milestone. If not, many orders placed for lights might have to be rescinded and reissued. In the worst case scenario, if the requirement is not met, any installed traffic lights might have to be removed and replaced with new approved signals, resulting in a significant loss to the contractor. IV.

CONSTRAINTS

Constraints are requirements that narrow or define the scope of a solution. For example, during the installation of ladders, a contract requirement might call for a specific brand of ladder, or other constraint that would narrow the design choices for example “Exterior metal surfaces for all structures shall be painted with Benjamin Moore M2480 P paint.” Constraints are typically kept in a section specific to constraint requirements. Keeping them separate allows architects and designers to review them prior to specifying or ordering equipment. Once a contract is signed, the contractor is expected to adhere to the constraints as stated in the contract. If due diligence has been performed there should be no conflicts between constraints and other requirements requiring resolution. However, should an issue arise as a result of further analysis of the contract requirements; resolution is usually required prior to implementation (see sections X and XI).

Contract

Signaling Subsystem

“All exterior structures shall be secured from unauthorized access with heavy duty padlocks.”

“All exterior signaling enclosures shall be secured from unauthorized access with heavy duty padlocks.”

“Wayside cases shall be secured with shrouded stainless steel combination padlocks.”

“Each bungalow shall be secured from unauthorized access with two squire stronghold high security wheel 75mm padlocks.”

Wayside Cases

Bungalows

Signaling Components Figure 3. Propagating cross-cutting requirements down.

constraint in that they partially constrain the scope of the solution. The main difference between constraint requirements and regulatory requirements is a legal one – regulatory codes are mandated by law and failure to follow them may result in civil or criminal penalties. V.

CROSS-CUTTING REQUIREMENTS

Cross-cutting requirements are requirements in the contract that are applicable to two or more subsystems. For example, “Provide padlocks for doors or covers of equipment in the system” is a cross-cutting requirement that applies to enclosures, buildings, panels and cases for equipment that are present in various subsystems. In order to ensure that cross-cutting requirements are included in the various work packages, they are propagated downward and customized for clarity, while maintaining traces back to the original contract requirement (figure 3.) VI.

REGULATORY CODES AND STANDARDS

A regulatory code is a set of requirements, produced by a legal entity, that are enforced by law. Standards such as IEEE 1220 [5] produced by professional organizations (e.g. IEEE) are considered guidelines or suggested best practice. However, if a standard is mandated in a contract, it then becomes legally binding and has the same impact as any other contractual requirement, e.g. “The Systems Engineering Management Plan shall be created in accor-

dance with IEEE 1220.” For convenience, we classify regulatory codes1as blanket, implicit and explicit. A blanket regulatory code is referenced in a contract, but it is left to the contractor to figure out where it applies, such as “All electrical work shall comply with applicable regulations in the New York State Electrical Code”. An implicit regulatory requirement is one that impacts contract requirements but is not specifically mentioned in the contract. For example, a contract may specify the construction of tank cars for a North American railway without mentioning any regulatory codes. Yet in order to use any Department of Transportation or Association of American Railroads tank car in North America, the rail car must meet the HM-201 federal regulation published by the U.S. Department of Transportation Pipeline and Hazardous Material Safety Administration Office of Hazardous Materials Safety. It is really up to the domain experts on the project to ensure compliance with relevant implicit regulatory codes, as extensive knowledge is needed to understand which parts of which codes are applicable. However it is the job of the requirements engineer to take that domain knowledge and capture it in the requirements database so that verification and validation can ensure compliance. An explicit regulatory requirement is the easiest to manage. It is specifically referenced as part of the individual contract requirement. For example, “Ensure that all hex bolts are in conformance with ANSI B18.2.1.” provides an explicit reference to the applicable regulatory requirement. Regulatory codes are pervasive and complex. Furthermore, because there are so many of them, and some codes are quite lengthy (e.g. some are over one thousand pages) or available only in hard copy, it may not be feasible or cost effective to import each applicable code clause into a requirements database. Yet, tracing from the regulatory requirement to the contract requirement is necessary to ensure that all appropriate regulatory requirements are considered and complied with. One approach that has been used at Siemens is to create a database section with regulatory requirement proxies (Figure 2). Each code has its own proxy in the database with a pointer back to the actual code in the form of a hyperlink or hard reference. Contract requirements then trace to the regulatory proxies. Note that this approach does have some problems. While generation of a work package will result in each requirement referencing the applicable code, there will be no fine grain trace from contract requirement to regulatory requirement. The people doing the work then, (e.g. the prime or subcontractors) must know how the code applies to their work. It is standard industry practice to make that assumption; fine grain tracing into each regulatory code would be an overwhelming amount of work that would also create additional risks. 1 A regulatory code is a related set of regulatory requirements typically published by a government agency. Adherence to code is usually mandated by law.

Figure 4. Tracing contract options

VII. CONTRACT OPTIONS A contract option is an offer that is included in a formal contract. The option cannot be revoked by the seller until the option expires, at which point it is voided unless renegotiated by the seller and the buyer [1]. The contractor must be ready to do the requirements analysis and perform the additional project work at such time that an option is exercised, which is generally any time up to the expiration date of the option. When a contract contains options that have not yet been exercised, management must decide how much risk the project is willing to incur by either developing the associated requirements or ignoring them until the option is exercised. If the analysis and development of unexercised requirements is done for an option that is ultimately left unexercised or allowed to expire, costly analysis and design work will have been done unnecessarily. The larger risk in developing the requirements of unexercised options is that the option characteristic of the requirements may be “lost in analysis” and the client may end up receiving an expensive unexercised option for free. Ignoring the option completely until it is exercised is also problematic. The contractor runs the risk of discovering late in the project that the exercised option may have implementation issues or may conflict with other requirements. Moreover, if design has started prior to the decision to exercise the option, then some designs may have to be changed. The worst case scenario for ignoring the option until it is exercised late in the project is the need for costly retrofitting to accommodate the option’s requirements.

Quality Mgmt System spec Contract Req't s1 s2 s3 s4 s5 c1 x c2 x c3 x x c4 x c5 x

System Test Contract Req't t1 t2 t3 t4 t5 c1 x c2 x c3 x c4 x c5 x

Figure 5. Compliance trace matrices

A suggested approach is to:   

 

Put the contract options in a separate section of the requirements database. Trace to any derived or impacted requirements. Provide some kind of visual warning indicator to show that the requirement is an option. This can be accomplished with a conditional statement in the requirement (e.g.: If Option 5 is exercised…). When the option is exercised, convert the option and any derived requirements into standard rather than option objects. On expiration of the option, clearly mark any derived contract and system requirements as deprecated or inactive.

In the example shown in Figure 4, a traffic light metaphor is used to indicate the status of the option (i.e.: Green=executed, Yellow=unexercised, and Red=expired). VIII. PENALTY CLAUSES AND DELAYED PAYMENTS Contracts may specify monetary penalties for missing functionality, poor quality, late delivery, or no delivery. The most severe form of penalty is the effective firing of the contractor and replacement with a new contractor that will be paid by the original contractor (with possible severe long term ramifications for the contractor that was fired). We recommend that some penalty clauses be analyzed and turned into requirements such as the following:  

Clauses dealing with the quality of deliverables must be analyzed to create derived requirements that are testable and are acceptable to the client. Clauses dealing with inspections and signoffs may have to be turned into PE requirements.

Requirements engineers may not get involved with parts of the contract that do not directly specify delive-

Quality Plan

Requirements Database Relevant Codes

Work Package Generation & Transmission

Relevant Program & Test Requirements

Relevant Functional Requirements

Relevant Standards

Project Mgmt Project Plan

Figure 6 Work Package Genera tion

rables and requirements. However, ignoring the management of requirements that derive from penalty clauses can be a costly mistake. IX.

INCENTIVE PAYMENTS

Some contracts specify incentive payments for early delivery. Unfortunately, such payments are often considered to be the sole domain of project management and may not be effectively communicated to the engineering staff. We recommend that incentives be managed in a similar fashion as contract options, and they should be traced to the impacted requirements. For example, there may be an incentive payment for the installation of a communications system, whereas there may not be an incentive payment for the installation of heating and air conditioning systems in the same facility. The requirements for the communication system are then prioritized at a higher level than heating and air conditioning. When requirement specifications or work breakdown structures and schedules are generated, the communication system would be clearly marked as having a high priority. X.

REQUIREMENTS ANALYSIS

Even with a contract that is well written, there is a need to analyze the requirements to ensure that everything can be tested to demonstrate contract compliance. During requirements analysis, it is a best practice to clarify abstract or ambiguous requirements so that each requirement is associated with derived, testable requirements that prove compliance. For example, an illustration of the use of goal modeling to analyze performance and extensibility requirements on a large project can be found in reference [6]. Where risk is discovered during analysis, we recommend the use of techniques such as those described in Table 1[7] to mitigate any potential problems that may result in the incurring of significant unforseen charges.

Risk Avoidance Technique

Original Requirement

Rewritten Requirement

Potential Risk

Assumption

“Off-the-shelf Fiber optic backbone shall be used.”

We make the assumption that the risk associated with the use of Fiber optic backbone is minimal.

Requirement is left unmodified.

Control

“The milestone payment shall be made upon acceptance of the user manual by the client."

The supplier has no control of the acceptance of user manuals; it is based on subjective criteria.

“The milestone payment shall be made upon delivery of the first draft of the user manuals to the client.”

Transfer

“While shipping shall be arranged by the client, the supplier shall be liable for any damages incurred in shipping.”

The supplier has no control but bears the liability should there be damage; transfer responsibility to the client

“Shipping shall be arranged and managed by the supplier.”

Avoidance

“The control system displays shall show all plant maps in three dimensions using 3D monitors and software.”

The technology is a risk. It may not be ready for commercial use when control system manufacturing or installation is scheduled to take place.

“The control system displays shall show all plant maps in two dimensions using 2D monitors and software. Post installation, the client may request a second contract be negotiated for the conversion from 2D to 3D once the technology becomes available.”

Table 1 Risk Avoidance Techniques

We suggest some guidelines that should be observed when creating requests for information (RFI) or approval of a set of derived requirements from the client during an analysis effort: 1.

Do not ask questions or make statements in a manner that may be interpreted as derogatory. Asking “What do you mean by high quality?” may reflect poorly on the supplier. The client would expect the supplier to already know what “high quality” means, e.g. “Why ask me when you are supposedly the expert?” Another question such as “Why did you choose A when B is better?” might imply that the client is not knowledgeable in the domain.

2.

Questions should always be bounded so that there will be closure in the response. For example, “We propose the use of Systems Wire & Cable Brand 10 gauge wire where the use of “high quality” 10 gauge wire is specified” as opposed to “What brand would you suggest for high quality 10 gauge cables?”

3.

The early analysis phase of a contract-based project is an excellent opportunity to create a positive relationship with the customer, creating a constructive, rather than adversarial, atmosphere.

4. Rather than submitting RFIs to the client one at a time and waiting for responses, it is more efficient to collect the questions, and then having a sit-down meeting with the client to answer them. This approach can elimi-

nate time consuming back-and-forth discussions and mitigate the possibility of irritating the client. XI.

CONTRACT COMPLIANCE

Contract compliance is generally proven by means of a set of trace matrices that show how each requirement in the contract is met in design, during execution, and in the finished product (Figure 5). The matrices are generated from the database containing the contract and project requirements. As mentioned previously, there are two important prerequisites to creating the trace matrices: (1) every contract requirement is either testable or has a derived set of testable requirements that prove compliance and (2) the client has accepted that the testable requirements will meet the terms of the contract. Demonstrating compliance can be challenging, and the earlier in the project the test mechanisms are defined, the less likely that there will be payment disputes. For example, one of the authors of this paper, prior to joining Siemens, was on a team delivering a computer control system to a refinery. The final milestone payment was due on delivery of the equipment. The contract stipulated that all delivered equipment would be new. Unfortunately, one of the delivered computer cabinets had a scratch in it. The client refused to pay on the grounds that it was not “new.” Actually, the client had a cash flow problem and wanted to delay payment, and they were able to use the lack of clarity in the requirement for “new equipment” to significantly delay a major payment. XII. CONCLUSIONS Requirements engineering processes for contractbased systems are considerably more complex than those used for product development, and the execution of such projects can be quite challenging.

Moreover, aspects of the contract such as penalty and option clauses may not be treated as requirements and may be handled in a disjoint manner. While some work has been done to study the transfer of information from prime to subcontractor, it has typically focused on software [10], a specific technology such as platform development [11], or problems associated with small enterprises, as opposed to the holistic view of RE processes on large, contract-based projects. We believe that the application of RE “Best Practices” to contract- based projects has the potential for improving productivity and contributing to project success, and further research is needed to define those best practices (see below). XIII. SUGGESTED FUTURE RESEARCH There are several areas where additional research is needed for the improvement of processes and tools used on contract-based projects, especially large infrastructure projects involving more than one contractor or solution provider. For example,  How to create work packages that include regulatory requirements, project execution requirements and cross-cutting requirements so that subcontractors with little or no background in requirements engineering can function effectively, with their work being tracked, validated and verified? (Figure 6)  How to effectively manage the regulatory codes that impact a large infrastructure project [8]?  How to effectively and efficiently monitor and manage the requirements that derive from penalty clauses, incentive clauses and contract options?  What techniques and tools might be made available to improve the management of project execution and cross-cutting requirements?  How might verification and validation, quality assurance and requirement engineering processes be better integrated?  How to better integrate project management and requirements engineering tools? We are currently looking at tooling, tracing models, and processes to help address some of the problems described above. XIV. REFERENCES T.D. Breaux, M.W. Vail, A.I. Antón, “Towards Regulatory Compliance : Extracting Rights and Obligatrions to Align Requirements with Regulations”, Proc. Of the 13th IEEE International Conference on Requirements Engineering, Minneapolis, September 2005. [2] P. Otto, A.I. Antón, “Addressing Legal Requirements in Requirements Engineering, Proc. Of the 15th IEEE International Conference on Requirements Engineering, New Dehli, October, 2007. [3] B. Garner: Black’s Law Dictionary, West Publishing Company, St. Paul, Mn. 2009. [4] R.S. Pressman: Software Engineering: A Practitioner's Approach, The McGraw-Hill Companies, 2009. [1]

Institute of Electrical and Electronics Engineers, Inc. (IEEE) STD 1220-2005, IEEE Standard for Application and Management of Systems. [6] J. Cleland-Huang; Marrero, W., and Berenbach, B., "Goalcentric traceability: using virtual plumblines to maintain critical systemic qualities," IEEE Transactions on Software Engineering. Vol. 34, no. 5, p. 685-699. 2008. [7] U.S. Department of Defense Risk Management Guide, August 2006 [5]

[8]

B. Berenbach, D. Grusemann and J. Cleland-Huang: "The Application of Just In Time Tracing to Regulatory Codes and Standards," 8th Conference on Systems Engineering Research, March 17-19, 2010, Hoboken, NJ. [9] T.J.M. Bench-Capon, G.O. Robinson, T.W. Routen, M.J. Sergot, “Logic Programming For Large Scale Applications in Law: A Formalization of Supplementary Benefit Legislation” 1st Int’l Conf. on AI and Law, Boston, MA, USA, pp. 190-198, 1987. [10] D. Assmann, T. Punter, “Towards partnership in software subcontracting”, Computers in Industry, 54 (2004) pp. 137-150. [11] B. Regnell, H. O. Olsson, S. Mossberg, “Assessing Requirements Compliance Scenarios in System Platform Subcontracting”, PROFES 2006, LNCS 4034, pp. 362-376, 2006. [12] E. Kamsties, K. Hörmann, M. Schlich, „Requirements Engineering in Small and Medium Enterprises: State-of-the-Practice, Problems, Solutions, and Technology Transfer, Proc. Of the Conference on Eurpopean Industrial Requirements Engineering (CEIRE’98), October 1998, London.