UNIT 7 CHECKING AND RECONCILING REQUIREMENTS

Question 1

Why should requirements be validated, what could happen if wrong/erroneous requirements are selected and how could it impact the project progress?

Answer 1

1. The process for reviewing and reconciling is designed to release the requirements for implementation in the downstream phases of the software project. The quality of the elicited and documented requirements must be assured before they are processed further.
2. This is necessary because all further activities, such as the software development process, depend directly or indirectly on the documented requirements. Any error in the requirements that is not detected at an early stage is propagated via the technical specification and architecture through to the program code. A faulty requirement can usually be easily corrected, but by reformulating it in requirements engineering (RE), significant additional
   effort is required when correcting errors in the software architecture or program code.
   However, a considerable amount of effort has already been invested in the creation of erroneous code at this point, and the correction of the errors requires further effort. In
   addition to correcting the errors, the system must be tested and put into operation. By carefully checking the requirements with comparatively little effort, errors that can be expensive to identify and correct in subsequent phases can be resolved earlier.
   Furthermore, inadequately checked requirements can entail legal risks. In addition to contractual penalties due to non-compliance with delivery times, there is also the risk of vio-
   lating legal requirements, such as the Data Protection Act, which can lead to legal consequences.
3. In addition to checking requirements for their technical and craftsmanship quality, it is particularly important that technical requirements are agreed on by all relevant stakeholders. The set of requirements released for implementation corresponds to the work order of a software project. The implementation of requirements in a system always requires effort. In addition, once requirements have been implemented, they cannot be
   easily removed from the system. Therefore, an established and project-accompanying coordination process helps to select the most important requirements to be implemented. Process models that support evolutionary development, such as the requirements to be processed, are redefined for each cycle.
   Coordination between stakeholders is required as soon as contradictions have been identified in the set of documented requirements. If the conflicting requirements come from different stakeholders, each of whom are also pursuing conflicting goals within the project, a conflict situation exists. Another trigger for a conflict is the identification of a contradiction between the documented requirements and the view of a stakeholder. Reasons for this situation can be, for example, changing the requirements of a system during the course of the project, or incomplete requirements elicitation.
   Practice shows that conflicting requirements often result from a different understanding of terms, responsibilities, and the motivation for the project. The goal of coordination is to achieve a common and consistent understanding of the set of requirements among the stakeholders. Conflict management tools must be used to resolve the conflict while maintaining the stakeholders’ willingness to cooperate.

Question 2

Name and define the four activities of the Reviewing and Reconciliation processes.

Answer 2

1. Define Review Criteria: in the run-up to the review, the exact criteria required for the review must first be defined.
   There are so many possible review criteria that not all of them can be considered equally, especially when reviewing extensive documentation or when there is time pressure.
   Therefore, the relevant review criteria must be determined in advance. This largely depends on the project situation, the type and importance of the requirements, the time available, and the people scheduled for this. The requirements engineer is responsible for the creation.
2. Select Review Principles and Review Techniques: only after it has been decided which review criteria are actually relevant and it has been determined how many resources are available for the review, the review principles and review techniques are taken into account and appropriately selected.
3. Perform Review and Document Results: once the technical preparation is finalized, an organizational audit must be planned. This includes organizing the required infrastructure, scheduling all of the participants, and, if
   necessary, coordinating external experts. It is important to document the results of the audit. Troubleshooting and revising the documented requirements takes place afterwards, and is not part of the audit.
4. Reconcile Requirements and Manage Conflict: if contradictory statements were identified in the set of documented requirements during an audit, or if there are contradictions between stakeholders and documented requirements, these contradictions must be reconciled, and, if necessary, the conflicts must be resolved using suitable conflict management measures.

Question 3

What does reviewing a requirement entail?

Answer 3

A review is a manual examination of work results. For example, this is carried out by examining, questioning, checking, and testing. The latter is performed when the object to be reviewed is a piece of software or an executable system. Testing is therefore understood as part of a review or as a special type.
A complete examination of requirements according to all conceivable criteria is not possible in practice, since the effort involved would not be economically reasonable in relation to the benefit. For this reason, there are various review criteria in RE literature, each of which focuses specifically on one aspect. For example, it is possible to distinguish between the three quality aspects of content, form, and coordination. They, in turn, are oriented to the goals of RE.
With the help of the quality aspects, the set of review criteria is structured in such a way that, when selecting the criteria, one can first identify the relevant quality aspects and then select the relevant criteria from the set of review criteria assigned to the quality aspects.

