Requirements Engineering Flashcards

RE: WHAT

• Definition of Requirements:
  • A need perceived by a stakeholder.
  • A capability or property that a system shall have.
  • A documented representation of (1) and (2).

Definition: Requirements Engineering (RE)

• Systematic and disciplined approach to the specification and management of requirements with the goal of understanding the stakeholders’ desires and needs and minimizing the risk of delivering a system that does not meet these desires and needs. [Adapted from the definition of Software Engineering in IEEE 610.12-1990]

RE: WHY

• Adds value in the process of developing and evolving a system:
  • Reducing the risk of developing the wrong system.
  • Better understanding of the problem.
  • Basis for estimating development effort and cost.
  • Prerequisite for testing the system.

SYMPTOMS of INADEQUATE RE

• Missing, unclear, incorrect requirements.
• Due to:
  • Rushing straight into building the system.
  • Communication problems between involved parties.
  • Assumptions that the requirements are self-evident.
  • Inadequate RE education and skills.

RE: WHERE (domain and environment)

• Examples include Mobile Web applications, Microsoft, SIEMENS, HSBC, Facebook, and Credit Suisse.

RE: WHERE

• System requirements – what a system shall do.
• Stakeholder requirements – what stakeholders want from their perspective.
• User requirements – what users want from their perspective.
• Domain requirements – required domain properties.
• Business requirements – business goals, objectives, and needs of an organization.

RE: HOW?

• Major tasks of RE:
  • Elicitation (Topic 4):
    • To obtain requirements from the stakeholders.
    • To detail and refine them.
  • Documentation (Topic 3):
    • To describe requirements properly.
  • Validation and negotiation (Topic 8):
    • To check if requirements meet certain quality criteria and to resolve conflicts.
  • Requirements management (Topic 9):
    • To structure the requirements.
    • To prepare them for different roles.
    • To change and implement them consistently.
  • Tool support may help perform these tasks (Topic 11).
  • The activities/tasks can be parallel, iterative, or concurrent.

Role & Tasks of Requirements Engineer

• Not a job title, but a role that people play who:
  • Elicit, document, validate, and/or manage requirements as part of their duties.
  • Have in-depth knowledge of requirements engineering.
  • Can bridge the gap between the problem and potential solutions.
• In practice, business analysts, application specialists, product owners, systems engineers, and even developers act in the role of a Requirements Engineer.

CHARACTERISTICS of A Requirements Engineer

• Usually the one with direct contact with stakeholders.
• Has both the ability and responsibility to become as familiar as possible with the domain and to understand it as well as possible (knowledge domain).
• 7 attributes:
  • Analytical thinking
  • Empathy
  • Ability to communicate
  • Ability to solve conflicts
  • Ability to moderate
  • Self awareness/confidence
  • Persuasiveness

FUNDAMENTAL PRINCIPLES OF RE: OVERVIEW

• RE is governed by a set of fundamental principles that apply to all tasks, activities, and practices.
  • Task: coherent chunk of work to be done (e.g., eliciting requirements).
  • Activity: action(s) performed to accomplish a task (e.g., identifying stakeholders when eliciting requirements).
  • Practice: a proven way of how to carry out certain types of tasks or activities (e.g., using interviews to elicit requirements from stakeholders).

9 FUNDAMENTAL PRINCIPLES OF RE

1. Value orientation: Requirements are a means to an end, not an end in itself.
2. Stakeholders: RE is about satisfying the stakeholders’ desires and needs.
3. Shared understanding: Successful systems development is impossible without a common basis.
4. Context: Systems cannot be understood in isolation.
5. Problem, requirement, solution: An inevitably intertwined triple.
6. Validation: Non-validated requirements are useless.
7. Evolution: Changing requirements are no accident, but the normal case.
8. Innovation: More of the same is not enough.
9. Systematic and disciplined work: We can’t do without RE.

1. Value orientation: Requirements are a means to an end, not an end in itself

• Value of requirements = benefit – cost
• Benefit
  • Contribution to build systems which satisfy the desires and needs of its stakeholders
  • Reduce the risk of failure and costly rework when developing the system
• Cost
  • Resources spent for eliciting, documenting, validating and managing requirements

2. Stakeholders: RE is about satisfying the stakeholders’ desires and needs

• Dealing with stakeholders is a core task of RE
• Different views of needs and viewpoints may result in conflicting requirements

Viewpoints

• The same building. Different views. Different viewpoints by different stakeholders must be taken into account.

Consensus and variability

• The viewpoints and needs of different stakeholders may conflict.
• Requirements Engineering implies
  • Discovering conflicts and inconsistencies
  • Negotiating
  • Moderating
  • Consensus finding
• But: also determine where variability is needed.

3. Shared understanding: Successful systems development is impossible without a common basis

• A basic prerequisite for any successful development of systems.
• Created, fostered, and assured in Requirements Engineering.
• Two forms of shared understanding:
  • Explicit (achieved by documented and agreed requirements).
  • Implicit (based on shared knowledge about needs, visions, context, etc.).
• Practices for achieving shared understanding: glossaries, creating prototypes, or using existing systems as a reference.

Shared understanding: the problem

• Explicit / implicit
• True / false
• Relevant / irrelevant

Forms of shared understanding [Glinz and Fricker 2015]

• Presents a table categorizing shared understanding into:
  • True explicit shared understanding
  • False explicit shared understanding (misunderstandings exist)
  • True implicit shared understanding of considered, but irrelevant information
  • Explicitly specified and truly understood, but irrelevant
  • Explicitly specified and misunderstood and not relevant
  • False implicit shared understanding of considered, but irrelevant information
  • Relevant, but not noticed by anybody (“Dark” information)
  • Dependable implicit shared understanding of relevant information
  • Explicitly specified and truly understood and relevant information
  • Explicitly specified and misunderstood and relevant
  • False implicit shared understanding of relevant information
  • Divides the understanding by Explicit Shared Understanding (ESU) and Implicit Shared Understanding (ISU)

