ITEC 4040 - L5: Negotiation, Validation, Verification

Requirements Negotiation

Process of reconciling stakeholder needs and priorities to reach agreement on system requirements.

Conflict in Requirements

Situation where stakeholder needs contradict or cannot all be met, reducing project support.

Conflict as Opportunity

Conflicts can inspire new and innovative requirements rather than just obstacles.

Developers' Role in Conflict

Developers and testers should report conflicts to requirements engineers for analysis and resolution.

Identify Conflicts

Monitor through all stages of requirements engineering to detect potential contradictions early.

Analyze Conflicts

Classify the type of conflict—data, interest, value, relationship, or structural—for targeted resolution.

Resolve Conflicts

Apply negotiation, creative solutions, or decisions to reach a mutually acceptable agreement.

Document Resolutions

Record outcomes and rationale to ensure traceability and transparency.

Data Conflict

Occurs due to misinterpretation or misinformation among stakeholders; resolved by clarifying meaning.

Interest Conflict

Arises from differing stakeholder goals or priorities, e.g., feature-rich vs cost-effective solutions.

Value Conflict

Stems from differences in cultural or moral values; requires understanding stakeholder backgrounds.

Relationship Conflict

Triggered by interpersonal tension or disrespect between stakeholders.

Structural Conflict

Caused by power imbalance or authority hierarchy between stakeholders.

Negotiation Strategy

Involves information exchange and compromise to reach a win-win outcome; time-consuming but fair.

Creative Solution Strategy

Uses brainstorming or innovation to create new alternatives that satisfy all parties.

Decision Strategy

Relies on an authoritative choice or voting to resolve issues quickly but may cause dissatisfaction.

Win-Win Approach

A negotiation outcome where all parties gain something; contrasts with win-lose or lose-lose scenarios.

Interaction Matrix

A table mapping requirement interactions (+1 positive, 0 neutral, -1 conflict) to visualize dependencies.

Validation

Ensures the system meets stakeholder needs; asks 'Are we building the right thing?'.

Verification

Ensures the system is correctly built; asks 'Are we building the thing right?'.

Purpose of Validation and Verification

Ensure quality by checking that all activities, inputs, and outputs meet standards.

Consequences of Poor Validation

Can cause legal issues, error propagation, and increased costs due to late corrections.

Stakeholder Inclusion

Ensures all relevant participants contribute to validation for complete perspective coverage.

Defect Detection vs Correction

Validation should identify issues independently of fixing them to maintain objectivity.

Multiple Independent Views

Using multiple evaluators increases reliability and completeness of validation results.

Requirements Documentation Formats

Use natural language for clarity and visual models for precision, balancing both as needed.

Repeat Validation

Should be performed continuously as requirements evolve over time.

Scenario-Based Validation

Involves running example scenarios or walkthroughs to confirm requirements understanding.

Storyboards

Visual narratives showing system use through images or mockups for stakeholder validation.

Passive Storyboard

Analyst-led presentation that demonstrates how the system will behave.

Active Storyboard

Animated or slideshow version providing partial interactivity.

Interactive Storyboard

Allows stakeholders to interact with mockups or prototypes to explore system behavior.

Role Playing

Technique where developers or stakeholders act out system roles to uncover hidden requirements.

Prototypes

Simplified models built to test or clarify unclear requirements quickly.

Throwaway Prototypes

Short-term versions such as presentation, exploratory, or experimental builds meant to be discarded.

Evolutionary Prototypes

Iteratively improved prototypes that evolve into the final system or MVP.

Vertical Prototype

Demonstrates depth by focusing on one or few features in full detail.

Horizontal Prototype

Covers breadth by including many features at a high level without depth.

Formal Proofs

Mathematical verification of logical consistency and correctness of system design or code.

Fagan Inspection

Structured review process involving planning, overview, preparation, inspection, rework, and follow-up stages.

N-Fold Inspection

Multiple teams inspect the same artifact independently, increasing defect detection coverage.

Desk Checks

Independent document reviews by peers or analysts to spot inconsistencies or errors.

Walkthroughs

Informal, author-led reviews where participants discuss and detect potential issues collaboratively.

Use Case Diagram Verification

Ensure each user has at least one use case and every case is tied to a valid actor.

Class Diagram Verification

Confirm all entities and operations align with identified use cases.

Sequence Diagram Verification

Validate that all interactions and messages between components are logically consistent.

State Machine Diagram Verification

Ensure all state changes are triggered by valid events and transitions.

ER Diagram Verification

Check entity relationships and cardinality for correctness and consistency with DFDs.

DFD Verification

Ensure all processes are labeled with verbs, avoid black holes and miracles, maintain data consistency.

Validation vs Verification Focus

Validation ensures building the right thing, while verification ensures it’s built correctly.

Fagan Inspection Steps

Planning → Overview → Preparation → Inspection → Rework → Follow-up.

Repeated Validation Importance

Essential as evolving requirements can invalidate prior approvals.