Question 4

Name and describe the Review Criteria for Content Quality.

Answer 4

• Completeness of all requirements: where all of the documented requirements are considered.
• Completeness of individual requirements: each individual requirement is examined in order to determine whether
  all relevant information for describing this requirement is available.
• Necessity of requirements: A requirement is necessary when it describes a stakeholder’s desire, or the goal of the
  development of a system or product. The description can be a function, service, or restriction. The requirements management procedures should ensure that the requirement is not only necessary, but also current and valid. This involves checking how relevant or necessary the requirement is for achieving the fomulated goal. All requirements are frequently documented, which the stakeholders find important at the moment of determination. However, not all requirements contribute
  equally to the achievement of the project goal. Therefore, this criterion is used to specifically reflect on each requirement and to what extent it actually contributes to the project goal. It is also worth noting that requirements should be “atomic” and indivisable. This is because it is easier to administer single features in a requirement and incorporate any changes. Connected requirements, which form a molecule to stay in the picture, can be linked by a corresponding entry in the metadata or attributes.
• Traceability: additional attributes or metadata of the requirements are needed. The requirements engineer should check whether the necessary information is documented. The active management of traceability, which should not be confused with revision management, helps the requirements engineer by using the requirements metadata. Requirements which are only valid until a certain date are marked by metadata using the appropriate notice. There are pre- and post-requirements for traceability.
• Adequacy: (also referred to as correctness) refers to the stakeholders’ wishes. In this case, we check whether the documented requirements reflect what the stakeholders wanted.
• Consistency: involves checking whether there are contradictions or inconsistencies in the set of documented requirements.
• No premature design decisions and technically solution-neutral: In this case, we check whether the requirements already specify how they need to be fulfilled without any binding organizational or legal boundary conditions. Requirements documents often impose unnecessary technical restrictions on input fields. Such requirements may still originate from old implementations. This is because these restrictions often conceal cross-references to dependencies that may not yet have been identified.
• Documentation of the domain-oriented problem: This process involves checking whether the domain-oriented problem can be identified for each documented requirement.
• Verifiability and testability: Verifiability or testability involve checking to see whether the corresponding acceptance
  criteria and test cases for the acceptance tests can be created from the requirement documentation. The created system is tested with test cases that are created on the basis of the documented requirements. Therefore, the requirements must be formulated in such a way that their implementation can be checked after completion of the implementation.

Question 5

Why Does a Requirement Specification Need Traceability?

Answer 5

Traceability supports different kinds of analyses, including:
* impact (collateral changes). Which requirements or artifacts are affected by changes?
* origin. Why does a requirement or artifact exist?
* coverage. Were all the requirements or artifacts considered for a complete solution?
* performance. How is the work progressing?
Professional traceability requires more than a unique requirement number. In this case, a traceability matrix (TM) (determines the completeness of a relationship) should be maintained, which is probably one of the most valuable methods, but it is almost never done. This is because maintaining a TM is time-consuming and error prone. Even if the matrix is partly generated by a machine, there is usually a high organizational and operational effort for its step-by-step completion, updating, and versioning. Tools, such as objectiF RPM, offer lean traceability to use most of the advantages with minimum maintenance effort.

Question 6

Name and describe the Review Criteria for Documentation.

Answer 6

• Conformity to the document structure: This process involves checking whether the requirements have been documented in the correct place and whether all the required elements of the document structure have been
  completed.
• Comprehensibility: involves checking whether the formulated text can be understood by the reader and whether technical or project-specific terms and abbreviations are explained in the glossary.
• Unambiguity: This process involves checking whether the requirements can be understood exactly as they were intended or whether the form of documentation allows an unacceptably high degree of scope for interpretation.
• Conformity to documentation rules: The process of conforming to documentation rules checks whether the requirements have been documented in accordance with the current modeling conventions or other regulations. For example, there are often organization-specific requirements, e.g., according to which scheme or in which sequence requirements are to be documented, or which modeling languages are used for which purpose. Here, it is important to consider whether the documentation complies with current regulations.
• Conformity to documentation format: This process involves checking whether the requirements are documented in the prescribed format intended for this purpose and using the prescribed applications.

Question 7

Name and describe the Review Criteria for Conformity.

Answer 7

