Processes and Requirements

Shows how different software artifacts can be validatied — not a process model

1. Validation: "Did we build the right product?" (business perspective)

2. Verification: "Did we build the product right?" (technical perspective)

→ Validation is case-based; Verification checks consistency between artifacts

Meeting in which a Software artifact is examined/evaluated (looking at quality and correctnes,…)

Types

• inspection (check if there are problems)

• team review

• walkthrough

• pair programming (one is coding one is checking)

• pass-around, ad-hoc review (documentation is produced, send around and comments are expected)

=> remove 60-90% of errors before testing is even started

Why not used?

- consultants cannot make money

- not new

- increased up front cost

- requires consideration of psychological factors

Dangers of Reviews:

• Testing is omitted because teams assume reviews catch all errors

• Authors feel frustrated or even violated by harsh reviews

• Sloppiness: "Errors will be found during review anyway"

Dangers for Reviews:

• Managers cut review time under deadline pressure

• Reviewers are unprepared, making the process a waste

• Obfuscation: Authors hide errors behind tricky or unclear code/documents

Benefits

-> Quality, correctness

-> improved understanding on project (less dependency on one person)

-> Teaching for beginners

-> better code (readibility, good documentation)

1. Planning – Schedule, define goals, select participants

2. Overview – Author presents artifact and context

3. Preparation – Reviewers study the material individually

4. Meeting – Team discusses findings and defects

5. Rework – Author fixes identified issues

6. Follow-Up – Check if rework was done correctly

7. Causal Analysis – Identify root causes of common defects

1. Author – Creates the artifact

2. Moderator – Organizes and leads the review

3. Reader(s) – Reads the document aloud or explains it

4. Recorder – Logs all findings and decisions

5. Verifier – Confirms whether issues have been resolved

(see 7 steps)

• based on test cases

• hypothesis based reading

• architectural reading

1. The Alcoholic Pattern

   • Roles: Addicted (e.g., always late/unprepared), Helper, Punisher, Ashamed

   • Dysfunction: Review becomes a loop of enabling and blame, not improvement

2. The "Now-I-Have-Got-You" Pattern

   • Reviewer A catches B's mistake and uses it to dominate

   • B is defenseless → leads to fear and silence

3. The "See-What-You-Made-Me-Do" Pattern

   • A blames their error on reviewer B’s previous suggestion

   • Undermines mutual responsibility and trust

4. The "If-It-Were-Not-For-You" Pattern

   • A claims: “If it weren’t for you, I’d have succeeded”

   • A uses hypothetical blame to avoid accountability

5. The "Look-How-Hard-I-Tried" Pattern

   • A highlights effort to excuse poor results

   • Shifts focus from quality to sympathy

6. The "Yes-But" Pattern

   • B blocks improvements by deflecting with "yes, but..."

   • Avoids responsibility while defending poor solutions

7. The "Wouldn’t-It-Be-Nice-If" Pattern

   • B suggests fancy additions to show off, ignoring A’s constraints

   • May push A into defensive or "yes-but" mode

w

A software process model is an abstract representation of a software development process.

It defines:

• Activities to be carried out

• Roles and responsibilities

• Artifacts to be produced

• techniques and tools to be used

→ Models that define the order of phases and transition criteria are Life cycle models (e.g., Waterfall, V-Model)

The Waterfall model is a sequential process model with feedback to earlier phases.

Phases:

1. Planning

2. Definition

3. Design

4. Implementation

5. Test

6. Use & Maintenance

→ "we can specify a system completely upfront"

The V-Model is a verification and validation-oriented life cycle model.

• Left side: Development phases (from requirements to implementation)

• Right side: Corresponding testing phases (unit test to acceptance test)

• The “V” shape shows that each development step has a test counterpart

→ Encourages early thinking about tests and traceability from requirement to test

Iterative processes develop software in repeated cycles, allowing feedback and changes at each iteration.

Key Characteristics:

• Each iteration includes: requirements → design → implementation → test

• Working software is delivered early and improved continuously

• Promotes feedback-driven development and risk reduction

→ Helps deal with uncertainty, evolving requirements, and complex systems

Incremental development delivers the system in small, functional pieces, each adding value.

Evolutionary development allows the system to adapt and evolve as understanding improves.

• waterfall model

• the original V model

• the spiral model

explaining how to incorporate

1. development phases

2. testing

3. risk management

such that a full grown process can be pieced together

The Unified Process (UP) is a framework for development.

