Requirements Management

PEER-REVIEWED

Orlando Lopez

ABSTRACT According to the ASTM E2500-07, requirements This article examines the management of require- come from four areas: product knowledge, process ments during the computer system lifecycle. Five knowledge, regulatory agencies, and company qual- categories of activities are identified. Specific actions ity standards. within each category are described. Requirements Requirements may be captured as user scenarios, management comprises a significant portion of system function and feature lists, analysis models, or specifica- lifecycle costs and must be well controlled. A listing tions. These work products are used as a framework to of applicable tools to facilitate requirements manage- select the supplier or integrator, to develop other work ment is provided. products associated with the development of the computer system, and to develop the user acceptance test. INTRODUCTION Requirements engineering strives to understand The majority of computer system failures are due what the relevant stakeholders need and want before to poor requirements-gathering and management. beginning to design and build a solution. Tools that This includes not understanding the business impact, software engineers can leverage include Six Sigma, what the customer wants, and how the end-user is voice of the customer (VOC), quality function deploy- to interact with the computer system. This situation ment (QFD), failure mode and effect analysis (FMEA), negatively affects subsequent development activities, requirements analysis matrix (RAM), orthogonal array associated work products, and quality. (OA), cause and effect analysis (C-E), design structure A requirement is a need or expectation that is matrix (DSM), Pugh matrix, and so on. stated, generally implied, or obligatory. “Gener- The requirements engineering tasks comprise the ally implied” means that it is common practice for following: the relevant stakeholders (i.e., business managers, • Inception. Context-free questions are used to end-users, software engineers, support people) establish a basic understanding of the problem, such that its absence would be deemed an obvious the perspectives of relevant stakeholders who shortcoming. The term “requirement” defines a bounded charac- terization of the system scope that can be generated by “User requirements specifications should different relevant stakeholders. It includes the infor- describe the required functions of the com- mation essential to communicate an understanding of puterized system and be based on docu- the problem and to support relevant stakeholders in mented risk assessment and GMP impact. its resolution. Various types of requirements include User requirements should be traceable product, functionality, performance, regulatory, legal, throughout the lifecycle.” reliability, supportability, usability, security, and non- —EU Annex 11 functional requirements.