• Coordination of each requirement: For this criterion, the extent to which the set of requirements has already been coordinated with the stakeholders after documentation is checked.
• Coordination after changes to requirements: This process consists of checking whether requirements that have already been reconciled were made after changes were incorporated into the documentation. This becomes particularly necessary when dependencies between requirements result in changes that were not originally predicted.
• Conflicts resolved: This process is implemented to check whether all identified conflicts between stakeholders have been eliminated and the contradictions in the set of documented requirements have been resolved.
• Approval granted: Before the requirements are implemented, they must be explicitly released. In contrast to
  a functional agreement, the granting of release means deciding that implementation may begin on the basis of the current status. Under certain circumstances, this can also be the case if not all quality aspects have been fulfilled, but implementation should nevertheless be started. The implementation of agreed upon requirements can also be postponed because requirements have been reprioritized. In this case, it is important to note whether or not the release for implementation has been given.

Question 8

Describe the First Testing Principle.

Answer 8

Involvement of the Right Stakeholders.
For the review of the requirements, the reviewer and the creator should be different people. Ideally, the requirements should be reviewed by independent persons who, as reviewers, have no conflicts of interest as part of their review activities. The selection of the specific auditors or reviewers should therefore depend on the objective of the audit and the requirements to be audited. The involvement of an external reviewer is recommended in particular for the review of special professional or technical aspects in which the project team is not very experienced but are considered critical. In order to obtain the advantage of an early review with the chance of discovering errors, it may be useful to ask internal employees to review or test at an early stage and only call in the external reviewer after an appropriate level of quality has been achieved.

Question 9

Describe the second Testing Principle.

Answer 9

Separation of Fault Detection from Fault Correction.
The basic idea behind this principle is to concentrate exclusively on the documentation of defects during the inspection. Only after the inspection is the assessment of the alleged defects and their consolidation carried out. The correction of the defects only takes place after the consolidation. This is to ensure that the time scheduled for testing is used for testing and not for correcting.
For example, in requirement F-R-1 and F-R-3, the authentication method on a system may be inconsistently described. In this case, this deficiency is documented, but not resolved. It may be that there really are two authentication methods, but this is not explained until
later in the document.

Question 10

Describe the third Testing Principle.

Answer 10

Testing and Reviewing from Different Perspectives.
The principle of testing from different perspectives is intended to ensure that the documented requirements are viewed and analyzed from as many different viewpoints as possible. The concept of different views is used in RE, both as an investigation technique and in perspective-based reading in testing.
For example, in testing, the user focuses exclusively on functionality, the tester focuses exclusively on the testability of the requirements, and another representative of the users focuses only on usability aspects.

Question 11

Describe the fourth Testing Principle.

Answer 11

Appropriate Change of Documentation Form.
The basic idea of this test principle is to transfer documented requirements into another form of documentation. During the transfer, the original documentation is intensively read and analyzed, and possible errors or gaps are identified. A typical use case for the change of documentation form is the verification of processes described as text by transferring them to a process model or a unified modeling language (UML) activity diagram. In practice, it has been shown that, when processes are formulated, the behavior in the event of an error, such as a failed test, is often not described.
For example, a process described in text form for data exchange between two applications is modeled as a UML diagram. The diagram is then used to check whether the text correctly reflects the requirements.

Question 12

Describe the fifth Testing Principle.

Answer 12

Construction of Development Artifacts.
The construction of development artifacts directly checks the usability of the documented requirements in the downstream phases of the software process. Typical use cases are the exemplary construction of design artifacts or the creation of concrete test cases. Here, elements of the requirements documentation are used as planned in later phases.
For example, the test cases for the acceptance test are created from the functional requirements. The construction of development artifacts is very complex and is therefore suitable only for very risky requirements.

Question 13

Describe the sixth Testing Principle.

Answer 13

Repeated Testing and Reviewing.
RE is iterative, but it is not possible to plan a meaningful sequence of core activities at the beginning of a project. Therefore, the amount of documented requirements changes depending on the knowledge gained by the stakeholders. In addition, dependencies between individual requirements are only recognized during the course of the project, which also leads to changes in the documentation. Therefore, the unique successful examination of requirements is no warranty for the fact that the requirements still withstand an examination later in the project. The repeated testing of requirements is therefore a testing principle that is particularly relevant if a larger amount of adaptations must be taken into account over the duration of the project. In addition, requirements should be repeatedly checked if they are to be adopted in a system other than the one originally conceived.
For example, requirements for the data exchange between an ordering system and a delivery system should be transferred to a replenishment system. This requires a re-examination of the requirements.

Question 14

Describe the Statement Testing Technique.

Answer 14

