Chapter 2: Inception and Requirements

Source files used: Lecture 2 - Inception and Requirements; textbook (applying-uml-and-patterns.pdf) Chapter 7 as support.

A focused guide to the inception phase and to requirements in the UP for the COMP302 Midterm 1. It covers what inception is (and is not), its artifacts, the FURPS+ model, and which artifact records which kind of requirement. Guide 1 introduced the phases; this guide zooms into the first one.

Roadmap: 1 OOA/D and UP → 2 Inception and Requirements → 3 Use Cases → 4 Domain Models → 5 SSDs and Contracts → 6 Logical Architecture → 7 Interaction Diagrams

Inception

What Is Inception?

Inception is the short initial step of a UP project. It explores questions like:

What is the vision and business case for this project?
Is it feasible?
Buy and/or build?
Rough estimate of cost: is it $10K-100K or in the millions?
Should we proceed or stop?

Its purpose is to collect just enough information to establish a common vision and decide whether moving forward is feasible.

Important: For the class project, Ayral assumes inception has already been carried out: earlier work showed that the project is feasible, and preliminary requirements were explored.

How Much Requirements Work Happens in Inception?

Only preliminary requirements and use case work: perhaps 10% of the requirements are analyzed in detail. Most requirements analysis happens during elaboration, and most UML diagramming happens there too.

Exam Trap #1: Treating inception as the time to write all requirements or to produce believable estimates and plans.

WRONG:   "Inception ends when all requirements are signed off
          and the plan is fixed."
CORRECT: "Inception ends with a continue/stop decision and a common vision;
          about 10% of the requirements are detailed."

This is the waterfall thinking warned about in Guide 1: in the UP, believable estimates and plans come during elaboration.

Inception Artifacts

These artifacts are started in inception, only partially completed, and refined in later iterations:

Artifact	Comment
Vision and Business Case	high-level goals and constraints, the business case, an executive summary
Use-Case Model	functional requirements; most use case names identified, perhaps 10% analyzed in detail
Supplementary Specification	other requirements, mostly non-functional; the key ones that will impact the architecture
Glossary	key domain terminology and the data dictionary
Risk List & Risk Management Plan	business, technical, resource, and schedule risks, and ideas for mitigation
Prototypes and proof-of-concepts	clarify the vision and validate technical ideas
Iteration Plan	what to do in the first elaboration iteration
Phase Plan & Software Development Plan	low-precision guess for elaboration duration and effort; tools, people, education, resources
Development Case	the customized UP steps and artifacts for this project (the UP is always customized)

Exam Trap #2: Listing the Domain Model as an inception artifact. It is not in the inception table, and the artifact timing table in Lecture 3 starts the Domain Model in elaboration.

Understanding Requirements

What Is a Requirement?

Requirements are the capabilities that the system must support and the conditions to which it must conform.

The UP best practice “manage requirements” does not mean fully defining and freezing the requirements in the first phase. Following RUP, it means “a systematic approach to finding, documenting, organizing, and tracking the changing requirements of a system”, done iteratively.

Changing: the UP embraces change in requirements as a fundamental driver on projects.
Finding: requirements are discovered with techniques such as use case writing and requirements workshops.

Why Requirements Matter

The lecture’s pie chart of factors on challenged software projects puts three requirements problems near the top: poor user input (13%), incomplete requirements (12%), and changing requirements (12%). Poor technical skills (7%) and poor staffing (6%) rank lower. Requirements issues are 37% of the chart.

FURPS+

The UP categorizes requirements with the FURPS+ model:

Letter	Category	Covers
F	Functional	features, capabilities, security
U	Usability	human factors, help, documentation
R	Reliability	frequency of failure, recoverability, predictability
P	Performance	response times, throughput, accuracy, availability, resource usage
S	Supportability	adaptability, maintainability, internationalization, configurability

The + stands for ancillary and sub-factors:

Implementation: resource limitations, languages and tools, hardware,
Interface: constraints imposed by interfacing with external systems,
Operations: system management in its operational setting,
Packaging,
Legal: licensing and so forth.

Use FURPS+ (or any categorization scheme) as a checklist for requirements coverage, so that no important facet of the system is forgotten.

Exam Trap #3: Guessing the letters.

WRONG:   S = Security, P = Portability
CORRECT: S = Supportability, P = Performance   (security is part of F)

Functional vs Non-Functional

In common usage, requirements are functional (behavioral) or non-functional (everything else). Usability, reliability, performance, and supportability are together called the quality attributes (quality requirements, or the “-ilities”).

Where Requirements Are Recorded

The Requirements Artifacts

Artifact	What it holds
Use-Case Model	a set of typical scenarios of using the system; the functional requirements
Supplementary Specification	all non-functional requirements, plus features not captured in use cases
Glossary	key terms, plus the data dictionary (validation rules, acceptable values)
Vision	the big ideas of the project and the business case; summarizes the high-level requirements
Business Rules	rules of the domain you must operate in, such as tax laws, aviation laws, laws of physics

Two more placement rules from the lecture:

Functional requirements are also summarized in the system features list of the Vision.
Non-functional requirements can be recorded in the use cases they relate to, or in the Supplementary Specification.

Prototypes are a mechanism to clarify what is wanted or possible.

Supplementary Specification

The NextGen POS example calls it “the repository of all NextGen POS requirements not captured in the use cases.” Sample entries from the lecture:

Logging and Error Handling: log all errors to persistent storage (functionality common across many use cases),
Pluggable Rules: customize system functionality with arbitrary rules at various scenario points,
Security: all usage requires user authentication,
Usability (Human Factors): text easily visible from 1 meter; avoid colors associated with common forms of color blindness; convey signals and warnings with sound, because the cashier is often looking at the customer, not the screen.

The textbook adds reports, hardware and software constraints, development constraints, internationalization, documentation and help, licensing and legal concerns, packaging, standards, physical environment concerns, operational concerns, and domain rules.

Glossary

In its simplest form, the Glossary is a list of noteworthy terms and their definitions (textbook). In the UP it also plays the role of the data dictionary. A lecture example:

Term	Definition	Format	Validation Rules	Aliases
UPC	numeric code that identifies a product, usually shown as a bar code	12-digit code of several subparts	digit 12 is a check digit	Universal Product Code

Its job is to remove ambiguity: different stakeholders often use the same term in slightly different ways.

Vision

The Vision summarizes the big ideas and the business case. The NextGen Vision has an introduction (“a next generation fault-tolerant point-of-sale (POS) application”), a business opportunity, a problem statement, a product position statement, alternatives and competition, and stakeholder descriptions.

Exam Trap #4: Putting a requirement in the wrong artifact.

