UNIT 2 DETERMINATION OF REQUIREMENTS Flashcards
What are the 4 step that a requirements engineer should do to elicit requirements?
- 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. - 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). - 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 prototypes). - 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.
Define the system context, system boundary and context boundary.
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. Documents can also be part of the system context and provide boundary conditions for the development of the system. The addition or exclusion of requirements changes the functional scope of the system and thus the system boundary. Another boundary is 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.
Give me some examples of sources of requirements.
- 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
- in-house and external research and innovation
- own development and new product concepts
- own marketing and sales
- own services for follow-up products, corrections, and new functions
- user groups for follow-up products, especially in B2B and B2C interviews, seminars, and workshops
- existing specifications and requirements
- dealers and sales partners for follow-up products, corrections, and new functions
- consultants (internal and external) for strategy definition, vision, and new products
What are the risks of selecting the wrong or too many stakeholders in the requirements elicitation?
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.
Those whose knowledge is outdated or who are not prepared to communicate sufficiently will not advance the project and should not be regarded as stakeholders. Stakeholders should be chosen carefully, as “forgotten” stakeholders can lead to unnecessary and expensive change requests.
What are the main archetypes of stakeholders and which are the ones to involve in the requirements elicitation?
- 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.
- 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.
- 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. In addition, they are often multipliers who, despite their limited influence, excite others with their enthusiasm and spread a positive mood. - 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.
Why should you document information about stakeholders?
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. This is not necessary for all stakeholders, but it increases the stakeholders’ commitment to the project.
Personal contact with the stakeholders ensures that they can also describe their interests and goals in the project (as documented in the figure above). Their documentation must
be carried out by the requirements engineer with the same care and precision as the project requirements. Incorrectly or inaccurately formulated stakeholder objectives can also result in costs due to subsequent changes.
What are the main investigation techniques categories?
- Interviewing techniques, such as the classic verbal interview or questionnaire
- Creative techniques, such as brainstorming in different modifications, change of perspective, and the 6-3-5 method
- Document-centered techniques, including “archaeological” activities, such as reading old requirement specifications or manuals
- Observation techniques, such as field observation and apprenticing, which help the requirements engineer form a picture from their own experience
Name and describe some investigative techniques a requirements engineer might select.
- 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, 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, and failure mode and effect analysis); 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.
What are could influence the choice of investigative techniques?
Unknown requirements exist and are difficult to identify because we cannot ask about them directly. There are always aspects that neither the contractor nor the client know. These are often the commercially interesting perspectives because innovations are born from them, but identifying them is not easy. 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.
What should be done during the investigative techniques to ensure the selected techniques are right for the project?
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.
Name the problems that emerge when human language is needed to help the analysis progress.
Transformational processes, representational transformations, deletion, generalization, distortion.
Describe the transformational processes that happen during the determining of requirements using techniques.
Every requirements engineer has to describe a real or yet-to-be developed system, product, application, or business process based on client statements or stakeholder interviews. The described reality is changed by the personal perception of the interviewees and is thus subject to a transformation of perception. However, the personal knowledge of the respondent, their social conditioning, and their previous knowledge will ensure that the perception is interpreted differently. Therefore, another transformation (the representation transformation) takes place when the
respondent formulates their impressions or requirements. The interviewee implicitly assumes a basic knowledge of the interlocutor, which assumes knowledge of the meaning of terms and their context; the absence of this knowledge will lead to further misinterpretation on the part of the listener. A requirements engineer must know that such transformations take place, leading to a loss or change of information. Perception transformations occur because each person perceives reality differently and forms an individual picture. Representational transformations occur because a transformation takes place as soon as a person expresses this image in language. Another rule is that small changes in the requirements can lead to large changes in the
cost and deadlines, and changes must therefore be made as early as possible in the project to keep change costs low. However, the wrong impression of the requirements engineer can be corrected by asking several people about the same issue. Representation transformations can be resolved if the requirements engineer adheres to the rules. When they begin to speak or write, they make a series of choices regarding the shape of the information to be articulated, thus forming the associated surface structure, which is the transformed version of the original. However, in the surface structure, there may be missing or misinterpreted parts. From this assumption, the (linguistic) goal of requirements analysis is derived. In order to
obtain a complete and unaltered picture of a stakeholder’s personal perception, the requirements engineer must identify the corresponding deep structure from the surface structure. 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.
What is deletion in NLP?
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).
An example could be that a witness to the traffic accident notices that one of the participants had not been driving in a straight line, but thinks it insignificant and does not men-
tion anything.
Deletion can be useful in a certain context, but when demands are placed on a system,
important information is lost through erasure.
What is generalization in NLP?
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. A generalization that is not quite as correct would be the basic fear of touching all stoves (i.e., including cold ones), or the
assumption that one can only burn one’s fingers on a specific stove. What remains is the knowledge that touching any stove will lead to unwanted burns, and hopefully also caution about all stoves (since they can be hot).
Generalization is also useful and meaningful in the context of systems analysis. However, it is important to group the circumstances appropriately. For example, due to a prejudice
that young drivers with beards always drive too fast, one witness could think that they noticed one of the drivers speeding excessively. Excessive generalization creates global demands on a system that are only likely to be correct and meaningful for a subset of the system. Special and error cases are often lost in the process.
What is distortion in NLP?
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.
For example, a witness may describe one of the people involved in a car accident as “completely inattentive” as they were wearing sunglasses and listening to
music in the car.
Distortion also occurs when something is described with expressions that are not appropriate to that situation. Thus, the situation is embellished or clouded, and one’s own perception, or that of the receiver, is influenced (albeit mostly subconsciously). The phenomenon of distortion makes it easier for people to integrate new information into their
perceptions. Some details are changed a little, if necessary, to fit into the picture of a situation that has already been created. Thus, we often change a piece of information or our perception in a way that seems right to us. 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.