Defines

• 4 Phases

• 9 Disciplines

Benefits:

• iterative und incremental

• risk-driven

• client-driven

• architecture-centric

1. Inception

   • Define project vision, scope, and feasibility

   • Identify critical use cases, initial risks, rough estimate

2. Elaboration

   • Refine requirements, establish baseline architecture

   • Resolve high risks, plan construction phase in detail

3. Construction

   • Build the system incrementally

   • Focus on coding, testing, and integration

4. Transition

   • Deliver the final product to users

   • Handle user feedback, training, and defect correction

1. Business Modeling – Understand business context

2. Requirements – Capture and manage stakeholder needs

3. Analysis & Design – Define and design the system structure

4. Implementation – Code and build components

5. Testing – Verify functionality and quality

6. Deployment – Deliver and install the product

7. Configuration Management – Manage versions and artifacts

8. Project Management – Plan, track, and control project progress

9. Environment – Provide tools, standards, and processes

RUP additionally defines roles, activities/tasks, and artefacts/work products

Agile Manifesto = Core values and priorities for agile development (2001)

• Individuals and interactions > Processes and tools

• Working software > Comprehensive documentation

• Customer collaboration > Contract negotiation

• Responding to change > Following a plan

Value exists in both sides, but left side is prioritized

You cannot plan ahead

You need to monitor continously

XP = A set of values, principles, and practices for agile development

Values

• Communication

• Simplicity

• Feedback

• Courage

Principles

• Quick delivery

• Rapid feedback

• Embrace change

• Incremental change

• Project, team, and individual-level practices

1. Just enough design

2. Write tests first (TDD)

3. Implement -> Modeling tools like CRC cards may be used

• Seems ad-hoc and hard to scale

• Lack of documentation and reuse

• Client collaboration is demanding

• Practices (e.g., pair programming, TDD) need more validation -> Higher cost, steep learning curve

Scrum = Agile management framework for software development

• 3 roles, 4 meetings, 3 artefacts

• Work delivered in time-boxed Sprints (usually 30 days)

• Based on Agile Manifesto values -> People are the key resource

Scrum Key Elements

• Product Owner creates and maintains Product Backlog

• Sprint Planning defines Sprint Backlog

• Daily Scrum syncs team

• Scrum Master supports the team

• Sprint yields a product increment

• Sprint Review + Retrospective evaluate and improve

1. Roles: Product Owner, Scrum Master, Team

2. Meetings: Sprint Planning, Daily Scrum, Sprint Review, Retrospective

3. Artefacts: Product Backlog, Sprint Backlog, Increment

1. Sprint Planning: plan the Sprint

2. Daily Scrum: share status, uncover issues

3. Sprint Review: demo shippable product

4. Sprint Retrospective: reflect and improve

Sprint = Time-box (≤ 1 month) producing a “Done” product increment

• No changes that threaten Sprint Goal

• Quality goals remain constant

• Scope may be re-negotiated

-> Continuous, consistent cycle of improvement

1. Product Owner: defines priorities and vision

2. Team: implements product

3. Scrum Master: ensures Scrum is followed -

"Pigs" (committed) vs. "Chickens" (involved)

=> individuals and interactions over processes and tools!

decides what will be delivered and is responsible for the result

The ideal Scrum Master is a moderator, coach and experienced software developer

self organised, implements the product increment

= High-level list of features (user stories) prioritized by business value

-> Evolves during the project

Items:

• Requirements captured as user stories

• not too many at once 2–3 sprints

• Must highlight essential features

• Coarse descriptions refined later

Scrum Planning = 3 levels of planning

• Release planning (based on backlog and velocity)

• Sprint planning

• planning of a workday

Pick next prioritized user story

Identify all required activities

• E.g., design, testing, documentation, review, refactoring

• Activities must:

  • Be clear

  • Take ≤ 16 hours

  • Be estimated in 2–4 hour increments

-> not more than 85% of the capacity

Net = available days – distractions (25–35%)

Example:

• 5 devs × 18 days = 720 hours

• Net = 480h → 85% = 408h available

2 metrics:

the effort (i.e. the “distance”) d required to work off the product backlog

the time t required to implement the whole product backlog can then be calculated with the following equation

~48% of project failures due to RE issues

-> Requirements are missing

-> Requirements are wrong or misunderstood

-> Stakeholders are not involved

Fixing errors later is expensive -> Early RE reduces risk and cost

