Requirements Engineering (RE) - A Summary PDF

UNIT 1 - FUNDAMENTALS AND TERMS OF REQUIREMENTS ENGINEERING 1.1 REQUIREMENTS ENGINEERING IN THE SOFTWARE PROCESS Before the construction of the software in a software project can begin, the system’s goal must be determined. In a waterfa...

UNIT 1 - FUNDAMENTALS AND TERMS OF REQUIREMENTS ENGINEERING 1.1 REQUIREMENTS ENGINEERING IN THE SOFTWARE PROCESS Before the construction of the software in a software project can begin, the system’s goal must be determined. In a waterfall-type project, there is one set of goals—the goals to be fulfilled by the system in development. For example, in Agile projects carried out using Scrum, goals appear at different levels. These goals should not be changed in an Agile project without careful consideration, even if the method used to achieve them can be Agile. The goal should be achieved in one sprint and is regarded as a stage goal. In Agile system development, in addition to the business goals or visions, the overall aim is to deliver executable software to the customer at the end of each iteration. For a requirements engineer, it is important to obtain or create high-quality objectives. Rupp and Die SOPHISTen (2014) define requirements engineering (RE) as a collaborative, iterative, incremental process. Its goal is to ensure that all relevant requirements are known and understood to the required level of detail. all requirements are documented according to the documentation requirements, or specified according to the specification requirements. the involved stakeholders agree on the known requirements. RE activities always involve several people or groups who must cooperate with each other. Specifically, these are people whose sphere of work is affected by, or comes into contact with, the system being created. One must also consider those whose work is involved in the creation process of the system. All affected or involved persons are called “stakeholders.” RE is not a single activity that can be completed at the beginning of a software project; it occurs in multiple cycles (called iterations). By performing RE activities multiple times, requirements for the system are elicited and refined. Since software engineering is a knowledge-driven process, RE usually takes place throughout the project. Purpose of requirements Requirements serve as a basis for communication, discussion, and argumentation for all involved in the system development process. The requirements engineer’s task is to reflect on and develop the common understanding and knowledge of the team members. Only then can the requirements engineer discuss the development process with the knowledge holders. Requirements serve as the basis for: communication, determination of rationalization potentials, optimization of customer benefit, tendering and contract design, system architecture, testing and acceptance, system integration and maintenance, troubleshooting and further development, and increasing employee and customer satisfaction. 1.2 CORE ACTIVITIES IN REQUIREMENTS ENGINEERING In this section, we will examine some of the core activities in RE. These include the determination and documentation of requirements, as well as checking and reconciling them. The section will also cover management practices related to RE. Requirements determination In companies, requirements are also created or imposed on products or services in a wide variety of areas. If you look at jobs within companies, you will always find activities in their role descriptions that are directly related to requirements analysis or, more precisely, to a requirements engineer. The results of development projects without this insurance are evident in the following well-known examples. Toll Collect in Germany Toll Collect had big goals: The state was supposed to collect several billion euros annually. Due to various technical difficulties and the complex and complicated construction, the system could not be put into operation until the beginning of 2005. As of 2021, contractual penalties and lost revenue are being claimed, and some of these issues are still being negotiated. Denver baggage debacle Among other things, it consisted of a rail network, thousands of baggage carts and engines, and hundreds of computers. However, the system did not have enough fault tolerance, there were network problems, the software was too complex, and the cost of the realization was far higher than initially estimated. The opening of the airport was delayed by 16 months. Re and Related Management Practises In the Information Technology Infrastructure Library (ITIL) framework, problem management is a process that is responsible for the sustainable resolution and prevention of problems and disruptions, which is achieved by addressing these issues in normal operations. Alongside proactively solving problems, problem management recommends changes by submitting requests for change (RfC) to change management. Change management aims to manage RfCs efficiently and avoid negative effects on service quality due to changes. Change management activities include managing, documenting, and authorizing RfCs based on impact analyses, as well as planning and coordinating the implementation of changes. Innovation management is a combination of the management of innovation processes and change management and is the subject of ISO. Systematic innovation processes require systematic documentation to provide sufficient data for the cost-benefit analysis and ensure that new concepts are well thought out and confirmed. Business process analysis aims to analyze and document the processes within an organization to find obstacles, bottlenecks, and shortcomings. This helps organizations prepare corrections. Portfolio management is the art and science of selecting and overseeing a group of investments, activities, or projects that meet the long-term objectives of a company. 1  Requirements Documentation The goal of the “documentation” activity mentioned in the previous figure is to ensure that the current state of knowledge is secured for all stakeholders and everyone involved can obtain an overview at any time. If parts of a software or hardware product are produced and delivered by several companies, the requirements specification flows into the contracts between the involved parties, including test cases for the acceptance of the deliveries. Checking and Reconciling Requirements As part of the quality assurance of requirements, it is essential for the requirements engineer to regularly check whether they are still updated or require further adjustment. This enables the traceability of changes, such as the status of the requirement, the reason it was changed, its maturity level, and whether it still needs to be refined. The Knowledge Areas of the Software Engineering Body of Knowledge (SWEBOK) defines three maturity levels of requirements (Bourque & Fairley, 2014): 1. The information does not need to be complete or coordinated. Examples may be sufficient. 2. The information should be reliable and resilient; however, it does not have to be complete. 3. The information should meet all quality criteria for good requirements. Particular emphasis is placed on completeness and correctness. For a line-by-line interpretation of the following table, look at the conceptual model as an example. A conceptual model is not absolutely necessary for the execution of the system requirements discipline (— in the corresponding cell, as shown in the figure below), but it is needed for the execution of the other four disciplines in maturity level three. 1.3 WHAT IS REQUIREMENT? Relationship between problem, requirement, and system (solution) Rather, they are told about a system or product that could solve this problem, or something the interviewee assumes would be helpful. The requirements engineer will therefore make the context clear to all stakeholders, as shown in the figure below. Types of Requirements There are three major types of requirements: 1. Functional requirements that concern the result of a behavior to be provided by a function of the system (or component of a service) 2. Quality requirements, including a more detailed description of quality, such as response times of a software, minimum availability, time for restart, maximum data loss in case of failure, validation, or verification of the software 2 3. Constraints or requirements that limit the solution space beyond what is necessary to meet the given functional and quality requirements In practice, there are many requirements that are classified as non-functional requirements (NFR) and which, for other authors, form a separate category. In fact, NFRs, like those in the following examples, can be sorted into technological requirements. A requirement to provide the desired function of specific technologies, techniques, hardware, and software may be understood as constraint. user interface requirements. These include the design according to internal or generally accepted design features and the use of end devices with different operating systems, browsers, etc. These may be understood as quality requirements, such as requirements for the scope and language of documentation. legal-contractual requirements. Examples include delivery time, guarantee and warranty periods, and contractual penalties. maintenance requirements. This category includes requirements such as like the handling of incidents, the designation of response times, and repair times. The International Institute of Business Analysis (IIBA) has a different view on requirements and decides between the following (International Institute of Business Analysis, 2017): Business requirements are “statements of goals, objectives, and outcomes that describe why a change has been initiated. They can apply to the whole of an enterprise, a business area, or a specific initiative”. Solution requirements “describe the capabilities and qualities of a solution that meets the stakeholder requirements. They provide the appropriate level of detail to allow for the development and implementation of the solution. Solution requirements can be divided into two sub-categories”. The sub-categories are functional and non-functional. Transition requirements “describe the capabilities that the solution must have and the conditions the solution must meet to facilitate transition from the current state to the future state, but which are not needed once the change is complete”. They also cover “data conversion, training, and business continuity”. Classification of Requirements According to their Legal Bindingness Bindingness is often used in connection with contracts, as the legal classification determines which parts of the contract are legally enforceable. Usually, legal bindingness is expressed by using certain modal verbs when the requirements are formulated in natural language. 3  The role of the Requirements Engineer The requirements engineer connects the most diverse areas. They are the mediator and therefore have many internal and external interfaces, primarily with the eventual users of the system. Therefore, they must have great sensitivity for the needs of the project participants. The role of the requirements engineer does not always have to be performed by a person who has a background in computer science. How the procedure of Requirements Creation is handled in practice After the requirements engineer, if applicable, has clarified the framework conditions and goals of the project with the project manager, both should think about which requirements are needed and when, and how these requirements can be compiled. Estimated costs and benefits of a requirement are contrasted in the system analysis, after which the requirements should be identified, formulated, checked, and evaluated. How expensive a technique is for a project depends on how costly it is to implement, how much experience the requirements engineer has with the technique, and how long the stakeholders and requirements engineers can be engaged. UNIT 2 - DETERMINATION OF REQUIREMENTS INTRODUCTION The system for which the requirements are determined has to fit into reality later, so the environment of the system must first be analyzed to define the necessary sources of requirements for the system. The requirements engineer has to perform four steps: 1. Determine system context. An analysis of which stakeholders and other systems have direct dependencies on the system in development will be carried out in order to get an idea about the specific sources of requirements. 2. Identify sources of requirements. Typical sources of requirements are stakeholders; documents (e.g., laws and policies); and other systems (e.g., legacy and competing systems). 3. Select appropriate determination techniques. Depending on the source of requirements, the project situation, and the nature of the requirements, an appropriate elicitation technique or a combination of elicitation techniques must be selected (e.g., interview technique, creativity technique, observation technique, or creating graphical user interface [GUI] prototypes). 4. Elicit requirements using the techniques. Requirements are elicited from the specific sources using the selected elicitation techniques at the level of detail required for the current situation 2.1 DETERMINATION OF SYSTEM CONTEXT The system context is the relevant part of the system environment that must be analyzed in order to define and understand requirements. It also includes stakeholders and surrounding systems that interact directly with the system in development. 4 The context boundary, which separates the system context from the irrelevant environment. The analysis of what does and does not belong to the system context determines which sources are relevant to the requirements. Everything in the irrelevant environment does not pursue goals or formulate boundary conditions for the intended system. However, the context boundary is also unstable from the beginning as it may only become clear during the course of the project whether laws, for example, are relevant. 2.2 DETERMINATION OF THE SOURCES OF REQUIREMENT The requirements should be determined methodically. In this step of a requirements engineering (RE) project, the structure is still subordinate because it could limit creativity. Checklists and question lists help to extract requirements that would otherwise remain hidden. The following list gives more examples of sources and the situations for which they are appropriate: market research or market studies, especially for new products, in the business to business (B2B) and business to customer/consumer (B2C) sectors internet, such as blogs, forums, and evaluations, for follow-up products and new functions internal documents, such as company rules and process documentation documents from “archaeology,” such as problem reports, manuals of predecessor systems, interface descriptions, and data documentation own development and new product concepts dealers and sales partners for follow-up products, corrections, and new functions consultants (internal and external) for strategy definition, vision, and new products Stakeholder Management Each stakeholder has an individual background, level of knowledge, and understanding of the problem. As a result, each stakeholder has their own perspective and priorities, so it may be necessary to align the communication with their technical background. Active stakeholder management is an elementary component of requirements engineering. How to select stakeholders The selection of stakeholders is important to a project. The circle of stakeholders can grow very quickly through this snowball system, so it may be necessary to reduce. The reduction can occur, for example, when management refuses to involve individuals in the project because they lack the necessary skills or resources. Depending on the stakeholder’s motivation for involvement in the project or RE and their influence in their organization, four “archetypes” of stakeholders can be defined: 1. Doers. These are the stakeholders with high influence and high motivation. These stakeholders should be involved as much as possible in the project because they have the power to enforce decisions and the will to drive the project forward to everyone’s satisfaction. Stakeholder agreements should be made with representatives of this group to keep them motivated. 5  2. Powerful. These are the stakeholders with high influence and low motivation. Enough effort should be invested to satisfy these stakeholders and maintain good contacts, but they should not be bored with too much information and details. A stakeholder agreement can also be useful with stakeholders in this group. 3. Seismographs and preachers. These are stakeholders with little influence and high motivation. These stakeholders should be informed about developments in the project and good communication should be maintained; they can quickly alert the requirements engineer the emergence of serious problems. Furthermore, they can often provide important information about the details of the project. 4. Observers. These stakeholders have low influence and low motivation. These stakeholders should not be forgotten, but it is not necessary to invest too much effort in their care. It is usually sufficient to make the relevant information available online and provide them with access. The figure above shows the four stakeholder archetypes and explains how a requirements engineer should involve them in a project. Different stakeholders may necessitate different kinds of reports. It is also a good idea to document relevant information about stakeholders. Depending on the complexity of the project, a simple table is sufficient. Some stakeholders may need a binding agreement to fulfill their tasks and duties. Therefore, it is beneficial to conclude an agreement with the stakeholders at the beginning of the RE activity. This should describe the role of the stakeholders and their importance to the project, assign responsibility for an area of the requirements, and specify the means of communication and the stakeholder’s commitment to cooperate. Personal contact with the stakeholders ensures that they can also describe their interests and goals in the project 2.3 SELECTION OF THE APPROPRIATE INVESTIGATIVE TECHNIQUES The investigation techniques can be grouped into four categories: 1) Interviewing techniques, such as the classic verbal interview or questionnaire 2) Creative techniques, such as brainstorming in different modifications, change of perspective, and the 6-3-5 method 3) Document-centered techniques, including “archaeological” activities, such as reading old requirement specifications or manuals 4) Observation techniques, such as field observation and apprenticing, which help the requirements engineer form a picture from their own experience 6 Techniques to methodically elicit requirements will be described and evaluated in a specific context, even if the client and requirements engineer do not know exactly what is at stake. These include market research and analysis. Customer workshops, market studies, questionnaires, interviews, analysis of existing documents, and visits to trade fairs and their evaluation are the most common tools used to identify and develop requirements. creativity techniques. These include group work, brainstorming, focus groups(These are small groups of people whose response to, e.g., a product, is used to predict the response of larger groups), role plays, and workshops. Group-oriented techniques must be carefully moderated because they can also lead to blockade situations. Role plays, on the other hand, require good mutual understanding and cannot be conducted across hierarchical levels or departments. experiments. These include prototyping, simulation, process models, user interfaces, concept testing with customers, and synthesizing requirements from user activities. concepts. These include scenarios; pictures; diagrams; structured and formalized analysis procedures (e.g. structured analysis, object-oriented analysis, joint application development, problem frames, quality function development [QFD], and failure mode and effect analysis [FMEA]); elaborating requirements from an existing system; and building a glossary and taxonomy to aid understanding. cognitive methods. These include protocol analysis from interviews and workshops; behavioral assessment of users; definition of persona (i.e., description of an archetypal user and their goals, demographic data, behaviors, preferences and elaboration, and typification of the associated use cases); and usability analysis. These techniques are used concomitantly. context assessment. These include demographic analysis (i.e., analysis of data and statistics for specific markets and their behavior, buying patterns, preferences, and size); ethnographic analysis (i.e., targeted study of cultural characteristics and behavior within a group); cultural characteristics; colors; and symbolism. These techniques are mainly used for heterogeneous markets 7 Factors Influencing the Choice of Investigative Techniques There are always aspects that neither the contractor nor the client know. The experience of an external consultant who knows many markets and companies, as well as conversations with non-customers, can help. Some examples of tools used to clarify assumptions and decisions are a tree diagram that breaks down the requirements, a feasibility study or prototyping, and a model that describes and examines the assumptions and external constraints 2.4 DETERMINING REQUIREMENTS USING TECHNIQUES After the project vision has been formulated, documented, and agreed upon, the requirements engineer defines the concrete objectives of the elicitation. For each goal, they identify and document the relevant sources of requirements by analyzing the system context. Immediately thereafter, they should begin to schedule discovery appointments with stakeholders and select an appropriate combination of discovery techniques (e.g., interview and system archaeology) that will enable the specific discovery objectives to be achieved for each source of requirements. The project vision and the specific objectives of individual investigations can be communicated to the respective stakeholders in advance, but it is essential that they are explained during the investigation in order to have the opportunity to clarify any questions of understanding in advance. During the conduct of the investigation, depending on the investigation technique, the requirements engineer may have to intervene and ensure, through moderation, that the focus of the requirements elicitation is not lost. At the same time, they must constantly question their own perception and the statements of the stakeholders to determine whether they have correctly understood the requirement Human Perception When the analysis demands the help of language, several things happen. These results have been described by researchers in the context of therapy within the framework of neuro linguistic programming (NLP). The aim of this work was to develop a form of therapy based on the therapist’s understanding of the patient’s personal reality Transformational Processes The described reality is changed by the personal perception of the interviewees (humans can only perceive a part of reality) and is thus subject to a transformation of perception. A requirements engineer must know that such transformations take place, leading to a loss or change of information. Another rule is that small changes in the requirements can lead to large changes in the cost and deadlines, and changes The fact that people follow rules in the formation of surface structures led Chomsky (1957) to assume that people’s behavior in the formation of linguistic utterances is rule-governed (Lin, 1999). Chomsky (1957) 8  presented a possible (and plausible) set of rules for the first time in the transformational-generative grammar. The requirements engineer wants to understand a part of the author’s personal reality, but only knows their linguistic surface structures. If the requirements engineer can deduce the transformations used, it is possible to discover the deep structure of what the author was trying to express through targeted questioning. Representational transformations Building on the findings of linguistics, Bandler and Grinder (2010) distinguish three principal types of transformation in NLP: deletion, generalization, and distortion. Deletion (This is a process by which we selectively turn our attention to certain dimensions of our (possible) experiences and exclude others) The process of deletion condenses the full amount of information that is transmitted to us into an amount that we can handle. When we, in turn, pass on information, we delete those parts that we subconsciously assume to be known by the recipient of the information. With the help of deletion, it is possible for us, for example, to filter the general babble of voices in a room in such a way that the voice of our conversation partner reaches us consciously (selective perception) Generalization (This is the process by which elements or parts of a personal model are detached from the original experience to embody an entire category.) Generalization is a process by which a unique experience is transferred to other similar circumstances or related contexts and thus accepted as generally valid. The human ability to generalize experience can be essential for survival. An example of such generalization is the hot stove. A child may touch it and correctly generalize that all stoves are dangerous, not just the one with which they burned themselves. Distortion (Distortion is the process by which reality is reshaped or even falsified.) Distortion occurs when an aspect of reality is altered in such a way that it results in a distorted image in the viewer’s mind. Any distortion can destroy a lot of information, and is thus, implicitly, also a deletion defect. Distortions are difficult for any requirements engineer, as they often cannot decide whether formulated facts are correct, distorted by the speaker, or distorted through their own perception. How to handle Linguistic Effects Each of the aforementioned transformation categories (deletion, generalization, and distortion) show up in certain linguistic effects. Each effect can lead to qualitatively inferior requirements, but not all cases lead to a defect. Language effects at the level of goals or more generic requirements (e.g., low specification levels) cannot always be avoided at certain levels of detail. However, since there will be readers who will only consider the specification at these levels, it is important that the information necessary for this readership is not destroyed by effects. The following basic rules should be adhered to at low specification levels: Always write your requirements in complete sentences. Use terms consistently and avoid synonyms or homonyms If there is already a glossary, use the terms defined there. Formulate processes using full verbs. While writing detailed requirements that are also part of a contract for an external assignment, linguistic effects are far more harmful and should be examined critically (or eliminated, if possible) 9  UNIT 3 - SELECTED INVESTIGATIVE TECHNIQUES 3.1 SELECTED CREATIVITY TECHNIQUES Creativity techniques are suitable for developing innovative requirements or an initial vision of a system. However, they are less suitable for determining detailed requirements of system behavior. In the following, a concrete variant of the change of perspective technique is explained in the form of six-hat thinking. In addition, two types of brainstorming (verbal and written), the principle of workshops, the 6-3-5-method, and design thinking will be discussed in this section. Change of Perspective (Six-Hat Thinking) Change of perspective is a creativity technique used to examine a problem from different angles. One variation is six-hat thinking by de Bono (1985), where each hat represents a perspective of a problem. Participants in the application of this method are given symbolically different colored hats that identify the perspective from which the stakeholder will view the problem. The white hat stands for objectivity and neutrality. The stakeholder primarily pays attention to facts and figures. The red hat stands for a subjective opinion and personal feelings. The stakeholder expresses their feelings, fears, and hopes. The black hat makes the stakeholder argue objectively, but negatively. The yellow hat makes a stakeholder argue objectively, but positively. The green hat puts creativity in the foreground. The stakeholder is eager to come up with new ideas. The blue hat stands for the control and organization of the whole thinking process. Verbal Brainstorming Verbal brainstorming is done with a group of five to ten people. This group collects ideas about a certain topic within a given period of time. The stakeholders express their ideas and use the ideas of the other stakeholders as inspiration for further ideas. Brainstorming is therefore particularly successful if the participating stakeholders are selected as heterogeneously as possible and are stimulated by external influences, which lets them flow into their own idea generation The advantages of brainstorming are that many ideas can be collected in a relatively short time and innovative requirements can be identified. However, if the group dynamics are difficult, poor or few results can be expected. This also applies if there are dominant stakeholders in the group. Furthermore, it is challenging for the requirements engineer to quickly note down all the information. 10  Written Brainstorming If the ideas are collected digitally, this is less work for the requirements engineer, who does not have to note down the ideas. This also means that there is no danger of forgetting ideas when they are expressed at the same time, and the creativity process is not inhibited by asking questions. However, the collection of ideas can also be carried out anonymously by stakeholders noting down their ideas but not expressing them aloud. Anonymity helps to prevent negative group dynamics and hierarchical conflicts. The disadvantage can be that creativity is not stimulated by the ideas expressed by other stakeholders. There are different variants of written brainstorming, as discussed below. Written brainstorming with user stories User stories are functional requirements formulated from a user’s point of view. In practice, it has proven useful to write user stories on an index card with a thick pen. The limited space encourages stakeholders to formulate precisely; the cards can then be easily sorted and grouped, and duplicate ideas can be eliminated. Experience has shown that the stakeholders should be asked to collect ideas from any perspective and without rationale, so as not to hinder the creativity process. 11  The 6-3-5 Method The 6-3-5 method is a written creativity technique. Six participants each develop three ideas at the same time and write them down on a card. After a fixed period of time (typically three to five minutes), the cards are passed on to the respective neighbor. The neighbor reads the ideas of their predecessor and is inspired to write down three more ideas. This is repeated until each participant has had each card once, i.e., five times. Then the ideas (25 in this case) are collected and evaluated, and the requirements are derived. Three typical ways to develop ideas are as follows: 1. Repeating the idea according to the principle of the genetic algorithm. Successful ideas survive. 2. Permutation. Ideas are modified. 3. New idea. The participant is inspired by other ideas and adds a new idea. This technique is easier for the facilitator to use than, for example, brainstorming, because the collecting, writing, and grouping of ideas is done by the participants themselves. Design Thinking The aim is to understand the need from different perspectives and develop ideas in iterations, evaluate them, and, based on the evaluation, develop new ideas that convince the user. The following list explains each of the six steps in design thinking: 1. Understanding means assessing the situation. It is about finding as many data, facts, and questions as possible to understand the issue and be able to talk about it. This is preparation for the next step. 2. Observation is done to find out the real needs of the users that have not been addressed so far. Design thinking assumes that many needs cannot be named by the users and must be observed in the context of the use of a product or service. 3. Synthesis means that the data from understanding and observation are collected and needs are derived from them. 4. Developing ideas is an important step. The goal is to develop as many ideas as possible and select those with the greatest potential. 5. Prototypes are used to concretize the ideas, develop simple prototypes, make them tangible for the user, and develop them step by step. The user can quickly experience the benefits of prototypes made of paper, clay, or software. 12 6. Testing is carried out when the prototypes are made available to target users for testing. The prototypes are refined with feedback from the users. Different methods to produce specific results are used according to the situation. Some examples include usiness model generation and business model canvas. This can be, for example, lean and demand-focused representation of a business model based on assumed market principles. benchmarking. This is constantly and consistently learning from the best, especially across products and sectors. prototyping. This is the systematic development of possible solutions for the initial need. The aim is to better understand the need and experiment with the use and business model at an early stage with open results. persona. This is the assumed typical role pattern of later customers or users, especially if, in business to consumer (B2C) or business to business (B2B), the actual customers are not on board in the design workshop. focus groups. These promote the active involvement of later users in early prototypes to evaluate ideas and develop new ones. reframing and 5 Why. These processes systematically question assumptions, constraints, goals, and perceived need in five steps with the question “Why is this so?” Pecha Kucha and elevator pitch. These models involve briefly summarizing an idea and its value in twenty seconds with the aim of convincing a decision-maker or user group. Workshop In a workshop, different stakeholders come together to work on the identification of requirements. When the requirements engineer invites the members of the workshop, they have to ensure that these representatives are equipped with the necessary expertise and decision-making authority to obtain the agreed requirements as a result of the workshop. 3.2 INTERVIEW TECHNIQUES The successful use of interviewing techniques requires that the interviewed stakeholders are able to explicitly express requirements, have the necessary time, and want to be interviewed. 13 Standard Interviews The interview is a questioning technique actively controlled by the requirements engineer, which makes it possible to determine detailed requirements. An interview is divided into four phases. First phase To conduct an interview, the requirements engineer must know the technical language or terminology of the interviewee and use it. Furthermore, the explicit definition of the interview objective, the selection and invitation of the participants, the determination of the interview location, and the concrete design of the interview questions are part of the preparatory activities. The interview questions can be open or closed. An example of an open question is: “What functionality would you like the system to have?” Open questions give the respondent the freedom to provide a lot of information, which is also more difficult to evaluate. For closed questions, direct questions. Second phase If the requirements engineer and the interviewee do not know each other, the interview begins with an introduction of the interviewer (requirements engineer) and a short thank you to the interviewee for taking the time to participate. Third phase The answers to the questions must be recorded, so a transcriber can be present or the interview can be recorded. In both cases, this must be discussed with the interviewee beforehand. The requirements engineer gives the interviewee feedback on their answers to check whether they have understood correctly. Fourth phase The implementation is concluded with a summary of the interview results, a thank you, and the indication that the respondent will receive a summary of the results. 14  Questionnaire Questionnaires are suitable for interviewing a large number of stakeholders. First of all, the stakeholders must be chosen (a full survey is generally preferable). If a full survey is not possible, the requirements engineer must select a representative set of stakeholders. Because the requirements engineer does not have the possibility to actively steer the survey, the questions must be formulated carefully. The elicitation of questions can be supported, for example, by a creativity technique or workshop. It may be necessary to prioritize the questions. For example, if the respondent loses interest or has too many questions to answer, there is a high risk that the survey will be abandoned. 3.3 OBSERVATION TECHNIQUES Observation techniques are particularly suitable when domain experts do not have time or are not able to explicitly express requirements. They must critically question the observed processes in order to produce target situations and reveal weaknesses in work processes and the system. Field Observation In a field observation, the requirements engineer is on site and directly observes the business processes taking place. They record the activities and their chronological order to determine the work processes. The observer does not have to observe passively; they can actively ask questions and have work processes explained to them. The danger of field observation is that the requirements engineer is perceived to be supervising the stakeholders’ work. Another challenge is critically questioning all processes in order to identify potential for optimization. Processes that are stuck and in need of improvement should not be transferred one-to-one into the new system. 15  Apprenticing Apprenticing is another observation technique. It differs from field observation in that the requirements engineer both observes and performs processes. Learning different activities is very time-consuming, which can be a disadvantage of this technique. It also cannot be used in every field. Safety-critical activities, such as monitoring a power plant or production line. Strengths and Weaknesses of Some Investigative Techniques Strengths and weaknesses of some of the techniques explained above are compiled in the following table. The investigation method “system archaeology” means studying documents of ancestor systems. The following table gives an overview of concrete factors within three categories listed and their influence on the use of a technique. 3.4 PROTOTYPING Today, a prototype is understood to be an initial version of a software system that can be used to demonstrate concepts or test designs in order to learn more about the problem and its possible solutions. This definition makes it clear that prototypes can be used to elicit requirements as a deeper understanding of the problem is gained through their creation and communication. Prototypes can be differentiated with regard to the following criteria: The nature indicates whether they are analog or digital prototypes. The durability or intended use distinguishes between prototypes that are not further developed after their creation and intended use (disposable prototypes), and those that are further processed into the later product (evolutionary and incremental prototypes). The degree of functionality implemented distinguish prototypes. Horizontal prototypes implement a layer of the (software) architecture (e.g., the data management layer). The relevant components of this layer are implemented, 16 but the other layers are not. The vertical prototype is called a piercing prototype because it implements one functionality or feature across all layers of the software architecture. Horizontal Prototype for GUIs Horizontal graphical user interface (GUI) prototypes can be used as a tool for mapping dialog flows and managing expectations. Depending on the project phase, either analog hand sketches or digitally implemented prototypes are used. At the beginning of a project, a hand sketch can be used to quickly visualize initial concepts for the implementation of a graphic interface. GUI sketches are digitally created interface sketches that are uniformly designed and, if necessary, clickable, but are still unfinished. The advantage here is that the navigation flow can already be shown and they are more precise than hand sketches. A mock-up is a prototype implemented in the target technology of the system in the original size and color, but without functionality. A reduced functionality can be simulated by depositing an unchangeable dataset. Mock-ups are used to visualize and tune the appearance of the planned system. These prototypes are developed quickly and without consideration of special quality requirements (quick and dirty), when they have to be available as soon as possible. A prototype that is further developed into the product is called an evolutionary and incremental prototype. Since the prototype becomes part of the final product, the quality requirements must be taken into account during its development, and the prototype must be developed explicitly under the quality aspects. However, this leads to a conflict of goals between early availability and extensibility of the prototype. In the case of mock-ups, it is difficult to convey to the customer that the logic management, data management, and integration with surrounding systems must be implemented in addition to the GUI. Customers usually have no understanding of the expenditure of the software development because it is usually not apparent to specialized experts. 17 Vertical Prototypes A vertical prototype fully implements selected functions of the target system through all system layers. This technique is appropriate where functionality and implementation options are to be clarified. UNIT 4 - DOCUMENTATION OF REQUIREMENTS 4.1 ACTIVITIES FOR DOCUMENTING REQUIREMENTS For the systematic documentation of requirements, four steps can be identified: 1. Determination of purpose and target group 2. Selection of the detail level and documentation form 3. Documentation of requirements 4. Checking whether documentation still fits the purpose and target group 18  1) Determination of Purpose and Target Group Since the documentation is intended to support communication in the software project, the purpose and the target group must be determined before the documentation is created. Typical goals for requirements documentation are as follows: Communication support for the stakeholders involved is needed, for example, when requirements need to be clarified and prioritized, or when the identified requirements must be handed over to the architects and developers for implementation. A knowledge repository and reference for decisions and definitions is needed so that the results of the original requirements elicitation can still be consulted after commissioning, and for maintenance and further development activities. Statements and clarification must be binding in case of dispute. In case of misunderstanding or ambiguity, there should be a binding document that is recognized by all sides as a common agreement. By defining the purpose and target group of the documentation, the requirements engineer obtains clarity about the use of the documentation. For example, a different presentation may be used for coordination with a specialist department than for coordination with top management, which, in turn, may differ from the documentation for knowledge transfer to the development team. Examples of typical communication situations include discussions with the business unit about functional requirements a decision template for management to release the budget Levels of Detail Usually, there are requirements at all four levels of detail for a system. The levels establish how completely the requirements are determined and documented. With this theoretical view, the requirements engineer can consciously decide which requirements in which level they should elicit next, or at which points they want to forego completeness or refinement 19  2) Selection of the Level of Detail and Form of Documentation Since the documented requirements are read and understood by different groups of people depending on their use, it is important to take the prior knowledge and interests of the respective stakeholders into account. With regard to the level of detail of the documentation, a decision must be made as to whether an overview is sufficient 3) Documentation of the Requirements Based on the previous activities, the requirements can now be documented in a form suitable for the purpose and target group. Changes to the requirements in drafts. Changes usually result in collateral changes to related requirements. Finding them is not always easy, so it is recommended to document relationships between requirements. Some software tools support this way of working. 4) Checking Whether Documentation Still Fits Purpose and Target Group Since the concrete documentation can take a long time, and the requirements can change among stakeholders as they continue to deal with the subject matter, it is important to regularly review whether both are still appropriate for the current purpose and goal. 4.2 TYPICAL ELEMENTS OF REQUIREMENTS DOCUMENTATION There is no uniform structure for requirements documents that can be used in all projects. The concrete structure and its content depend on the type of system, the organization of the software project, and the company-specific requirements. The aim of specifying the structure is to ensure that requirements are described in a comparable way across projects. In practice, document structures often develop into write-only documents; although they are published as a convention. Therefore, specifications for document structures should be continuously monitored and adapted to practical needs. Although there is no generally applicable documentation structure, four typical elements of requirements documents can be identified: 1. Project vision 2. Overview level 3. Detailed requirements 4. Glossary Project Vision At the beginning of a project, the client’s specifications and requirements must be determined, documented, and agreed upon. Starting with the initial project idea, the client’s requirements, goals, and expectations are identified and defined step by step. n the first workshop of the project, it is recommended to formulate the project vision or goal as a text of half an A4 page. The project vision obtained should be the first section of a requirements document. It should answer the following questions: What is the goal or purpose of the project, i.e., what will be achieved? What is the motivation for the project, 20 Overview Level The following should be considered: location of the system in the business process landscape, i.e., a brief description of which business processes and functions are supported by the system embedding of the system in the information technology (IT) landscape of the organization, so it is possible to classify the system compared to other IT systems brief description of the most important system function so that the reader can gain an overview of the individual system functions, e.g., with use cases technical interfaces to other systems, so all involved parties are aware of the technical dependencies, and technical integration can be started at an early stage brief description of the roles that will actively work with the system, so it is clear which stakeholders must be actively involved in requirements elicitation Detailed Requirements Each system function should be described briefly so that the reader has an overview. Let’s assume that, for an online store, the important system functions “Add items to inventory,” “Search goods,” “Buy items,” and “Send newsletter” have been identified. Each of these functions must have a section in the detailed requirements documentation. ” These sub-functions are documented within the system function section. For each sub-function, all of the information that the development team needs to start implementing the system is compiled before the implementation starts. In particular, this includes all relevant functional requirements, quality requirements, and constraints. Glossary Abbreviations in particular require binding definitions in a glossary. Confusion can also be caused by common verbs. The following is a list of tips for building the glossary: Sort the defined terms alphabetically. Define technical terms to be used in the requirements. If available, list synonyms or related terms that may have a different meaning. Define verbs to prevent misunderstandings if they are not otherwise defined or explained in the specification. Describe adjectives, such as “fast.” Use legally binding modal verbs and explain their meaning. Define requirements related to roles by describing tasks and responsibilities. 4.3 FORMS OF DOCUMENTATION Text and Tables In principle, all requirements can be described using text and tables, which are the most frequently used documentation forms for information systems. The advantages of documentation in the form of text and tables lie in their ease of use. Neither documenting nor reading documentation requires any additional learning. In addition, both are versatile because they can describe all types of requirements. In some requirement specifications, only the positive cases are described. It is also important to describe the behavior of a system when something goes wrong. The next four examples, based on Ebert (2019), start with a roughly structured specification (example one) and then move to a detailed structured specification (example two) in which the extensions are identified by hierarchical numbering. This ensures the unambiguous identification of the requirements 21 In example three, a semiformal specification with a strict outline is shown, which can be reused as a template for other requirements. 22 Example four shows a formal specification, which looks like a piece of program code. It is very compact (without the same amount of detailed information), but it is not understood by stakeholders without programming skills. User Stories User stories are a popular technique used in Agile. The logic behind user stories is simple, user stories are a popular technique used in Agile. However, this simplicity only goes so far, and user stories need to be complemented by a degree of rigor to benefit from this technique. A well-written user story scribbled on a sticky note or card has the following form: The realization effort in Agile projects is roughly estimated using the “T-shirt sizing” technique shown in the table below. The relative effort at the beginning of a project is just a way to say that one task may take four times longer than another. Epics Customer requirements in an early development stage can be quite large or vague. This has given rise to a different type of user story, known as an epic. Sketches and Simple Graphics The advantage of sketches and simple graphics, as exemplified in the figure below, is that they are simple and can be created quickly on a whiteboard or paper. One disadvantage of sketches and simple graphics is their wide scope for interpretation if their meaning is not described, e.g., by text. Therefore, sketches are only suitable for permanent documentation to a limited extent. 23  Models Basically, a distinction is made between graphical and textual models. The graphical models have a visual character, i.e., they are graphics whose notation elements each have a specific meaning. In requirements engineering, both graphical process models (e.g., Business Process Model and Notation [BPMN] or event-driven process chains) and graphical software models (e.g., unified modeling language [UML]) are used. Graphical models are used to document requirements for the structure and behavior of systems. GUI Prototypes Graphical user interface (GUI) prototypes are particularly suitable as a form of requirements documentation for user interfaces. In addition to using these prototypes to elicit requirements, GUI prototypes can also be used directly as a form of requirements documentation. They can be used, for example, to precisely define the exact size, position, color, and labeling of user interface elements. Mixed Forms of Documentation In practical use, requirements for information systems are usually documented in a mixture of models, formulated text, and GUI prototypes. This combination compensates for the individual disadvantages of each documentation 24 form. This supports the reader in understanding and classifying the modeled facts. When using different forms of documentation, care must be taken during documentation and all subsequent revisions and adaptations to ensure that the text and model reflect the same level of knowledge, and that there are no inconsistencies in the documentation. Other Forms of Requirements Formulation and Formalization In order to overcome the difficulties of natural language, many formal notations and languages for the formulation of requirements for software have been developed. The first trials of the programming language Ada, used for specifications, failed because pure Ada is too restrictive for requirements specifications, and not all relevant parties possess the programming knowledge needed to understand Ada. The four specification examples previously shown represent four different types of specification.However, the semiformal specification is the easiest to understand for non-programmers and can be maintained using a tool. Requirements in Agile Software Projects In an Agile software delivery method, the following approximation levels are used: The highest level is realized by a “project product description” called the “vision.” A high level requirement, alternatively called “product group” or “project product description composition,” is also called “epic,” “feature,” “function theme,” or “scope.” An intermediate level can include epics, features, functions, or a “coarse-grained user story.” The lowest, most detailed level is described by user stories and is named “fine-grained user story.” Agile delivery methods try to reach the final level of detail by decomposition, starting with “boulders” and “rocks” and stripping them down to “gravel” (Richards, 2018). From an estimation point of view (in the form of time, cost, or benefits), the margin of error at each of these stages could be as follows: 50 to 100 percent for the pre-project stage 20 to 40 percent for the initiating stage 10 to 20 percent for the delivery stage UNIT 5 - MODELING OF PROCESSES 5.1 BASICS AND TERMS In addition to the organizational structure, this includes the process organization and business processes, which are used to describe the processes in a company, and external partners, such as suppliers and customers. The following will explain how organizations can be structured, the goals of business processes in the process organization, and the elements of business processes and their relationships to each other. Organizational Structure In most cases, this structure is hierarchical and defines the framework for processing tasks. In other words, it determines which tasks will be performed by who; The goals of the organizational structure are a division of labor and an order of the operational action processes by creating and distributing tasks. In a hierarchy, management structures and authority to issue directives are formed, making it possible to assign tasks and responsibilities. The upper level is authorized to issue instructions to and make decisions for the subordinate levels. The subordinate levels have the right to make suggestions to their superordinate level; 25  The multi-line system is structured in the same way as the single-line system, with the difference that superiors of equal rank also have authority to issue directives across teams. The principle is based on the fact that supervisors are subject-matter experts and can therefore be consulted by employees. In a matrix organization, staff can keep the affiliation to their team or department, and the leader of the unit takes the lead in personnel matters. Consequently, employees in a matrix organization may have at least two leaders to report to, which could be regarded as a disadvantage for some employees. The advantages include greater availability of experts. improved information flow in the project and company. faster decision-making processes. enhanced motivation and working morale. better development of self-management skills (employees working autonomously despite reporting to more than one lead). increased exchange of information across departments. increased production and innovation due to the inclusion of functional specialists Process Organization The process organization depends on the organizational plan. The process organization documents the design of the organizational structure’s work processes by linking individual work steps using the resources (jobs, departments, roles, instances, and tasks) of the organizational structure. The goals of the process organization are to maximize the utilization of the service production, minimize waiting times to keep the costs of service production as low as possible, and improve the quality of processing and working conditions. Elements in Business Processes A general definition of a business process (BP) is “a goal-oriented, chronological sequence of tasks that can be performed by several organizations or organizational units using ICT (information and communications technology). The table each component, there is a graphical model, called a shape, which is linked to other shapes by their edges. These are known as sequence flows. Depending on the context in which they are drawn, they can mean “belongs to,” “executes,” or “is responsible for,” as shown in the figure below the table. Even though the edges usually look the same, their different meanings can be managed in a professional tool for business process modeling (BPM). 26 27  5.2 MODELING WITH THE BUSINESS PROCESS MODEL AND NOTATION (BPMN) The Business Process Model and Notation (BPMN) is a notation for modeling business processes, which is managed and developed by the Object Management Group (OMG). The understanding of process models can be enhanced by thinking of the process as a computer program in which a “token” is routed from one step to the next, depending on the progress of the activities being performed or the conditions given in the logical links. The figure below shows a process for shopping via the internet, from the first customer contact to the payment. Three additional sub-processes modeled in the yellow “lanes” are also shown: the main process for checking in a warehouse management system, the availability of the selected product, and checking the credit card or PayPal account. This figure below is an enlargement of the previous, in which it is possible to see the processes in greater detail. The process starts with the green event on the left, when the user starts the dialog with the online shop. The yellow object that follows is known as a joining or gateway, which flows into one output on the right. This means that, no matter which of the three inputs the token comes from, it will be forwarded to the single output that offers a selection of items for ordering. Before the selected item can be moved to the shopping basket, a parallel process in the warehouse management system (WMS) begins to check its availability. Meanwhile, the aforementioned token moves into the main process to the orange event, where the process waits for the arrival of the message from the WMS that the check has been performed. 28 Gateways Gateways initiate or terminate branches (splitting or joining gateways) in the sequence flow of a diagram. In other words, gateways route the token at the input port to one or more output ports. The marking of the gateway determines its meaning. As with the operations of the logic or logic functions of a programming language, we distinguish between exclusive, inclusive, and parallel gateways. 29 With this knowledge, the BPMN model from the two enlargement figures can be better understood. The flow is split by an XOR, since the system’s question about the payment method only allows the choice of exactly one method, and also offers the possibility of canceling the whole process. 30 31 Connection Type The three connection types of BPMN are sequence flow, message flow, and association. The sequence flow specifies the order of activities and can cross lane boundaries, but not pool boundaries. A message flow can connect activities or events in different pools where communication is via messages. Association links data objects and annotations to flow objects. In the figure, the association displayed as dotted lines indicates where the annotations belong. 5.3 MODELING WITH EVENT-DRIVEN PROCESS CHAINS Event-driven process chains (EPC), also known as Architecture of Integrated Information Systems (ARIS), are widely used in German-speaking countries. The EPC is used, just like the BPMN, to model operational processes. Extended event-driven process chains (eEPC) increase the expressive power of the EPC through additional notation elements Important Notation Elements Nevertheless, compared to BPMN, some important parts such as pools and lanes are missing in EPCs. The handling of events is clearly different from BPMN as the example in the figure above shows. An event is something that happens in the course of a process and affects the flow. The event shape is also used as a status shape, which, for example, after a splitting gateway, indicates for what condition the attached path can be treated. This makes an EPC drawing less compact than BPMN. The same is true for a trigger to start a sub-process. The difference in eEPCs is that activities can be decorated with additional shapes bearing the following information: Who (what person or role) is executing or has participated, e.g., following the responsible, accountable, consulted, and informed (RACI=This is an abbreviation for participation grades in an activity) model? If EPCs are not modeled in swim 32 lanes where at least the responsible person or role is mentioned, then this additional shape located above the activity shape is obligatory. Which information technology (IT) system is involved in this activity, or which document is read (connection from object to activity) or written (connection from activity to object)? Connectors A connector is either a split or a join, but never both at the same time. Connectors are the only symbols that branch or join control flows. Events and functions never have more than one input and one output. The figure below shows the three different connectors. AND connectors enclose sub-processes that are executed simultaneously or independently. OR connectors enclose alternative paths, where multiple alternatives can be executed simultaneously. EXCLUSIVE-OR connectors enclose alternatives, and only one may be executed at a time. 33 The following figure is an example of the usage of connectors. First, the AND connector is used because both checks must be performed in parallel, and the approval at step two will only be given if both checks deliver positive results. In both flows, there are exclusive results: OK or nOK. Both nOK were joined at step three with an inclusive OR because one or two nOKs are sufficient to refuse the new order. At step four, an XOR joins the flows again because the traveling token can only come from approval if XOR refuses. Extended EPC Some tools, such as ARIS, which allows the creation of customized shapes whose relationship to other shapes 34 Overview of EPC The EPC method offers fewer shapes for models than BPMN. For this reason, EPC is easier to understand for beginners if the modeler follows the rules of this methodology. For beginners, the benefit of switching between activity and state is sometimes difficult to understand, and mistakes are often made in the modeling of the logic, i.e., the use of the connectors (gateways) in BPMN. Nevertheless, following the rules is important in order to make the processes understandable for the reader. The modeler is supported in adhering to the rules if they use a tool that checks the syntax and draws attention to errors or ambiguities. 35  UNIT 6 - SYSTEMS MODELING 6.1 BASICS OF UNIFIED MODELING LANGUAGE UML provides the notation elements for the static and dynamic models of analysis, design, and architecture, and supports object-oriented approaches (Rupp et al., 2012). By integrating extensible markup language (XML) into UML, a textual notation of equal power was added to the modeling language, which had previously comprised only graphical elements, and which enables the transfer of models from one modeling software to another. So that the user of UML is not disappointed, it should be clear to them from the outset that UML is not perfect, complete, a programming language, a purely formal language, specialized for one application area, a complete substitute for textual description, or a method or procedure model. The fourteenth diagram type, the profile diagram, enables the modeler to tailor UML to their project environment by adapting standard UML model elements. The extensions or restrictions of individual elements of the UML metamodel can be bundled into packages as profiles and applied to models, exchanged, and removed as required. The four most frequently used diagrams are highlighted in the table below. 36 Relationship between UML Models and UML Diagrams A UML diagram represents a very specific view of a system or an issue. For example, a class diagram models business objects and their properties, while an activity diagram models internal processes of the system. Separation of Meaning and Representation UML is used for graphical modeling, in which each graphical model element has a specific meaning. The UML standard specifies the set of possible terms that can be used when creating a UML model. Furthermore, the UML specifies, for each diagram type, which of the terms available in the UML can be used in the respective diagram type, and which graphical representation should be used for this purpose. This means that the set of allowed model elements depends on the concrete UML diagram, and the graphical representation of the same term may differ depending on the diagram, but the meaning remains the same. From this, the meaning is independent of the graphical representation, which enables, for example, the automatic transformation of UML models into other model types or directly into program code. The set of UML elements (e.g., the contents of a class diagram) that the modeler assembles in a model is stored in a repository. This is usually a tool-dependent repository (e.g., a database or multiple files) that provides additional management services for team support, validations, tracing, etc. UML therefore provides a set of possible terms and their graphical symbols for modeling a UML model and specifies rules for constructing these diagrams. For each element, it is specified with which other elements it may be connected and in what way, as well as what this connection means in concrete terms. 6.2 UML USE CASE DIAGRAM The use case diagram is used to represent the most important functions of a system and its interfaces in the system environment, providing an overview of the system and its direct environment. The figure below shows an example of a simple use case diagram for an online store using basic information. There are five main activities, three human actors, and some external systems. 37  The behavior of the system from the user’s point of view, or from the point of view of the peripheral systems connected via technical interfaces, is depicted on a very abstract level. Important Notation Elements Use Cases in Requirements Engineering The use case diagram (UCD) is suitable for the simple representation of the system’s functions to the outside world. Since the UCD does not contain any details about the system, it can be used, for example, to communicate with the user or management. It is also suitable as a form of documentation for the system overview and for determining the system context. Identification of Use Cases As a rule, a use case is a task that is completed in several steps with which the actor wants to achieve a certain result. The figure below shows some examples of suitable and unsuitable use cases. For example, “log in to the system” is too trivial to be a use case. The use case should cover some activities and decisions made about events or status. 38 Task One: Think of a familiar system from your everyday life, e.g., an automatic coffee machine or a rail ticket machine. Try to model these systems with a UML use case diagram. 6.3 UML ACTIVITY DIAGRAM In general, the activity diagram is used when tasks must be broken down into their individual steps. For example, it is suitable for detailing use cases from a use case diagram. While no sequences or conditions are explicitly modeled in the use case diagram, the main task of the activity diagram is to visualize detailed processes with conditions, loops, and branches. Important Notation Elements The table below presents the basic notation elements that can be used to describe simple processes as a UML activity diagram. The modeled actions and activities in an activity diagram are processed in their specified order. Once the execution of an action has been started, the successors of this action can only be executed when the action has been completed. In the token model, this means that the token is only passed on when the activity has ended. 39 Branching and Merging In addition to the notation elements in the previous table, more available elements for the splitting and synchronization of information flows are compiled in the next table. it is recommended to use branching and connecting nodes, as well as parallelization and synchronization nodes, in pairs. This means that a branch is always closed with a merge. Likewise, a parallelization should always be closed with a synchronization Use of Activity Diagrams in RE The UML activity diagram is used in requirements engineering to refine and detail use cases. It is suitable for the representation of processes in interaction with business execution conditions. In particular, the activity diagram can also be used to describe required actions that are important in the event of an error or in exceptional situations. Task Two: Consider a familiar process in your everyday life, e.g., withdrawing money, making an online transfer, or buying an online ticket, and try to model this process with a UML activity diagram. 40  6.4 UML CLASS DIAGRAM The class diagram is one of the most frequently used documentation forms in object-oriented system development. In principle, it can be used for the analysis and documentation of technical aspects, without a resulting object-oriented system at the end. The figure below shows an example of a UML class diagram used for the documentation of functional requirements. Notation Elements: Classes and Their Properties In the previous figure, classes are always represented by a rectangle. The name of the class is written in the rectangle. Relevant properties or attributes of a class can be identified and entered in a lower rectangle, and both rectangles are connected. As a minimum, the name has to be given for each attribute. Further properties, such as data type and default values, can be specified, but do not have to be. The missing properties are specified during the development process. The table below shows how classes with and without properties are modeled in the UML class diagram. 41 Notation Elements: Relationships between Classes Among other things, the types of relationships described in the table below can be modeled in the class diagram. 42 Multiplicities (also called cardinalities) can be used to specify quantities for relations. These specifications are noted at the end and at the top of a relation, e.g., to the left of “…” is the lower limit, and to the right of “...” is the upper limit of the quantities. The table below gives an overview of possible quantity specifications, but it does not include inheritance relationships. No quantity specifications can be modeled for them. Use of Class Diagrams in RE In the requirements engineering environment, the class diagram is used to document static concepts of an application area. This includes business objects; business entities (industry-specific things in the real world that are to be managed with information systems); people; objects; and systems and their relevant properties, relationships, and dependencies to each other. The primary goal is to document, understand, and communicate the domain-oriented problem. This means that the classes in the class diagram are regarded as concepts of the domain-oriented environment and not as elements of a system. Task Three: Choose a familiar environment from your everyday life, e.g., distance learning, a bank online portal, or an online store. Try to model the business objects, people, and other business entities in a UML class diagram. 6.5 UML STATE DIAGRAM The UML state diagram is a behavioral diagram that can be used to document the functional states of objects or systems. In contrast to actions and processes, which are modeled in the activity diagram, the state diagram specifies which states an object or a system can assume, which dependencies or sequences exist between the states, and when they can be reached. 43 Important Notation Elements 44 Use of State Diagrams in RE Since domain-oriented state transitions can be used to represent the entire life cycle of a business object in a very compact form, they are suitable as a supplement to an overview of the complex process or flow diagrams. Another use case for state diagrams is modeling call sequences of screen masks. Here, each state corresponds to a screen mask or screen page, and the state transitions represent the user’s click sequence. Task Four: Select known business objects from your environment, then try to model the life cycle of the business objects in a UML state diagram. Alternatively, model completing a distance learning course or bidding on an item at an online auction site. UNIT 7 - CHECKING AND RECONCILING REQUIREMENTS 7.1 ACTIVITIES FOR CHECKING AND RECONCILING REQUIREMENTS The process for reviewing and reconciling is designed to release the requirements for implementation in the downstream phases of the software project. 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. 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 violating legal requirements, such as the Data Protection Act, which can lead to legal consequences. 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. Comparable to elicitation and documentation of requirements, the core activity of the reviewing and reconciliation processes can be divided into four steps: 1. Defining review criteria 2. Selecting review principles and review techniques 3. Performing reviews and documenting results 4. Reconciling requirements and managing conflict. 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. 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. 45 Perform review and document results 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. 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. 7.2 TEST CRITERIA 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. In the following, possible review criteria for requirements are presented, most of which are described in the literature by Rupp and Die SOPHISTen. Review Criteria for Content Quality In Prince2, the six criteria of the INVEST mnemonic are used to check the quality of a well written user story (Richards, 2018): 1. Independent 2. Negotiable 3. Valuable 4. Estimable 5. Small 6. Testable. The Institute of Electrical and Electronics Engineers (IEEE) defines various quality criteria in the ISO/IEC/IEEE 29148-2011 standard for both individual requirements and requirements specifications (Rupp & Die SOPHISTen, 2014). The following lists the quality criteria that a requirement must meet in order to be called “excellent.” Completeness of all requirements This is where all of the documented requirements are considered. Possible questions include the following: Does the set of documented requirements include all relevant requirements for the system? Are there any missing requirements? Were irrelevant requirements documented? Completeness of individual requirements For this purpose, each individual requirement is examined in order to determine whether all relevant information for describing this requirement is available. Possible questions include the following: Is all information documented that is needed to understand these requirements? 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. 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. Possible questions include the following: Can the requirement’s contribution to the project goal be described? Does the requirement describe a function or feature that is not yet important? 46  Traceability For this criterion, additional attributes or metadata of the requirements are needed. The requirements engineer should check whether the necessary information is documented. Are there dependencies between requirements, and, if so, are they clearly identifiable? Do the referenced requirements still exist, and are they still valid? The active management of traceability, which should not be confused with revision management, helps the requirements engineer by using the requirements metadata. Possible questions include the following: Who accomplished the changes, when, and why? Which connections exist alongside which other requirements? There are pre- and post-requirements for traceability. Pre-requirements include questions such as the following: For whom is the requirement important? Who should be informed about changes as a priority? Post-requirements include questions such as the following: Has the requirement been implemented and accepted? Are there collateral changes that need to be considered? Are there any artifacts missing? Why Does a Requirement Specification Need Traceability? 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) 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 Adequacy 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. Possible questions include the following: Did the stakeholder really say that? Do the requirements correspond to the intention of the source? Consistency Consistency involves checking whether there are contradictions or inconsistencies in the set of documented requirements. Possible questions include the following: Can the given set of requirements be fulfilled? Are requirements mutually exclusive? Do requirements contradict each other? 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. Possible questions include the following: Are regulations already made on the concrete design of the system? Are the technologies to be used prescribed? Are detailed specifications made for internal technical processes? Are technical restrictions or conditions described? 47  Documentation of the domain-oriented problem This process involves checking whether the domain-oriented problem can be identified for each documented requirement. Possible questions include the following: Is it clear for each requirement which business problem it solves or which purpose it fulfills? Verifiability and testability 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. Possible questions include the following: Can concrete test cases be derived? Is it clear how the requirements can be checked for correctness after implementation? Are criteria to be checked already defined in the acceptance test? Review Criteria for Documentation The criteria for checking the documentation answer the central question: Have the requirements been documented in a comprehensible manner and in compliance with the documentation regulations? The following test criteria can be used to check the documentation. 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. Possible questions include the following: Does the document str