Lecture 8 - Requirement Management PDF

Lecture 8 – Requirement Management Requirement Engineering Book Pohl, Klaus. Requirements engineering: fundamentals, principles, and techniques. Fast-National University of computer & Emerging Sciences Assigning Attributes to Requirements Information about the re...

Lecture 8 – Requirement Management Requirement Engineering Book Pohl, Klaus. Requirements engineering: fundamentals, principles, and techniques. Fast-National University of computer & Emerging Sciences Assigning Attributes to Requirements Information about the requirements must be documented throughout the entire life cycle of a system. This includes, for example, unique identifiers of a requirement, the name of the requirement, the author and sources of the requirement, and the person responsible for the requirement. 2 Assigning Attributes to Requirements Attributes for Natural Language Requirements and Models Template-based assignment of attributes to requirements To document information about requirements, it has proven useful to delineate this information in a structured manner: as attributes. Attributes of a requirement are defined by a unique name, a short description of the contents, and the set of possible values that can be assigned to the attribute. For example, the template for functional requirements can be different from the template for quality requirements with respect to the defined attribute types and/or the allowed attribute values. 3 Assigning Attributes to Requirements Attribute Scheme The set of all defined attributes for a class of requirements (e.g., functional requirements, quality requirements) is called an attribute scheme. Attribute schemes are usually tailored to meet the individual project’s needs. Assignment of requirement attributes During the course of the project, the attributes of the requirements are assigned with fitting attribute values. An exemplary assignment of attributes for a requirement including the attributes “identifier”, “name”, and “requirement description” as well as attributes that allow for documenting the stability of the requirements and its source as well as its author. 4 Assigning Attributes to Requirements Attribute Scheme The set of all defined attributes for a class of requirements (e.g., functional requirements, quality requirements) is called an attribute scheme. Attribute schemes are usually tailored to meet the individual project’s needs. Assignment of requirement attributes During the course of the project, the attributes of the requirements are assigned with fitting attribute values. An exemplary assignment of attributes for a requirement including the attributes “identifier”, “name”, and “requirement description” as well as attributes that allow for documenting the stability of the requirements and its source as well as its author. 5 Assigning Attributes to Requirements Attribute Types of Requirements Frequently used attribute types 6 Assigning Attributes to Requirements Additional attribute types for requirements 7 Assigning Attributes to Requirements Project-specific tailoring of the attribute scheme Specific properties of the project, e.g., project size, local or distributed development, or project risk Constraints of the organization, e.g., organizational standards and regulations Properties and regulations of the application domain, e.g., reference models, modeling guidelines, standards Constraints and restrictions of the development process, e.g., liability law, process standards 8 Assigning Attributes to Requirements Definition of attributes by means of information models When employing tools for requirements management, defining the attribute structure of requirements is often not done by means of tables, but is model based, by means of information models. A model-based definition of an attribute scheme determines the attribute types as well as limitations in attribute values, similar to template-based definitions. In addition, model-based attribute scheme definition allows for determining relations between attribute types of different attribute schemes. 9 Assigning Attributes to Requirements Advantages of model-based attributing Along with the advantages of table-based definition, model-based assignment of requirement attributes additionally allows consideration of requirement dependencies when selectively accessing the requirements. This aids in maintaining consistency in the attributes of the requirements. Furthermore, the information model of a model-based assignment of requirement attributes can serve as the foundation for the definition of an attribute structure to be used in a requirements management tool. Also, templates for the assignment of requirement attributes can be generated on the basis of the 10 information model. Views on Requirements Role-specific definition of views Views on requirements are often defined for different roles in the development process. Examples include views for the architect, the programmer, the project manager, and the tester. It is common to define multiple views for a role in order to support the sub-activities of each role. One particular view can also be applied to multiple roles. 11 Views on Requirements Selective Views on the Requirements Foundation A view contains a part of all available requirement information. A view can do the following: Select particular requirements; i.e., not every requirement is contained in a view. Mask certain attributes of requirements; i.e., not every attribute of a requirement is contained in a view. Arbitrarily combine both these selection principles; i.e., only a subset of all available requirements and only a subset of all available attributes are contained in a view. 12 Views on Requirements Generating selective views 13 Views on Requirements Condensed Views on the Requirements Is not immediately contained in the requirements. Generating condensed views can be defined by aggregating the data contained in the requirements basis. A condensed view can, for example, contain information on the percentage of requirements that stem from a particular source. Combination of selecting and condensing a single view may also consist of a combination of generated, condensed, and selected data. 14 Prioritizing Requirements Requirements can be prioritized by their order of implementation, for example. Due to the different prioritizations in the various sub-activities, the priority of a requirement can be determined by one or more attributes (e.g., priority of the contractor, priority due to urgency of implementation). 15 Prioritizing Requirements Method for Requirements Prioritization Determining goal and constraints of prioritization. In order to prioritize a set of requirements, a goal (i.e., purpose) of prioritization must be defined first. In addition, the constraints of prioritization are documented, such as the availability of different stakeholders and groups thereof or the resources available for prioritization. Determining prioritization criteria Cost of implementation Risk Damage due to unsuccessful implementation Volatility Importance Duration of implementation (i.e., how long it takes to be 16 implemented) Prioritizing Requirements Determining Stakeholders By choosing appropriate stakeholders, it can be guaranteed that the required expert knowledge is available during the prioritization process. The stakeholders that ought to be involved are, depending on the goal and prioritization criteria, developers, project managers, customers, or users, for example. Selection of artifacts When Selection of artifacts selecting requirements, one must make sure that the selected requirements stem from the same level of abstraction. Prioritizing requirements from considerably differing levels of detail will lead to inconsistent and erroneous results 17 because stakeholders tend to assign a higher priority to Prioritizing Requirements Selection of prioritization techniques On the basis of the determined properties of the prioritization (e.g., constraints, criteria of prioritization, etc.), a suitable prioritization technique or a combination of multiple techniques is selected. 18 Prioritizing Requirements Techniques for Requirements Prioritization Ad hoc techniques and analytical techniques The spectrum of prioritization techniques spans from simple, single criterion classification to elaborate analytic prioritization approaches, such as AHP (Analytical Hierarchy Process) [Saaty 1980], Cost-Value- Analysis [Karlsson and Ryan 1997], or QFD (Quality Function Deployment) [Akao 1990]. 19 Prioritizing Requirements Ranking and Top-Ten Technique Two well-established techniques for requirement prioritization are, for example, the following [Lauesen 2002]: Ranking: In this technique, a number of selected stakeholders arrange the requirements to be prioritized with respect to a specific criterion. Top-Ten Technique: In this technique, the n most important requirements for a defined criterion are selected. For these requirements, a ranking order is determined afterward. This ranking order represents the importance of the selected requirements with regard to the defined criterion. 20 Prioritizing Requirements Single-Criterion Classification Mandatory: A mandatory requirement is a requirement that must be implemented at all costs or else the success of the system is threatened. Optional: An optional requirement is a requirement that does not necessarily need to be implemented. Neglecting a few requirements of this class does not threaten the success of the system. Nice-to-have: Nice-to-have requirements are requirements that do not influence the system’s success if they are not implemented. 21 Prioritizing Requirements Kano Classification one can classify and prioritize requirements with respect to their acceptance on the market. The three properties in the Kano approach Dissatisfiers: A requirement specifies a dissatisfier that the system mustpossess in order to be successfully introduced to the market. Satisfiers: A requirement specifies a satisfier if the customers consciously demand the associated property. Satisfiers of the system specify the degree of satisfaction of the customer. An increase in the number of satisfiers usually leads to increased customer satisfaction. Delighters: A requirement specifies a delighter if the stakeholders do not consciously demand the defined system property or the stakeholders do not expect the 22 implementation of the property. The customer satisfaction Prioritizing Requirements Prioritization Matrix According to Wiegers Computing requirement priorities is an analytical prioritization approach for requirements. The core of the approach is a prioritization matrix according to which the priorities of the regarded requirements can be determined systematically. Calculation of priorities in a prioritization matrix according to Wiegers 23 Prioritizing Requirements Systematic method to determine the requirement priorities The calculation of priorities in a prioritization matrix according to Wiegers can be done as follows: 1. Determine the relative weights for benefit, detriment, cost, and risk. 2. Determine the requirements to be prioritized. 3. Estimate the relative benefit. 4. Estimate the relative detriment. 5. Calculate the total values and percentage values for each requirement: Value%(Ri) = Benefit(Ri) ×WeightBenefit + Detriment(Ri) × WeightDetriment 6. Estimate the relative cost and calculate the cost percentage for each requirement. 7. Estimate the relative risks and calculate the risk percentage for each requirement. 8. Calculate the individual requirement priorities: 24 Priority(Ri)=Value%(Ri)/(Cost%(Ri) ×WeightCost + Risk%(Ri) Prioritizing Requirements It became apparent in practice that analytical prioritization approaches such as the prioritization matrix according to Wiegers as sketched above demand considerably more time and effort than ad hoc approaches, so these ad hoc approaches are to be favored in many cases. However, analytical approaches have the advantage that the degree of subjectivity in the prioritization results can be significantly reduced so that they lead to more objective and comprehensible results in complex and critical prioritization situations. 25 Traceability of Requirements Advantages of Traceable Requirements : Verifiability Identification of gold-plated solutions in the system Identification of gold-plated solutions in the requirements Impact analysis Reuse Accountability Maintenance 26 Traceability of Requirements Purpose-Driven Definition of Traceability Purpose of traceability information is In order to establish requirements traceability effectively and efficiently, the information to be recorded should be chosen with respect to the purpose that it will serve. In other words, only the information which has a clear purpose for system development or system evolution ought to be recorded. Traceability information that is recorded in this fashion is often sketchy and incomplete, unstructured, and erroneous with regard to its further use. 27 Traceability of Requirements Classification of Traceability Relations Pre-RS traceability and post-RS traceability Pre-RS traceability: Pre-RS traceability are traceability links between requirements and those artifacts that are the basis for the requirements, e.g., artifacts like the source or origin of a requirement (previous artifacts). Post-RS traceability: Post-RS traceability comprises traceability information between requirements and artifacts of subsequent development activities. For example, such artifacts could be components, implementation, or test cases that belong to a requirement (posterior artifacts). Traceability between requirements: The traceability between requirements is about mapping dependencies between requirements. An example of this kind of traceability is the information that a requirement refines another requirement, 28 generalizes it, or replaces it. Traceability of Requirements Types of requirements traceability 29 Traceability of Requirements Example of the three types of requirements traceability 30 Traceability of Requirements Representation of Requirements Traceability The most common approaches to representing traceability are simple textual references, hyperlinks, and trace matrices and trace graphs. Text-Based References and Hyperlinks This simple way to represent traceability information of a requirement consists of annotating the target artifact as a textual reference in the requirement (initial artifact) or to establish a hyperlink between the initial artifact and the target artifact. When linking artifacts, different types of hyperlinks with specific link semantics can be used. 31 Traceability of Requirements Trace Matrices Another common technique for representing and documenting traceability information between requirements as well as between requirements and previous and posterior artifacts in the development process are trace matrices. The rows in a trace matrix contain the initial artifacts (requirements). In the columns, the target artifacts (e.g., sources of requirements, development artifacts, requirements) are represented. If a trace link exists between an initial artifact in row n and a target artifact in column m, cell (n, m) is marked in the trace matrix. 32 Traceability of Requirements Interpretation of a trace matrix Simple trace matrix for the trace relation “derived” that exists between two requirements. An entry in the matrix specifies that a trace link of type “derived” exists from a requirement “Req-n” to another requirement “Req-m” such that “Req-n” was derived from “Req-m”. 33 Traceability of Requirements Maintainability of trace matrices In practice, it became apparent that trace matrices are difficult to maintain as the number of requirements increases. A trace matrix that, for example, documents the refinement relations between merely 2,000 requirements contains over four million cells. In addition, many trace matrices must be created in order to be able to represent the available information cleanly (e.g., with regard to different types of traceability links). 34 Traceability of Requirements Trace Graphs A trace graph is a graph in which all nodes represent artifacts and all edges represent relationships between artifacts. The distinction between different artifacts and types of traceability can be realized by means of assigning different attributes to the nodes and edges of the graph. Trace graph over different development artifacts. 35 Traceability of Requirements Traceability chains If traceability information about previous artifacts (e.g., stakeholders and Traceability chains interview protocols) as well as posterior artifacts (e.g., test cases and components) must be managed, traceability chains for the respective requirement can be created at different levels, up to a trace of the requirement over the entire life cycle of the system. Common tools to maintain requirements allow for the definition of representation levels when creating traceability chains so that, depending on the selected level, only immediate relations of a requirement or entire traceability chains for the requirement can be generated and displayed. The traceability chains are the foundation36 for a comprehensive impact analysis during requirements Versioning of Requirements During the life cycle of a system, the requirements of the system change as new requirements are added and existing requirements are removed or altered. The reasons for changes in requirements are diverse. One possible reason is, for instance, the fact that stakeholders learn more and more about the system as requirements engineering progresses. As a result, new and altered requirements come to their mind. Due to these changes, a suitable versioning of requirements is strongly advisable. Versioning of requirements aims at providing access to the specific change states of individual requirements over the course of the life cycle of the system. The version of a requirement is defined by its specific content of the change state and is marked by a unique version number. 37 Versioning of Requirements Requirements Versions When versioning requirements, one can distinguish between the version and the increment of the version number. For example, the version number 1.2 references a requirement with version 1 and the increment 2. 38 Versioning of Requirements Requirements Configurations Dimensions of configuration management of requirements Managing configurations of requirements can be described in two dimensions]: In the product dimension, configuration management deals with individual requirements within the requirements foundation. In the version dimension, configuration management considers the various change states as part of version management within the product dimension. 39 Versioning of Requirements Dimensions of configuration management of requirements (based on [Conradi and Westfechtel 1998]) 40 Versioning of Requirements Properties of requirements configurations Logical connection Consistency Unique identification Immutable Basis for rollbacks 41 Versioning of Requirements Requirements Baselines Configuration vs. baseline Requirements baselines are specific configurations of requirements that typically comprise stable versions of requirements and, also, often define a release of a system. Due to that property, requirements baselines are usually visible externally (e.g., to the contractor). When requirements baselines are used, a number of important activities in the development process are supported: 42 Versioning of Requirements Basis for release planning: Requirements baselines are configurations of “stable” requirements, specially marked for the contractor. Baselines therefore serve as the basis of communication for the planning of system releases as well as their definition. Estimation of the effort involved with implementation: As baselines of requirements can be used for the definition of system releases, they can also be used to estimate the effort needed to realize a system release. This can be done by estimating the partial effort involved with implementing a requirement of the baseline and summing up the total effort for the remaining baseline. Comparison to competing products: Requirements baselines 43 can be used to compare the planned system to competing Management of Requirements Changes Requirements Changes Reasons for changes : The reasons for changes in requirements can be multifarious. Along with changes that stem immediately from errors or incomplete requirements, the evolution of the context can make it necessary to change the requirements. Changes per se are not negative : Changes in requirements per se are not negative. They are merely an indication that stakeholders deal closely with the system and learn more and more about its functions, qualities, and restrictions. If change requests only occur infrequently during development of the system, it may be a sign of low stakeholder interest in the system to be developed. 44 Management of Requirements Changes Change frequency as an indicator of process quality Requirements changes occur very frequently, the development of a system that is in agreement with all involved stakeholders becomes nearly impossible. A high change frequency is, among other things, an indicator for inadequately performed requirements engineering activities, such as elicitation and negotiation techniques. In addition, a high change frequency takes up a lot of resources in the development project. 45 Management of Requirements Changes The Change Control Board Over the course of the system life cycle, it is necessary to channel change requests for requirements and define a structured process that will lead to a justified decision about whether a change request is approved and how it is approved. The evaluation of requirements changes, as well as the decision about performing the change, is usually the responsibility of a change control board. 46 Management of Requirements Changes Tasks of the change control board Estimate the effort for performing the change (potentially commission a third party with an effort analysis). Evaluate change requests, e.g., with respect to the effort/benefit ratio. Define requirement changes or define new requirements on the basis of change requests. Decide about acceptance or rejection of change requests. Classify incoming change requests. Prioritize accepted change requests. Assign accepted change requests to change projects. 47 Management of Requirements Changes Representatives in the change control board In some cases, the CCB may want to delegate these tasks to another party. Decisions about changes have to be negotiated and agreed upon with the contractor and all involved stakeholders in the development project. Change manager Contractor Architect Developer Configuration manager Customer representative Product manager Project manager Quality assurance representative Requirements engineer 48 Management of Requirements Changes The role of the change manager The chairperson of the change control board is the change manager. The change manager has the task, among other things, of mediating between parties in case of conflicts and to negotiate decisions with the respective parties. In addition, the change manager is responsible for communicating and documenting decisions. 49 Management of Requirements Changes The Change Request Template for change requests. They have to be documented in a purpose-oriented manner. A change request documents the desired change and contains additional information for the management of the change request. 50 Management of Requirements Changes A change request should contain the following information: Identifier: The identifier makes it possible to uniquely identify a change Change information request at any point during the life cycle of the system. Title: The title summarizes the key concern of the change request in one brief statement. Description: The description documents the requirement change as precisely as possible. It can contain information on the effect of the changes as well. Justification: The most important reasons as to why the change is necessary are listed here. Date filed: The date at which the change request was filed. Applicant: The name of the person that issued the change request. Priority (in the applicant’s opinion): The importance of the change request according to the applicant’s opinion. 51 Management of Requirements Changes Management information for the change request The following information for requirements change management is helpful: Change validator: The person that verifies if the change has been performed correctly. Impact analysis status: Flags whether an impact analysis has already been performed on the change request. CCB decision status: Flags whether the change control board has already decided upon the change request. CCB priority: Documents the priority of the change request assigned by the change control board. Responsible: Documents the person that is in charge of performing the change request. System release: Documents in which system release the changed requirement shall be implemented. 52 Management of Requirements Changes Classification of Incoming Change Requests Corrective, adaptive, and exceptional changes : Corrective requirement change: A change request is classified thusly if the reason for the change request is a failure of the system during its operation that can be attributed to an error in the requirements. Adaptive requirement change: A change request is thusly classified if a requested change requires the system to be amended. A possible reason for an adaptive requirement change can be a change in the system context, e.g., a new technology is available or the system boundary was altered. Exceptional change (hotfix): A change request is classified as an exceptional change if the change must absolutely immediately be done at all costs. Exceptional changes can 53 Management of Requirements Changes Different processing methods The method for processing requirements changes depends on their classification. For example, exceptional changes must be analyzed, evaluated, decided, and potentially implemented right away. Contrastingly, adaptive requirement changes are often processed in batches at a later point in time, typically as soon as the next (or some subsequent) system release is imminent. On the other hand, corrective requirement changes are usually analyzed, evaluated, and if necessary implemented rather promptly after the change request has been filed. 54 Management of Requirements Changes Basic Method for Corrective and Adaptive Changes Method for handling change requests 55 Management of Requirements Changes Impact analysis During impact analysis, the effort for performing the change is estimated. In order to do so, all requirements affected by the change are sought out, including any newly defined requirements. Afterward, the posterior development artifacts that potentially will have to be changed or redeveloped are identified (e.g., test cases or components). For each affected artifact, the effort for implementing the change is determined and the total effort for the change is computed by summing up all partial efforts. The consistent integration of the changes into the requirements basis often only negligibly influence the total effort. The most significant portion of the total effort is usually generated by the necessary adaptations of the 56 Management of Requirements Changes Using traceability information Identifying those requirements and posterior development artifacts that are affected by a requirements change can be automated or at least supported by means of traceability information. If no or not all necessary traceability information is available, domain experts or experts of the development team should be questioned with respect to the consequences of the change request filed. Evaluating a change The change control board evaluates the change filed. In order to do that, cost and benefit are compared and evaluated with regard to the available resources. For example, the benefit of the change can be the avoided loss in prestige, improved 57 Management of Requirements Changes Implementing approved changes In the next step, approved changes are prioritized by the change control board. Afterward, the requirements changes are assigned to a change project or the next (or any subsequent) system release for implementation. Validating the requirement changes Planning, control of the implementation, and validation of the successfully applied changes are typically the responsibility of the change manager or of the change control board and may be delegated, of course. 58  Summary Requirements management is a core activity of requirements engineering. It’s the aim of this activity to maintain persistent availability of the documented requirements as well as other relevant information over the course of the entire system or product life cycle, to structure this information in a sensible manner (e.g., by means of requirements attributes), and to ensure selective access to this information. The management of requirements comprises techniques of the following categories: Assigning attributes to requirements: In order to allow for requirements management, properties of requirements are documented by means of requirements attributes. Prioritizing requirements: Requirements are prioritized at different points in time, during different activities, and according to different criteria. Depending on the goal of prioritization and the subject of prioritization, different 59 prioritization techniques are to be used.  Summary Traceability of requirements: During requirements management, traceability information of requirements is recorded, organized, and maintained so that information about cross references and dependencies between requirements or between requirements and other development artifacts can be used. Versioning of requirements: Versioning and configuring requirements makes it possible to keep information about specific developmental states of requirements and requirements documents available over the course of the life cycle of the system or the product. Management of requirements changes: Usually, the change control board is responsible for processing change requests. The change control board decides if a change request 60 is approved or rejected and prioritizes it. The board also References Pohl, Klaus. Requirements engineering: fundamentals, principles, and techniques.(Chapter 8). 61