Requirement = Condition or capability needed by user/system

• Needed to solve a problem or meet objectives

• Must be met to fulfill contracts/specs

• Documented representation of those conditions

= Foundation and contract of the development process

-> Most important artifact in software projects

• Elicitation (gathering needs)

• Documentation (create SRS)

• Agreement (conflict resolution) Cross-cutting

• Validation

• Management

= Anyone (in)directly influencing system requirements

-> missing stakeholders may lead to missing requirements

Requirements Engineer

• Acts as translator between users and devs

• Skills: analytical, empathetic, communicative, conflict-resolving -> Responsible for elicitation, documentation, agreement

Different stakeholders = different perspectives (that may conflict)

-> RE must manage all viewpoints

Systems are part of domains and other systems

-> Dealing with multi-level requirements is unavoidable

= Relevant part of the environment needed to understand the system

1. System boundary = between system and environment

-> system boundary separates the system to be developed from its environment

1. Context boundary = between relevant and irrelevant domain parts

Real-world requirement (RWorld) must be satisfied by system (RSystem)

Given: Machine spec S, Domain D

Then: S ∧ D ⊨ R (real-world requirement)

-> S must satisfy R only under domain assumptions

Requirements Elicitation = Process of discovering requirements from stakeholders and sources

Who should elicit requirements?

Elicitation Roles

• Stakeholders: provide domain knowledge

• Requirements Engineers: guide process

• (Smart ignoramus: unbiased questioning)

1. Ask: interviews, polls

2. Collaborate: workshops, role playing

3. Build & Play: prototypes, mock-ups

4. Observe: user behavior

5. Analyze: artifacts, bug reports, market studies

-> Use varied methods for rich input

1. Ask about solution restrictions

   • Technical, legal, organizational, cultural

2. Check for hidden requirements -

> Constraints may mask actual needs

Non-Functional Requirement Issues

• Often misunderstood or misused

• Confused with global, soft, or supplementary features

-> Focus on the concern, not terminology

A concern is a matter of interest in a system

-> can be used to classify requirements

Concern-based Classificaiton

• Behavior/input/reaction → Functional

• Desired system quality → Quality

• Prescribed restriction → Constraint

-> Ask: “What is the real concern?”

Functional,

Quality,

Constraint (limitation, like legal, environmental, physical)

Recognizing Representations

• Operational = action verbs

• Quantitative = measurable

• Declarative = reviewable

-> Don't confuse quality kind with qualitative requirement

Writing Guidelines

• Short, active sentences

• One requirement per sentence

• Avoid vague terms (“easy”, “quickly”)

• Use template (see SS)

-> Maintain glossary for consistent terms

Most common:

1. User Stories (agile)

2. Use Cases (model-based)

= Am I building the right system?

= Checking if requirements are correct and complete

1. Reviews (formal or informal)

2. Acceptance Tests

3. Simulations

4. Prototyping

5. Model checking

• Necessity

• Cost

• Time

• Risk

• Volatility

-> done by stakeholders, only a subset is prioritizeed

Simple ranking

Assigning points

Prioritization methods:

• MoSCoW (MUST, SHOULD, COULD, WON’T)

• Cost Value Analysis (value vs. cost, risk, volatility)

• Kano Model (Attractive, Performance, Must-be, etc.)

Cost for removing errors depends on how long it stays in the software

The ability to trace a requirement

(1) back to its origins,

(2) forward to its implementation in design and code,

(3) to requirements it depends on (and vice-versa).

1. Manually: high effort, needs consistent naming and updates

2. Automatically: IR-based candidate links + manual review -> Tool support is essential for efficiency

Uses various models:

• Use Case Texts

• Use Case Diagrams

• Activity Diagrams

-> Use Case Texts are just a notation

-> Use cases define a contract of behavior between system and users

• Describes system as black-box interactions

• Captures operational requirements

use cases are a notation to textually capture an interaction of (typically) two parties

Identify relevant actors and system boundaries

Different scopes → different goals and actors -> Understand context to define meaningful use cases

• System Boundary = interface of system to environment

• System Context = relevant environment for RE

• Context Boundary = separates relevant from irrelevant -> These evolve during elicitation

Good Use Cases

• Vary in granularity (e.g., “negotiate contract”, “withdraw money”)

• Focus on goal achievement

-> Best at Elementary Business Process (EBP) level

a task

performed by one person

in one place at one time,

in response to a business event,

which adds measurable business value

and leaves data in a consistent state

