Correctly assign the following characteristics of requirements engineers to their definition:

In requirements engineering, survey techniques…

Which of the following statements about support elicitation techniques in requirement engineering
is/are correct?

Which of these statements regarding conceptual models in requirements engineering is/are correct?
Which of the following statements about requirements document quality criteria is/are correct?

In the Kano model…

What are the advantages of natural language-based requirement documentation?

Template-based textual use-case specification…

Use-case modelling is
User stories…

The three C’s according to Jeffries…

Acceptance criteria can be expressed…

Product backlog items…

Which of the following are valid assumptions about content if code has gone through alll technical
procedures?

When should DoR be used?

Which of the following are signs that a user story could be too technical?

Comments in Gherkin…

Which of the following statements regarding the Given keyword in Gherkin is/are correct?
The Gherkin language…

The BDD approach to user stories…

Which of the following statements about the combination of BDD and TDD is/are true?

TDD…

What statements can be made about documentation created while using BDD?
Which of the following are steps of a normal working process with BDD?

BDD…

Regarding the BDD approach to user stories, correctly assign the stakeholders to their tasks.

Testing for gaps in story maps…

What are tasks involved in creating a user story mapping?

The Elicitation phase…

Which of the following statements regarding the system context and system boundary is/are correct?

Describe in your own words why Requirements Engineering is needed?

Requirements engineering is necessary because unclear, incomplete, or wrong requirements
inevitably lead to the development of a system that does not possess critical properties or
possesses properties that were not requested.
It is also necessary because in later stages of the development of a project when a defect in the
requirements is corrected, the higher are the costs associated with fixing it.
It is also necessary because it prevents different interpretations of the requirements.

Describe the categorization of requirements according to the Kano Model.

Dissatisfiers:
-Properties of the system that are self-evident and taken for granted (subconscious
knowledge)
-Must be fulfilled by the system in any case
-Dominantly influenced by existing systems Solved through observation and document-
centric techniques
Satisfiers:
- Explicitly demanded system properties (conscious knowledge) o Can be elicited well
using survey techniques
Delighters :
- System properties that the stakeholder does not know or expect and discovers only
while using the system – a pleasant and useful surprise (unconscious knowledge)
- Creativity techniques are best suited to elicit delighter
What are the three perspectives of requirements? List and describe them shortly.
1. Data perspective
- Static-structural
- Example: Structure of input and output data
2. Functional perspective
- Documents which information (data) is received from the system context and
manipulated by the system or one of its functions
- The order in which functions processing the input data are executed is also
documented
3. Behavioral perspective
- State-oriented
- Document the reactions of the system upon events in the system context
- Example: effects of the system analyzed that represent events in the system context of a
different system

Please list and describe the notation elements of the Use Case Diagram.
Akteur:
- als Person
- als Rechteck
- als Icon

Beziehungen:
- um Assoziationen zwischen Akteur und Anwendungsfall zu symbolisieren
- Generalisierung/Spezialisierung
- Es gib:
include: A beinhaltet B
extend: A extends B

- Kommenator = ich glaube das erklärt sich von selbst.

What is the difference between system boundaries and context boundaries and what is
part of the systems context?
System boundary:
The system boundary separates the planned system from its environment. It demarcates the
part of reality that can be shaped and changed within the development process from aspects in
the environment that cannot be changed by the development process.
System context:
The system context is the part of the environment of a system, relevant for the definition and
understanding of the requirements of the system under consideration

Context boundary:
The context boundary separates the relevant part of the environment
of a planned system from the irrelevant part, i.e. the part of the environment
which has no influence on the planned system and therefore no influence on the requirements of this
system.
on the requirements of this system.

Which types of Elicitation Techniques do you know?

- Survey Techniques
- Creativity Techniques
- Document-centric Techniques
- Observation Techniques
- Support Techniques

What is a glossary and which elements does it contain?

All relevant terms must be defined in a common glossary to remove
misunderstandings. A glossary must contain the following elements:
- Context-specific technical terms
- Abbreviations and acronyms
- Everyday concepts that have a special meaning in the given context
- Synonyms, i.e., different terms with the same meaning
- Homonyms, i.e., identical terms with different meanings
Which views are part of the dynamic view of Requirements Modeling?
In Requirements Modeling, the dynamic view describes the behavior of the system and
how it responds to different inputs and events over time. It typically includes the
following views:
1. Use Case View
2. Activity View
3. State Transition View
4. Sequence View
Overall, the dynamic view of requirements modeling focuses on describing the behavior
of the system and how it responds to different inputs and events over time.