The simplest review technique is an informal opinion. In this case, the requirements documentation is read by a person who is independent and uninvolved in the documentation
of the requirements. The documentation is evaluated with regard to the relevant review criteria. Without the specification of review targets, the results may not be completely usable.
Deficiencies are marked in the document and briefly explained. The statement can be carried out, for example, by a colleague or an external service provider. The process does not follow any particular pattern or specifications.

Question 15

Describe the Walkthrough Testing Technique.

Answer 15

In a walkthrough, the document is read by several people, and the identified defects are discussed in the group. Here, the roles of author, reviewer, and recorder must be assigned. This review technique proceeds with five steps:
1. The documented requirements are distributed to the reviewers and the relevant review criteria are named.
2. The reviewers are given sufficient time to check the document individually with regard to the criteria mentioned, and, if necessary, to note any deficiencies.
3. The author, all reviewers, and a minute-taker meet for a walkthrough session. There, the author presents and explains the requirements to be reviewed step by step.
Depending on the size of the group and the discipline of the participants, a moderator may also be involved to lead the session.
4. Once the author has arrived at the requirements in question, the reviewers present the deficiencies found, and explain and discuss them among themselves. In addition
to the deficiencies identified in advance, quality deficiencies may still be identified during the meeting.
5. The minute-taker is responsible for noting the deficiencies so that the authors can revise the document as needed following the meeting.
A formal version of the walkthrough is an inspection.

Question 16

Describe the Perspective-Based Reading Testing Technique.

Answer 16

Perspective-based reading is a technique that can be used in combination with a review (e.g., an opinion or walkthrough). The reviewers are not supposed to read the document
from a general perspective, but they are assigned specific perspectives from which they are to evaluate the requirements. Which perspectives are chosen depends on the current project situation. Specific role perspectives can be assigned. For example, one reads from the customer’s perspective, another from the tester’s perspective, and another from the software architect’s perspective.
Another possibility is to orient the perspectives based on the relevant test criteria. For example, if nine relevant criteria have been identified and three reviewers are available,
the criteria can be divided among the reviewers. This way, each reviewer does not have to keep track of all aspects, but can focus on the criteria assigned to them. The errors are
then consolidated, so that the reviewers can also exchange information among themselves regarding any errors found.
By distributing such concrete review assignments, parallelization is achieved, which means that even large requirements documents can be reviewed efficiently from various points of view. If a requirements document is to be read by more than one person, it is helpful to consider beforehand whether useful perspectives can be identified or the review tasks can be divided.

Question 17

Describe the Use of Checklists Testing Technique.

Answer 17

Checklists are used to ensure that no task is forgotten during a review. They work as an important aid in many different areas of everyday private life and industrial processes. For example, checklists help in the compilation of private luggage for long journeys or mountain expeditions, and are also helpful for aircraft pilots when carrying out the system check before the aircraft takes off. Checklists can also provide valuable support when checking requirements so that no aspects are forgotten in complex situations.
Experience from past projects can be useful to refer back to when creating checklists for quality assurance of requirements, internal organizational guidelines and specifications, relevant test criteria, and test principles. Depending on the availability of checklists, existing checklists can be reused, or project-specific checklists can be created. The creation of project-specific checklists is particularly useful for the repeated review of large documents. This serves as a guide for the reviewer when working through the requirements to maintain focus and ensure that all relevant questions or review criteria have been taken into account. Checklists can be combined well with perspective-based reading. This way, the relevant questions can be formulated and documented specifically for each perspective. It is advantageous to formulate specific questions on a checklist that is no longer than one page. This way, the reviewer always has all aspects in view in a form that is clear
and understandable.

Question 18

Describe the Test by Prototypes Testing Technique.

Answer 18

Another review or test technique that is not limited to reading and evaluating documented requirements is testing using prototypes. Prototypes are also suitable as a documentation technique. When using prototypes, the activities of determination and testing cannot always be clearly distinguished from each other. The basic idea of using prototypes to test requirements is to provide stakeholders with their own understanding of the requirements determined by constructing system artifacts. Based on the prototype, the stakeholders can then evaluate whether their common requirements were understood in this way without having to construct a complete system. Due to the relatively simple changeability of prototypes, testing, coordination, and revision can be carried out in several cycles.

Question 19

Describe the typical tasks in conflict management related to RE.

Answer 19