e.g. approving a credit request

1. Boss Test = would your boss be happy?

2. Coffee Break Test = finish a use case when would you intuitively make a coffee break

3. Size Test = not just one step -> Focus on meaningful goals

Diagramming Tips

• Focus on user-goal level use cases

• Don't overdo diagrams—text is primary

• Place primary actors left, supporting right

• Use <<include>> and <<extend>> properly

-> Diagrams are for clarity, not completeness

Stakeholder = person/org with interest in the system

Actor = interacts with system (role/system/org), Primary actor initiates use case

Use case model = is the set of all use cases and related diagrams

Scenario = specific sequence of actions (an instance)

Use Case = collection of related scenarios (success & failure)

-> A use case is a set; a scenario is a story

-> Goals initiate scenario definition

-> Scenarios concretize and refine goals

1. Define system boundary

2. Identify primary actors

3. Identify user goals

4. Define use cases for goals (imperative names)

   -> CRUD goals often grouped (Create, Retrieve, etc.)

Use cases are complex

-> Iterative Refinement, work breadth-first

Precision levels:

1. primary actor's name and goal

2. use case briefs or main success scenario

3. add extension conditions (failure conditions)

4. add extension handling steps (failure handling) + more

1. Fully Dressed: full details and structure

2. Casual: plain text

3. One-/Two-Column: actor & system side-by-side

4. RUP Style: similar to fully dressed

Steps describe 1. interactions, 2. validation, or 3. internal change (between user ans system)

e.g. ATM, insert card, validate card, deduct amount from balance

Precision levels

1. Data nickname

2. Data fields associated with nickname

3. Everything

<<include>> through underlining

1. Preface: scope, level, primary actor

2. Stakeholders & Interests: who cares and why

3. Pre Conditions: must be true before starting

4. Post Conditions: what’s true after success

5. Main Success Scenario (Describes happy path)

6. Extensions = describe all other scenarios or branches both success or fail

   - labeled with two parts: Condition (how system detects), Handling part

7. Special Requirements = NFRs linked to this use case

8. Tech & Data Variations = tech-specific differences

NLP = Natural Language Understanding

• Models grammar, meaning, and language structure

• Uses algorithms to analyze and interpret text -> Enables computers to "understand" language

-> Automatic processing of requirements, documentation, issues,… = huge leverage across SE lifecycle

NLP Pipeline

• Tokenizer (splits text into units)

• Tagger (labels parts of speech)

• Stemmer/Lemmatizer (find base word forms)

• Parser (builds tree/graph structures)

• Discourse Analyzer (interprets meaning & context)

NLP can help identify problematic patterns

Requirement Quality Attributes = Key aspects of textual clarity

• Non-Ambiguity

• Completeness

• Consistency

• Understandability

QuARS Tool = Quality Analyzer for Requirements

• Uses dictionaries and analyzers

• Detects low-quality indicators -> Supports early requirement validation

RESI = Requirements Engineering Specification Improver

• Identifies and suggests fixes for quality issues

• Uses POS tags, ontology links, and linguistic rules -> Aims to improve clarity and structure

LLM = Predictive language model

• Predicts next word/sentence (fill the gap)

• Estimates probability of word sequences

• Promises semantic understanding -> Useful for context-aware tasks in SE

Word Embeddings = Vector representation of words

• Compact, meaningful vectors

• Enable arithmetic operations & semantic comparisons

-> Foundation for LLMs (e.g., king – man + woman ≈ queen)

= Core architecture of almost all LLMs

• Encoder & Decoder components

Key part: (Self-) Attention Layer

▪ Assesses which part of the input should be focused? Which/How do parts of the input relate?

▪ Fundamental for the capabilities and success of LLMs

▪ Feed-Forward Neural Network: Main training layers

1. Masked Language Modeling (e.g., BERT)

2. Next Sentence Prediction

3. RLHF (Reinforcement Learning with Human Feedback)

1. Zero-Shot: Just give the task description

2. One/Few-Shot: Provide examples for better results

3. Fine-Tuning: Train further with task-specific data -> Approach depends on task complexity

1. Stores knowledge as vectors (vectorstore)

2. Retrieves relevant chunks for a query

3. Provides retrieved info to LLM -> Reduces hallucinations & improves factual accuracy

Identify requirement types:

• Functional

• Quality (e.g., performance, usability)

• Constraint (e.g., platform, standards) -> Enables better analysis, prioritization, and processing