Informatics 43 — Week 2 Lecture Notes

Table of Contents

1. Software Failures
2. Why Requirements Matter
3. Requirements Engineering
4. Requirements Specification Document
5. Specification Methods and Verification
6. Ziv's Law
7. Wrap-Up and Memory Framework

1. Software Failures

1.1 The real problems behind failure

The failure readings identify several root causes for why software projects go wrong: complexity, conformity (having to integrate with existing human systems), difficulty measuring progress, the burden of "legacy" systems, and "Hubble Psychology" (overconfidence or groupthink that prevents teams from seeing problems).

Hubble Psychology — named after the Hubble Space Telescope — refers to the belief that if you keep pouring money into a failing project, it will eventually work out. The Hubble telescope was seen as a huge failure during development (Congress invested millions and NASA kept asking for more), but it eventually became a success. Other examples: Amazon was losing more than it was making for years before turning around. However, most projects with this mindset simply fail — like the California DMV modernization project that spent $134 million before the entire project was thrown away. Over-optimism is dangerous; software failures should be expected, and planning for them is essential.

1.2 Case study: Minnesota licensing system

Minnesota's license and registration system failed because the team never clearly defined roles or what the software should be. The project went massively over budget, with plans being revised again and again. HP was contracted to do the work but eventually stepped away from the project. This is a classic case of requirements issues combined with bad management — the team simply did not know what they were building.

1.3 Case study: TSB Banking

TSB, a UK bank, attempted to migrate from one infrastructure to another. On the day of the switch, customers could not log in or withdraw money. Those who could log in found their balances were wrong — some had no money, some had extra money, and some could even access other people's accounts. This is one of the most dramatic examples of what can go wrong during a software migration.

1.4 Case study: Shopa

Shopa was a British startup that shut down largely because the company never figured out what product to build. Internal teams had no shared understanding of the product direction, leading to conflict between engineering and sales. This is a textbook example of what happens when requirements are absent or unclear.

1.5 Industry statistics

1.6 Top software failure causes

The top causes of software project failure are:

1. Lack of user input/involvement — the most frequently cited problem
2. Incomplete requirements and specifications — requirements issues
3. Changing requirements and specifications — requirements issues
4. Lack of discipline in development processes — lack of rigor/formality
5. Lack of methodical usage of metrics — lack of rigor/formality
6. Lack of resources

The first three are all requirements issues. The middle two reflect a lack of rigor and formality — one of the INF 43 core principles from Week 1.

2. Why Requirements Matter

2.1 Definition

An important distinction: requirements address what a customer needs, not what a customer wants.

The "faster horse" analogy: A customer says they want a faster horse. Why? Because they need faster transportation. The best solution turns out to be building a car — something the customer never asked for, but exactly what they needed. Always dig deeper to find the real need behind the stated want.

2.2 Evidence for their importance

Poor requirements are the single most common reason projects stumble or fail. According to CHAOS reports, requirements defects account for more than 70% of rework costs, and rework itself consumes about 30–50% of the total project budget. Lack of user input and involvement is consistently listed as the most frequent problem.

2.3 Software life cycle costs

The vast majority of software cost comes after the initial build:

2.4 Cost of change grows over time

Changes are cheapest during analysis and specification. The cost increases dramatically as you move into design, implementation, integration, and especially maintenance. This is why investing time in requirements up front saves enormous cost later.

2.5 Which category employs the most programmers in the US?

A. In-house staff writing systems for internal use. Most programmers do not work at game companies or on consumer apps — they build internal business systems.

3. Requirements Engineering

3.1 The requirements phase in the waterfall model

In the waterfall model, the requirements phase is the very first stage. It is split into two sub-activities:

The expanded waterfall shows: Requirements Analysis → Requirements Specification → Design → Implementation → Verification → Maintenance.

3.2 Techniques for requirements analysis

There are many ways to discover what a system should do:

• Interview the customer — ask directly
• Observe the customer — watch how they actually work
• Create use cases / scenarios / user stories — describe interactions step by step
• Prototype solutions — build something quick to get feedback
• Identify important objects, roles, functions, goals
• Perform research — study the domain
• Construct models — create abstract representations
• Data-driven analysis — use analytics, A/B testing, prototyping, and market research to evaluate potential features

3.3 The todo list app example

The lecture walks through a "build me a todo list app" scenario to show how vague requirements evolve into precise ones. The first version has only six basic requirements. The improved version adds ordering, character limits, undo for delete, usability targets (complete tasks within 5 minutes without training), calendar integration, and social sharing.

Good requirements should be: complete, unambiguous, non-conflicting, and verifiable.

4. Requirements Specification Document

4.1 Purpose

The requirements specification serves as the fundamental reference point between the customer and the software producer. It defines the "what" (not the "how"), environmental constraints, software constraints, and software qualities.

It is worth spending significant time on this document because it is the source for all future steps in the software life cycle, and changes are cheaper now than later.

4.2 Users of a requirements document

Many different stakeholders read this document: customers, developers, managers, testers, documenters, maintainers, system engineers, software architects, marketing personnel, and others.

4.3 Document structure

4.4 Connection to INF 43 principles

The requirements document itself is structured to reflect the fundamental SE principles: rigor, separation of concerns (modularity, abstraction), anticipation of change, generality, and incrementality. Not every project requires every section.

5. Specification Methods and Verification

5.1 Specification methods

5.2 Verification checklist

When verifying a requirements specification, ask:

• Is it complete?
• Is each requirement understandable?
• Is each requirement unambiguous?
• Are any requirements in conflict?
• Can each requirement be verified?
• Are all terms and concepts defined?
• Is the specification unbiased?

6. Ziv's Law

Ziv's Law states that software development is unpredictable and documented artifacts such as requirements will never be fully understood. Uncertainty is inherent and inevitable in software engineering processes and products.

This does not mean requirements are useless — it means we should expect imperfection and plan for change, which connects directly to the principle of anticipation of change.

7. Wrap-Up and Memory Framework

Week 2 knowledge structure
|
+-- Software failures
|   +-- root causes: complexity, conformity, progress measurement, legacy, hubris
|   +-- Hubble Psychology: over-optimism (Amazon, CA DMV $134M waste)
|   +-- case studies: Minnesota (undefined roles), TSB (migration disaster), Shopa (no product direction)
|   +-- stats: 29% success rate, 34% late, cost overruns double budget
|   +-- top failure causes → mostly requirements issues + lack of rigor
|
+-- Why requirements matter
|   +-- definition: what (not how); needs (not wants)
|   +-- "faster horse" analogy: dig for real needs behind stated wants
|   +-- 70%+ of rework costs from requirements defects
|   +-- cost of change grows exponentially over project phases
|   +-- maintenance = 67% of total life cycle cost
|
+-- Requirements engineering
|   +-- analysis: discover/observe/gather customer needs
|   +-- specification: describe/document customer needs
|   +-- analysis techniques: interview, observe, use cases, prototypes, data-driven
|   +-- good requirements: complete, unambiguous, non-conflicting, verifiable
|
+-- Requirements specification document
|   +-- purpose: fundamental reference between customer and producer
|   +-- sections: introduction, executive summary, application context,
|   |   environmental requirements, functional requirements, software qualities,
|   |   other requirements, time schedule, risks, assumptions, future changes,
|   |   glossary, references, UI, acceptance test plan
|   +-- structured according to INF 43 principles
|
+-- Specification methods
|   +-- natural language, diagrams, formal language, models
|   +-- verification: complete, unambiguous, non-conflicting, verifiable, defined, unbiased
|
+-- Ziv's Law
    +-- uncertainty is inherent and inevitable in SE
    +-- requirements will never be fully understood
    +-- plan for change

One-sentence summary

Requirements engineering — the systematic analysis and specification of what software should do — is the most critical phase of development because requirements defects are the top cause of project failure, the most expensive to fix later, and the document structure itself must embody the same SE principles (rigor, separation of concerns, anticipation of change) that govern the entire discipline.