1. Conflict Identification: Before a conflict resolution is possible, it must be identified. Conflicts in RE can basically
   be identified at any time. The identification of conflicts during elicitation requires a high level of attention and sensitivity on the part of the responsible requirements engineer. Conflicting technical requirements are often not obviously recognizable as such. Under certain circumstances, only the software architect knows the technical relationships and dependencies. It is therefore
   advisable to involve the software architect when analyzing requirements for contradictions.
2. Determination of the Conflict Type: If the presence of a conflict has been identified, the first step should be to analyze what type of conflict is involved. For this purpose, conflicts can be assigned to different conflict types. This classification then helps in the selection of the solution strategy. It should be noted, however, that, in practice, one conflict often bears the characteristics of several conflict types. Therefore, the types cannot always be sharply distinguished from each other. Rupp & Die SOPHISTen identified several conflict types:
   * Factual conflict: is typically characterized by the presence of incorrect or insufficient information, or a different interpretation by the stakeholders.
   * Conflict of interest: if stakeholders have different interests or goals with regard to the system or the software project, a conflict of interest exists.
   * Conflict of values: a conflict of values is characterized by individual ideals and cultural differences.
   * Relational conflict: relational conflict exists when stakeholders have personal conflicts among themselves that are not directly related to the system, but are expressed in the way they communicate. Typical characteristics are poor communication, disrespect, insults, and strong emotions.
   * Structural conflict: a structural conflict exists when the conflicting parties have different power or decision-
   making authority.
3. After an identified conflict has been analyzed for its characteristics, it must be resolved. A key challenge in conflict resolution is maintaining the willingness of the stakeholders affected by the conflict to cooperate, even after the conflict has been resolved. Therefore, it is important to involve all relevant stakeholders in the resolution in order to achieve acceptance of the solution reached by all parties.
   A selection of possible solution strategies includes:
   * agreement. The conflict is resolved through the exchange of information, arguments, and discussions. The conflicting parties agree on and describe a solution.
   * voting. All relevant stakeholders vote, and the solution that receives the pre-determined required number of votes is implemented.
   * upper-lower. The conflict party with more power or higher authority decides.
   * pro-contra list. For each of the conflicting requirements, the advantages and disadvantages are examined and compared.
   * value-oriented analysis. For each of the contradictory positions, the value created by their implementation is determined. Then, the one whose implementation brings the greatest value to the company is realized.
   * postponing the solution. This strategy does not resolve the conflict, but postpones the solution until a later point in time. The approach makes sense if it is foreseeable that
   there will be a significant gain in knowledge in the future that will allow the conflict to be easily resolved. In addition, downgrading conflicts to unimportant requirements can
   prevent the project team from dwelling too long on insignificant trivialities.
4. Documentation of Conflict Resolution: After conflict resolution, the responsible requirements engineer must ensure that the conflict, its resolution, and the procedure for finding a solution are suitably documented. This is the only way to prevent the same conflict from arising again later in the project and having to be resolved again. If the conflict does arise again, however, it can be ended quickly by referring to the solution that has already been found. On the other hand, it may turn out that the solution found is not suitable. In this case, the documentation can be used to retrace the decision-making process and take it into account when developing another solution.

Answer 20

Requirements engineering is complicated, because many of the requirements can be interdependent, complex, and difficult to formulate for everyone involved. First and foremost, it is important that the stakeholders understand the requirements correctly. This should also be subject to detailing, change, and coordination processes. In addition, there needs to be traceability so that it is still possible to find out later who changed something, when, and why it was changed.
The requirements engineer should not succumb to the temptations of known and available tools. The following special tools have been developed for RE to make the requirements engineer’s job easier and reduce any possibility for error:
* tracking the change history with the possibility of rollback
* tracking releases
* creating reports with statistics
* informing stakeholders with up-to-date information, and communicating with them
* managing the relationships between requirements
* managing documents related to requirements and their version management
* creating and managing Business Process Modeling Notation (BPMN) process diagrams
* creating and managing UML diagrams
A tool should support as many of these tasks as possible. It is also advantageous if the tools work with databases so that, for example, the same objects used in diagrams are
treated as representations of one instance, and changes to them are automatically applied to all their representations without the need for manual rework. Especially when using modeling processes, errors can be reduced if, for example, the rules of the method are implemented in the tool, and incorrect or misinterpreted connections can be automatically prohibited or checked in a validation step.
If several tools with different scopes of work are used in a project, the effort to keep the content consistent increases if the tools do not have automatic interfaces that facilitate
the exchange of data. Representational State Transfer (REST) application programming interfaces (APIs) or extensible markup language (XML) interfaces are easy to use and configure.