For more Author ABOUT THE AUTHOR information, Orlando López is an independent consultant with more than 25 years of software quality assurance go to experience and more than 18 years in quality assurance and compliance in the FDA- and EU-regulated gxpandjvt.com/bios[environment. He may be contacted by e-mail at [email protected].

78 Journal of Validation Technology [Spring 2011] ivthome.com ORLANDO LOPEZ

want a solution, the nature of the solution, and Figure 1: Systems development distribution. (Source: Roger the effectiveness of the collaboration between S. Pressman, Software Engineering: A Practitioner’s Approach, 7th ed., the relevant stakeholders and developers. McGraw-Hill, NY, used with permission by Roger S. Pressman.) • Elicitation. Relevant stakeholders describe the product objectives, what is to be done, how the product fits into business needs, and how the • “front end” activities product is used on a daily basis. 40-50% customer communication • Elaboration. A refined technical model of analysis software function, behavior, and information design is developed. review and modication • Negotiation. Requirements are categorized and organized into subsets, relations among require- • construction activities 15-20% ments identified, requirements reviewed for cor- coding or code rectness, requirements prioritized based on the relevant stakeholders needs. generation • Specification. Requirements are derived from • testing and installation or provided by the relevant stakeholders describ- 30-40% unit, integration ing the function, performance, and development white-box, black box constraints for a computer system. These work regression products should be in a form suitable for requirements management through the lifecycle and beyond. • Requirements validation. Formal technical reviews examine the specification work products Figure 2: Cost to find and fix a defect. to ensure requirement quality and that all work products conform to agreed-upon standards for Cost to nd and x a defect the process, project, and products. • Requirements management. Activities that 60.00-100.00 help a project team to identify, control, and track 100 requirements and requirement changes as the project proceeds. 10 10.00

Figure 1 depicts a typical systems development dis- log scale 3.00 tribution showing the percentage of effort needed for 1.50 1.00 each key developmental activity. Except for require- 1 0.75 ments management, front-end activities should take between 40-50% of the system development lifecycle Test est (SDLC) distribution. Req. Code The importance of managing requirements is Design Field Use depicted in Figure 2. This figure correlates the cost System T to find and fix defects during the system lifecycle (SLC). For example, finding and fixing an error during the requirements costs 3/4 (.75) unit. Finding and REQUIREMENTS fixing the same error during the system testing will MANAGEMENT PURPOSE cost around 10 units. The purpose of the requirements management pro- This discussion addresses product requirements cess is to maintain and control a current, correct, and activities. Product requirements include high level documented common understanding of the relevant features or capabilities that the business team has stakeholders, intended product use, development committed to delivering to a customer. Product resources, constraints, and needed computer system requirements do not specify how the features or the capabilities that were captured and baselined in the capabilities will be designed. Project requirements requirements documentation. are beyond the scope of this paper. The requirements management process describes gxpandjvt.com Journal of Validation Technology [Spring 2011] 79 PEER-REVIEWED

Figure 3: Requirements management. management and can be elements of the plan are as follows: Manage Requirements • Obtain an understanding of requirements

Manage • Obtain commitment to requirements Obtain an Obtain Requirements Onderstanding Commitment • Manage requirements changes Changes of of • Maintain bidirectional traceability of Requirements Requirements Maintain requirements Bidirectional Traceability of • Ensure alignment between project work and Requirements requirements. Requirements

Identify Figure 3 provides the relationships between these Inconsisitencies Between Project activities. Work and Traceability Matrix Requirements OBTAINING AN UNDERSTANDING OF REQUIREMENTS The intent of these activities is to establish crite- the tasks necessary to correct, update, and control a ria for the project, to identify appropriate require- requirements specification (RS). ments providers, to set criteria for the evaluation and The result of requirements management process is acceptance of requirements, and to ensure through an updated organized set of documented requirements an analysis or review process that the established throughout the system lifecycle that do the following: criteria are met. • Supports the relevant stakeholder’s needs, goals, Those who receive requirements analyze them and objectives with the providers to ensure that a compatible shared • Remains within a well-defined scope understanding is reached on the meaning of require- • Identifies and quantifies impacts of changes ments. The result of these analyses and dialogs is an including those of scope, schedule, cost, hard- approved RS including the definition of the system ware, and staffing boundaries. • Controls the current, documented RS. Example work products for this practice include the following: A requirement management plan may be neces- • Lists of criteria for distinguishing appropriate sary for highly-complex and highly-critical proj- requirements providers ects. The requirements management plan is used • Criteria for evaluation and acceptance of require- to document the necessary activities required to ments (see Table I) effectively manage project requirements from trace- • Results of analyses against criteria. ability to delivery. The requirements management plan is created dur- Lack of evaluation and acceptance criteria often ing the planning phase of the project. Its intended results in inadequate verification, costly rework (see audience is the project manager, project team, proj- Figure 2), or customer rejection. ect sponsor, and any senior leaders whose support is needed to carry out the plan. OBTAINING According to the capability maturity model integra- COMMITMENT TO REQUIREMENTS tion (CMMI), activities that are part of requirements Once the understanding of the requirement is established, this practice deals with agreements and commitments among those who have to carry out the activities “A software requirements traceability anal- necessary to implement the requirements. ysis should be conducted to trace software The main deliverable after getting the commitment requirements to (and from) system require- of the relevant stakeholders is the RS. It is an approved ments and to risk analysis results.” document by all relevant stakeholders. The RS estab- —US FDA General Principles of lishes the relevant stakeholders’ requirements baseline, Software Validation and retains changes of need and their origin throughout the system lifecycle. It is the basis for traceability to the

80 Journal of Validation Technology [Spring 2011] ivthome.com ORLANDO LOPEZ

computer system requirements and forms the definitive Table I: Attributes of requirements. source of information about requirements for subse- Attribute Definition quent systems and communications with stakeholders. Unambiguous All requirements must have only one interpretation Later, in the thick of development, the RS is critical in • Clearly and properly stated preventing scope creep or other unnecessary changes. • Complete. As the system evolves, each new feature opens a world Verifiable A human being or a machine must be able to verify of new possibilities, so the RS anchors the team to the that the system correctly enacts the stated require- original vision and permits a controlled discussion of ments. scope change. Traceable The requirements must be traceable from other de- While many organizations use only documents to sign and test documents. To facilitate the traceabil- manage requirements, others manage their require- ity, each requirement should be uniquely identified. ments baselines using software tools. These tools allow Modifiable Unanticipated changes must be able to be made requirements to be managed in a database, and usually easily. have functions to automate traceability (e.g., by allow- Usable Each requirement must be tied to business values, ing electronic links to be created between parent and identified as a priority for the customer, and appro- child requirements, or between test cases and require- priate to implement by the development team. The ments), electronic baseline creation, version control, RS must be usable by not only the development and change management. Usually such tools contain team but also subsequent maintenance teams who an export function that allows a specification document will be called upon to modify and change the sys- to be created by exporting the requirements data into a tem. standard document application. Consistent Individual requirements must not conflict with each The RS must include an overview of the process in other. Requirements must be consistent as well with overall architectural approach and quality at- order to familiarize the infrastructure and application tribute priorities. developers with the user, business process and data Complete It must contain clear descriptions of all features and acquisition requirements of the system, and any special functions of the system. It must clearly contain considerations for the project. The system functionality definitions of all known situations the system could must be well defined at the outset in order to provide encounter. the prospective supplier or integrator with enough information to provide a detailed and meaningful proposal. Specifically, on data acquisition systems, the RS must • Type of control and process operations to be include data definitions; data usage information; data performed storage, retention, and security requirements; and opera- • Data storage requirements tional requirements and constraints. • Transaction and data timing requirements and The RS addresses the following: considerations • The scope of the system and strategic objectives • Regulatory requirements • Process overview, sequencing requirements, opera- • Preliminary evaluation of the technology tional checks • Feasibility study and preliminary risk assessment • Sufficient information to enable the supplier or • Safety and security considerations integrator to work on a solution to the problem (e.g., • Security, other requirements device-driven sequencing, the methods required of • Non-functional requirements (e.g., SLC develop- the presentation of data, data security, data backup, ment standards, programming language standards, data and status reporting and trending, etc.) program naming convention standards, etc.). • Redundancy and error-detection protocol • Operating environment Each requirement in the RS should have the attri- • Interfaces (e.g., to field devices, data acquisition butes depicted in Table I. systems, reports and HMI), input/output lists, com- The requirements should be verified or tested dur- munications protocols, and data link requirements ing the SDLC. In a classic “V” model, the require- • Information gained from operators and super- ments are tested during the user acceptance testing, visors on the system design requirements and aka the performance qualification (PQ) in the US expectations in order to influence how the system Food and Drug Administration-regulated industries is designed and operated context. This testing should include the verification gxpandjvt.com Journal of Validation Technology [Spring 2011] 81 PEER-REVIEWED

Figure 4: Manage requirements changes. If the change request is accepted, then: Impact Analysis • Generate changed RS and change requests for Updated Requirements other controlled products as applicable and Changed Interface Requirement Manage necessary. Requirements documents • Implement the change. Also, make the necessary Change Request Changes Updated Traceability Matrix modifications to related artifacts: RS, modeling Notiﬁcation of Change to diagrams, QFD, generic specifications, and so on. affected parties • Verify and validate changed RS. • Update and distribute updated documentation of the procedural controls associated with the system as necessary. that were identified in the RS. The exit criteria to this process are as follows: MANAGING • Decision was made through the applicable process REQUIREMENTS CHANGES not to proceed with the change. Once commitments to the requirements are estab- • Updates to requirements made, distributed, and lished and plans have been made, the project will controlled transform from planning mode to execution mode. • Other work product change requests have been During the project execution phase, possible condi- generated as required. tions precipitating a change are as follows: • A new requirement is identified The impact analysis process, as part of the manage • The software project is re-scoped (requirements requirement changes, by itself has multiple steps. This added, dropped, or modified) process must be clearly defined and communicated • An inconsistency is identified between the capa- to the customer as well as to the project team. The bilities of the product developed and the docu- high-level steps of the change impact analysis process mented requirements. include the following: • Get change request Figure 4 depicts that inputs and outputs of the • Expand the demand statement using VOC analysis management of requirements changes. (i.e., who, what, when, where, why, and how). The entry criterion to this process is “A Require- • Analyze engineering impacts ment Change Request has been submitted.” • The “how” yields clues around impacted features The tasks associated with this process include the • Identify, using for example quality function following: deployment (QFD), associated functionality, • Analyze change request for impact and feasibility and design parameters. These design parameters • Prepare an impact analysis statement are the engineering items to be scrutinized to • Determine the disposition of the change request determine their impact. (e.g., accept, reject, defer). • In review meeting(s), analyze if a problem requires only a hardware or machine “tweak” or if it requires a software change • Analyze software impacts The quality system regulation requires a • Using the QFD, identify all the functionalities mechanism for addressing incomplete, (use cases) that are impacted ambiguous, or conflicting requirements. • For each use case, analyze graphical user inter- Each requirement (e.g., hardware, soft- face (GUI) and controller change required using ware, user, operator interface, and safety) the traceability analysis identified in the software requirements • Conduct risk analysis, for example based on specification should be evaluated for accu- failure mode and effect analysis (FMEA), so the racy, completeness, consistency, testability, potential regressive damage due to the change correctness, and clarity. is minimized. —US FDA 21 CFR 820.30(c). • Create the change request impact analysis document and review with customer.

82 Journal of Validation Technology [Spring 2011] ivthome.com ORLANDO LOPEZ

MAINTAINING BIDIRECTIONAL Figure 5: Requirements traceability. TRACEABILITY OF REQUIREMENTS Requirements traceability (Figure 5) is concerned with documenting the origin of a requirement as well as the REQUIREMENTS relationships between requirements and other development artifacts, such as designs, models, analysis results, code, and test plans, cases, procedures, or results. The purpose of requirements traceability is to facilitate the following: DESIGN TEST • Overall quality • Understanding of the product • Tests necessary to verify • Ability to manage change. CODE The intent of this practice is to maintain the bidirectional traceability of requirements for each level of product decomposition (see Figure 6). Figure 6: Forward and backward traceability. The following two types of traceability are recommended: Requirement Design Test • Forward traceability (i.e., to all documents Speci cation Description Case spawned by the SRS). This depends upon each requirement in the SRS having a unique name or reference number. Traceability is an essential aspect during the veri- • Backward traceability (i.e., to previous stages of fication activities in the SLC, and it is an important development). This depends upon each require- input into design reviews. A formal design review is ment explicitly referencing its source in earlier recommended to confirm that requirements are fully documents. specified and appropriate before extensive software design efforts begin. The forward traceability of the RS is especially impor- Table III depicts the traceability activities during tant when the software product enters the operation a typical SLC. and maintenance phase. As code and design documents The practice of requirements traceability is iterative. are modified, it is essential to ascertain the complete It is conducted throughout the SLC and involves the set of requirements that may be affected by those following activities: modifications. • Functionality —defining functional require- It should be possible to trace back to the origin of each ments based on technical assumptions or client requirement, and every change made to the requirement needs should, therefore, be documented in order to achieve • Traceability —setting up and maintaining a traceability. Requirements traceability is also useful requirements traceability system when conducting impact assessments of changes to • Log—updating regularly (at least weekly) the requirements, design, or other configured items. traceability matrix with new information When the requirements are managed well, traceabil- • Communicating —communicating regularly (at ity can be established from the source requirement to least weekly) with stakeholders about the status its lower level requirements and from the lower level of requirements requirements back to their source. Such bidirectional • Log —recording data used to track the require- traceability helps determine that all source requirements ments in the traceability matrix have been completely addressed and that all lower level • Communication —communicating to stake- requirements can be traced to a valid source. holders that a particular requirement has been Table II shows the links that are to be maintained. completed. To demonstrate bi-directional traceability evidence of The traceability of requirements can be built into sorting (and use) by each column is to be captured. documentation and code without having to have gxpandjvt.com Journal of Validation Technology [Spring 2011] 83 PEER-REVIEWED

Table II: Example of links to be maintained. Module/ Test Script Name/ Unique Requirement Configured Item Step Number Requirement ID Description Design Reference Reference Release Reference Reference

a separate traceability document. Three common quality and completeness of the requirements con- approaches are: traceability matrix, using computer tribute to the accuracy of the specification. databases to evaluate traceability, and building inher- The success of computer systems implementation ent traceability into the structure of the documenta- and maintenance depends on these three tasks. As tion and code. Software developers have flexibility depicted on Figure 2, a practical and accurate require- in how they want to implement traceability. ments specification will contribute to the successful implementation of the computer system, on time, ENSURING ALIGNMENT BETWEEN within budget, and on schedule. PROJECT WORK AND REQUIREMENTS Requirements management can achieve the success This practice focuses on maintaining consistency described above if it is maintained throughout the between requirements, project plans, work products, system lifecycle. and, in case of inconsistencies, initiates corrective actions to resolve them. For example, the project plan TOOLS should be revised if changes to the requirements are The following are a sampling of requirements man- identified as impacting the schedule. agement tools. Note that the tools mentioned do Corrective actions taken by the project to resolve not represent an endorsement and are presented for inconsistencies can also result in changes to project information purposes only. In most cases, tool names plans and supplier agreements. are trademarked by their respective developers.

SUMMARY Cybernetic Intelligence GmbH-EasyRM, www.easy-rm. It is necessary to identify, control, and track require- com ments before design and construction of a computer IBM Rational RequisitePro—IBM tool used for require- system can begin. ments management, http://www-01.ibm.com/software/ Requirements management consists of the follow- awdtools/reqpro/ ing five activities: Integrated Chipware–RTM, www.chipware.com • Obtaining an understanding of requirements Rational Software-Rational RequisitePro, www.rational. • Obtaining commitment to requirements com • Managing requirements changes Siemens-Systems Engineering and Requirements, http:// • Maintaining bidirectional traceability of www.plm.automation.siemens.com/en_us/products/ requirements teamcenter/solutions_by_product/systems_engineer- • Ensuring alignment between project work and ing.shtml requirements. Telelogic Inc.—tool used for requirements management, http://www-01.ibm.com/software/awdtools/ The relevance of requirements management to suc- doors/?&ca=qapromo-s0swg-b0swg-l0-d0swgmer- cessfully manage a computer system implementation n0363-o0doors-g0usen/. project is stressed by distributing over 40% of the SDLC on managing requirements The main activities of the requirements management are to meet the VOC and keep updated the requirements specification during the SDLC. The

84 Journal of Validation Technology [Spring 2011] ivthome.com ORLANDO LOPEZ

Table III: Traceability activities and SLC. SLC Phase Typical Traceability Task(s) Comment Requirements • Software requirements to system A traceability analysis should be conducted to verify that requirements (and vice versa) the software design implements all of the software require- • Software requirements to risk analysis ments. As a technique for identifying where requirements are not sufficient, the traceability analysis should also verify that all aspects of the design are traceable to software requirements. Design • Design specification to software A traceability analysis should be conducted to verify that requirements (and vice versa) the software design implements all of the software requirements. As a technique for identifying where requirements are not sufficient, the traceability analysis should also verify that all aspects of the design are traceable to software requirements. An analysis of communication links should be conducted to evaluate the proposed design with respect to hardware, user, and related software requirements. Construction/source • Source code to design specification A source code traceability analysis is an important tool to code/configuration (and vice versa) verify that all code is linked to established specifications • Test cases to source code and to and established test procedures. A source code trace- design specification ability analysis should be conducted and documented to verify that: • Each element of the software design specification has been implemented in code • Modules and functions implemented in code can be traced back to an element in the software design specification and to the risk analysis • Tests for modules and functions can be traced back to an element in the software design specification and to the risk analysis • Tests for modules and functions can be traced to source code for the same modules and functions. Developer’s software • Unit (module) tests to detailed design Control measures, such as a traceability analysis, should testing • Integration tests to high level design be used to ensure that the intended coverage is achieved. • System tests to system requirements User acceptance User acceptance test to system • In a typical “V” model, this is the ultimate test. Each re- testing requirements quirement must map to at least one test case. • Control measures, such as a traceability analysis, should be used to ensure that the intended coverage is achieved. Maintenance After the computer system has been delivered for operations, the forward traceability of the RS is especially important when the software product enters the maintenance phase. As part of the activities to conclude a project, the requirements traceability matrix must be updated with the as-built information. The objective is to have an up-to-date matrix describing how the system final design satisfied the functional, business, security, and technical specifications in the requirements document. As code and design documents are modified, it is essential to be able to ascertain the complete set of requirements that may be affected by those modifications. With the new project, a new cycle begins to the requirements management process. gxpandjvt.com Journal of Validation Technology [Spring 2011] 85 PEER-REVIEWED

GENERAL REFERENCES DISCLAIMERS ASTM, ASTM E 2500–07, Standard Guide for Specification, De- The information contained in this article is provided sign, and Verification of Pharmaceutical and Biopharmaceutical in good faith and reflects the personal views of the Manufacturing Systems and Equipment, August 2007. author. These views do not necessary reflect the per- Bonney Joseph, “Requirements Engineering: Our Best Prac- spective of the publisher of this article. No liability tices,” StickyMinds.com http://www.stickyminds.com/site- can be accepted in any way. The information provided wide.asp?Function=edetail&ObjectType=ART&ObjectId= does not constitute legal advice. The recommenda- 13169&tth=DYN&tt=siteemail&iDyn=37 tions to implement requirements management, as Carnegie Mellon University, Software Engineering Institute, described in this article, are purely from the stand- Capability Maturity Model Integration (CMMI) for Soft- point and opinion of the author, and should serve as a ware, Rev 1.3. suggestion only. There are many other ways to imple- IEEE, IEEE Std 1233-Guide for Developing System Requirements ment requirements management. Some descriptions Specifications, 1998. are based on listed guidelines with judicious editing ISO, ISO 9001-Quality Management Systems–Requirements, were necessary to fit the context of this manuscript. 2008. ISO, ISO/IEC 9126-Software Engineering-Product Quality, 2001. ARTICLE ACRONYM LISTING ISO, ISO/IEC 12207-Systems and Software Engineering—Software C-E Cause and Effect Analysis Life Cycle Processes, 2008. CMMI Capability Maturity Model Integration ISPE/GAMP, “GAMP Traceability for GxP Regulated Appli- DSM Design Structure Matrix cation,” Pharmaceutical Engineering, Vol 26 No 1, January/ FMEA Failure Mode and Effect Analysis February 2006. GUI Graphical User Interface NASA, Software Engineering Documents, http://software. OA Orthogonal Array gsfc.nasa.gov/ISDpaAll.cfm. PQ Performance Qualification US Center for Disease Control (CDC), “Unified Process Prac- QFD Quality Function Deployment tices Guide – Requirements Management,” UP Version RAM Requirements Analysis Matrix 06/30/07. http://www2.cdc.gov/cdcup/. RS Requirements Specification FDA, General Principles of Software Validation; Final Guidance SLC System Lifecycle for Industry and FDA Staff, June 2001. SDLC System Development Lifecycle Additional regulatory or guidance references associated VOC Voice of the Customer with this topic can be found at: PIC/S Guidance on Good Practices for Computerised Systems in Regulated “GxP” Environments (PI 011-3), US FDA 21 CFR 211.68; US FDA 21 CFR 820.30(g), 21 CFR 820.70(i) and 21 CFR 11.10(a). http://en.wikipedia.org/wiki/Requirements_traceability. JVT

86 Journal of Validation Technology [Spring 2011] ivthome.com