4. Context: Systems cannot be understood in isolation

• Requirements never come in isolation.
• Requirements specify a system.
• The system may be part of another system.
• The system is embedded in a domain context.
• The scope of a system may exceed the system boundary.

Defining the context boundary

• Context boundary:
  • Which aspects pertain to the system context –related to the system to be developed?
  • Which aspects are part of the irrelevant environment?

Defining the system boundary

• System boundary:
  • Which aspects pertain to the system to be developed?
  • Which aspects belong in the system context?

scope

• SCOPE … is the system to be developed.
• Part of system context.
• Is the system.
• Define after system boundary is defined.
• Parts of reality that can be modified or altered by the development process; hence changes in the scope don’t typically require the consulting of the interface partners.

Documenting the system context: context diagram

• Shows:
  • External actors that want to interact with the system.
  • What input can these provide.
  • What output they wish to receive.
• Generally only one process and includes no data entities.
• Diagram includes:
  • One process or problem statement.
  • One or more end points.
  • Data flow – the interface between the problem statement and the environment.

Documenting the system context: use case diagram

• Shows:
  • External actors that want to interact with the system.
  • Through which use cases they want to interact with the system.
• Diagram includes:
  • One or more actors.
  • One system boundary and the name of the system.
  • The use cases, which the system has to support.
  • The relationship between the actors and use cases.

5. Problem, requirement, solution: An inevitably intertwined triple

• Problem – the as-is situation that is not satisfied by stakeholders.
• Requirements – capture what the stakeholders need in order to get rid of the problem or to simplify it.
• Solution – socio-technical system that satisfies these requirements.
• Cannot be tackled in isolation.

6. Validation: Non-validated requirements are useless

• Process of confirming that the documented requirements match the stakeholders’ needs.
• Every requirement needs to be validated.
• The ultimate question: Does the deployed system actually match the stakeholders’ desires and needs?
• The risk-reduction question: Do the documented requirements match the stakeholders’ desires and needs?

7. Evolution: Changing requirements are no accident, but the normal case

• Reasons for changing requirements:
  • Changed business process.
  • Competitor’s launching new products or services.
  • Clients changing their priorities or opinions.
  • Changes in technology.
  • Feedback from system users asking for new or changed features.
  • Detection of errors in requirements or detection of faulty domain assumptions.

8. Innovation: More of the same is not enough

• Requirement Engineers are not stakeholders' voice recorders.
• Problem-solvers.
• Innovative ideas.
• Good requirement engineers go beyond what stakeholders tell them.

9. Systematic and disciplined work: We can’t do without RE

• RE needs to be performed in a systematic way, regardless of the process used to develop a system.
• Agility and flexibility are not valid excuses for an unsystematic, ad-hoc style of work in RE.
• Systematic and disciplined:
  • Configure an RE process that suits the problem at hand with the process used for developing the system.
  • Do not always use the same process, practices, and work products.
  • Do not reuse processes and practices from the past successful RE work without reflection.
  • No “one size fits all”.

3 types of requirements

• Functional:
  • Use cases
  • Business rules
  • Data
  • State
  • Error handling
  • interfaces classified into: functional, behavioural & data/structure
  • Big influence on system architecture
  • Is not implemented but limit the solution space
  • Requirement concerning a result of behaviour that shall be provided by a function of the system
• Quality (how well system behave):
  • Performance
  • Security
  • Reliability
  • Usability
  • Maintainability
  • Portability
  • Requirement that pertains to a quality concern that is not covered by a functional requirement
• Constraints (organisational and technical):
  • Development process
  • Budget
  • Deadlines
  • Team
  • Legislation
  • Norms
  • Guidelines
  • Standards
  • Operations
  • Requirement that limits the solution space beyond what is necessary for meeting the given functional and quality requirements

Categories of quality requirements

1. Performance (e.g., response time behaviour and resource utilisation)
2. Security
3. Reliability (availability, dependability, fault tolerance, recoverability)
4. Usability (understandability, learnability, ease of use)
5. Maintainability (analysability, changeability, stability, testability)
6. Portability (adaptability, instalability, replaceability)
   • Examples:
     • The application shall load and display data from the database within 3 seconds for standard user queries.
     • The web shop supports 100 concurrent customers.
     • The insurance system provides user authentication.
     • The application shall implement encryption for data in transit and at rest to comply with industry standards.
     • In the event of a failure, the system should recover automatically within 5 minutes. Downtime for maintenance is maximum 24hrs per month.
     • The user interface shall follow established usability guidelines and receive a minimum score of 80 in user satisfaction surveys.
     • The insurance system supports all common touch screen gestures.
     • The calculation for the costs of the insurance policy changes every year due to a federal law. The calculation for the costs of the insurance policy needs to be tested via automated tests so that changes can be validated automatically.
     • The client for the insurance system needs to run on internet Explorer 10 (and above). The client for the insurance system provides an automatic installer so that insurance agents can install the client themselves.

Assign the following requirements to: Functional(F), Quality(Q) or Constraints(C).

• The system shall allow to import student data from the legacy tool X. (F)
• The system shall run on Windows and Mac OS. (C)
• The project shall go into production in July 2024. (C)
• Students must enter user-name or identity card number to register. (F)
• The project should be developed off-shore. (C)
• The system shall complete saving citizen’s data within 5 seconds. (Q)
• Program level guidelines in terms of user interface have to be followed. (C)
• The system shall allow new users to be quickly up to speed where basic functionality shall be possible to learn from the user interface, mid-complex workflows shall be supported with a help system. (Q)