Please list and describe the transformational effects of natural language for describing
requirements by self-chosen examples.

Which of the following statements regarding Epics/User-stories/Themes is/are correct?

What's the meaning and the purpose of the 3C principle?
The 3C principle, or the three critical aspects of user stories, is a concept used in agile
software development to ensure that user stories are effective and useful.
- Card
- Conversation
- Confirmation
The 3C principle is intended to ensure that user stories are focused, relevant, and useful.
By starting with a brief written description, having a conversation to clarify the details,
and confirming the story with acceptance tests, the development team can ensure that
they are building software that meets the needs of the customer or end user.

What's the meaning and the purpose of the INVEST principle?

The INVEST principle are guidelines to write good user stories.
- Independent: The user story should stand on its own, not dependent on other user
stories. Can be implemented and tested on its own - Negotiable: User stories should be
flexible, so they can be modified as the project progresses
- Valuable: User stories should provide value to the end-users and customers.
- Estimable: It should be possible to estimate the amount of work a user story needs to
be implemented
- Small: A User story should be small enough to be implemented in one sprint.
- Testable: A user story should be testable, so that it can be verified that the functionality
has been implemented correctly

Which of the following statements regarding Epics/User-stories/Themes is/are correct?

What do you know about acceptance criterias?
- When the user story is defined
- So it is clear when a user story is correctly implemented, defines conditions by which a
requirement is fulfilled
- The stakeholders/client/end-user
- user stories - one for every user story
- An acceptance criteria always refers to one specific user story, DoD is the same for
every user story, the fulfillment of the acceptance criteria can be a criteria for the DoD

How are acceptance criteria structured in BDD?

In Behavior Driven Development (BDD), acceptance criteria are typically structured using a
specific format known as the "Given-When-Then" (GWT) format.
The GWT format is a way of describing a behavior or feature in terms of the conditions under
which it should occur (Given), the action or event that triggers the behavior (When), and the
expected outcome or result (Then). This format helps to ensure that the acceptance criteria
are clear and well-defined, and that they accurately capture the requirements of the feature
being developed.

What is the purpose of BDD and who is involved?

Helps with normal English language to facilitate the communication between non-tech
and tech people.
Who is involved?
- Business stakeholders/customers
- Developers
- Testers/QA professionals

What is the difference between BDD and TDD?

In TDD, a written test case is used to check the efficacy of application functionality BDD
tests the system’s behavior from the end-user’s perspective
TDD = Write tests for each functionality and implement code according to these tests
until they pass.
BDD = Is an extension of TDD, tests are instead focused on the behavior of the system
from the users’ point of view. Most common approach is Given-When-Then testing Helps
with normal English language to facilitate the communication between non-tech and
tech people
How are acceptance criteria structured in BDD?
In Behavior Driven Development (BDD), acceptance criteria are typically structured using
a specific format known as the "Given-When-Then" (GWT) format.
The GWT format is a way of describing a behavior or feature in terms of the conditions
under which it should occur (Given), the action or event that triggers the behavior
(When), and the expected outcome or result (Then). This format helps to ensure that the
acceptance criteria are clear and well-defined, and that they accurately capture the
requirements of the feature being developed.

What are 'scenario outlines' used for in Gherkin? Give an example.

Scenario Outlines in Gherkin are used to represent a template or a pattern of steps that
can be used to generate multiple concrete scenarios. Scenario Outlines are useful when
you want to test a feature or functionality using multiple test cases with similar behavior
but different input values.
Example of a Scenario Outline:

Feature: Login Functionality Scenario Outline: Valid Login Given I am on the login page
When I enter "<username>" and "<password>" And I click on the Login button Then I
should see the Dashboard page Examples: | username | password | | john | secret | | jane |
password | | jim | abcd1234 |

In this example, we are testing the login functionality of a web application using a
Scenario Outline. The Scenario Outline defines a template for the test case with a set of
steps that will be executed for each set of input values provided in the Examples section.