WRONG:   "Credit authorization within 30 s, 90% of the time" goes in the Glossary
CORRECT: Supplementary Specification (or the use case's Special Requirements)

WRONG:   "UPC is 12 digits; digit 12 is a check digit" goes in the Vision
CORRECT: Glossary (data dictionary)

Evolutionary vs Waterfall Requirements

Start Before the Requirements Are Done

In the UP and other evolutionary methods (Scrum, XP, …), production-quality programming and testing start long before most requirements are analyzed: when only 10% or 20% of the most significant, risky, high-business-value requirements are specified.

Why Not Specify Everything First?

When waterfall requirements analysis is attempted, most of the features specified early turn out to be of little use. The lecture’s feature-usage chart: Never 45%, Rarely 19%, Sometimes 16%, Often 13%, Always 7%.

Key Insight: 64% of the features in that chart are never or rarely used, so specifying everything up front wastes most of the effort.

Exam-Style Practice Problems

Problem 1: Inception Artifacts

Question: The Fall 2024 Midterm 1 study sheet asks: what are some of the inception phase artifacts?

Answer:

Vision and Business Case, Use-Case Model, Supplementary Specification, Glossary,
Risk List & Risk Management Plan, Prototypes and proof-of-concepts,
Iteration Plan, Phase Plan & Software Development Plan, Development Case

Problem 2: Requirements Artifacts

Question: The same sheet asks: what are some of the requirements discipline artifacts?

Answer:

Use-Case Model, Supplementary Specification, Glossary, Vision, Business Rules

Problem 3: Classify with FURPS+

Question: Classify each NextGen requirement.

Credit authorization response within 30 seconds, 90% of the time.
Text must be visible from 1 meter.
Robust recovery when remote services such as the inventory system fail.
Language internationalization of the displayed text.
Must run on Linux.

Answer:

1. Performance     (response time)
2. Usability       (human factors)
3. Reliability     (recoverability)
4. Supportability  (internationalization)
5. + Implementation (a constraint on platform and tools)

Problem 4: Define the Terms

Question: Explain “supplementary specification”, “functional requirement”, “FURPS”, and “glossary” (all on the study sheet’s term list).

Answer:

Supplementary specification: the artifact that captures requirements not in the use cases, mostly non-functional (URPS+), such as “all usage requires user authentication”.
Functional requirement: a behavior or capability the system must provide (features, capabilities, security), recorded mainly in use cases.
FURPS: Functional, Usability, Reliability, Performance, Supportability; the + adds implementation, interface, operations, packaging, and legal.
Glossary: noteworthy terms with definitions, also used as the data dictionary (format, validation rules, aliases).

Common Exam Traps

1. Inception Is a Feasibility Step

WRONG:   inception = the requirements phase
CORRECT: inception = vision, business case, scope, vague estimates, continue/stop

Why: Most requirements analysis happens during elaboration.

2. About 10%, Not 100%

WRONG:   all use cases written in detail during inception
CORRECT: most use case names identified; perhaps 10% analyzed in detail

Why: Detailing everything up front is waterfall thinking.

3. The Domain Model Is Not an Inception Artifact

WRONG:   inception artifacts include the Domain Model
CORRECT: Vision, Use-Case Model, Supp. Spec., Glossary, Risk List, Prototypes,
         Iteration Plan, Phase Plan & SDP, Development Case

Why: The Domain Model belongs to Business Modeling and starts in elaboration.

4. FURPS Letters

WRONG:   S = Security
CORRECT: S = Supportability; security is listed under Functional

Why: The slide defines Functional as “features, capabilities, security”.

5. Wrong Artifact for a Requirement

WRONG:   non-functional requirements written into the Glossary or the Vision
CORRECT: Supplementary Specification, or the related use case

Why: The Glossary is for terms and data rules; the Vision only summarizes.

6. The Glossary Is Also the Data Dictionary

WRONG:   Glossary = definitions only
CORRECT: Glossary = terms + data dictionary (format, validation rules, aliases)

Why: The lecture’s UP artifact list shows “key terms” and “data dictionary” under the Glossary.

7. Managing Requirements Is Not Freezing Them

WRONG:   "manage requirements" = stabilize them in the first phase
CORRECT: find, document, organize, and track CHANGING requirements, iteratively

Why: The UP embraces requirement change as a fundamental driver.

8. Most UML Drawing Is Not in Inception

WRONG:   draw the detailed UML models during inception
CORRECT: most UML diagramming occurs in the elaboration phase

Why: Inception collects just enough information for a decision.

Final Tips for the Midterm

Memorize the inception artifact table: at least six of the nine names, with a few words each.
Know FURPS+ cold: five letters plus the five ”+” categories, and that security sits under F.
Match requirement to artifact: functional to the Use-Case Model, non-functional to the Supplementary Specification, terms and data rules to the Glossary.
Quote the RUP phrase: finding, documenting, organizing, and tracking the changing requirements.
Use the 10% number: for how much detail inception produces, and 10-20% for when production programming starts.

Good luck on the midterm! You’ve got this.