A Conceptual Model of Requirement Types · Business Analysis Notes

Key ideas#

A working scheme, not a theory#

Academic classifications, such as Wiegers and Beatty’s levels, explain how kinds of requirements relate. Pererva and Ivanova offer types and attributes from project practice that you can copy into a tracker as they are, and that also define what traces to what.

The sixteen types, grouped#

The grouping below is for readability; the codes are the authors’.

Group	Code	What it holds
Evidence	ANSW	Answers and information collected from stakeholders, kept in their original form so you can show how each was used and justify decisions
Evidence	STKR	Stakeholder requests: a consistent, complete list, traced to BR and BRULE as a check
Business	BR	Business requirements: why the organization needs the system
Business	BRULE	Business rules that protect the structure of the business or control and influence its operations
Business	BVISION	The product vision from the business side: stakeholder expectations, standardization
Constraints	ASSUM	External constraints and assumptions coming from stakeholders, business requirements or business rules
Constraints	TECH	Internal constraints that follow from the chosen technologies and platforms, set by the architect
Constraints	SERT	Requirements of certification bodies and regulators
Constraints	STSTD	Standards (for example, national GOST standards) identified during business analysis; architectural standards are handled separately
Constraints	CHAR	Useful characteristics of similar or legacy systems that the new system should keep
Solution	TVISION	The system concept: how BVISION will be realized on the chosen technologies
Solution	UREQ	User requirements, stated directly by future users
Solution	UC	Use cases: sets of actions that give an actor a meaningful result
Solution	FR	Functional requirements: testable statements of what the system can do
Solution	NFR	Non-functional requirements: testable statements, often with numeric targets
Shared	TERM	Glossary terms and concepts

How the types flow#

The authors describe a chain: BVISION and ANSW lead to UREQ, UREQ to UC, and UC to FR. TVISION takes the FRs into account and shapes, or limits, the NFRs. STKR items trace to BR and BRULE, which shows whether every stakeholder request is backed by a business reason.

Non-functional sub-types#

NFRs get their own sub-scheme of seventeen sub-types: user interface (GUI), interaction with external systems (ICE, “interface control element”), documentation (DOC), data (DATA), certification (CERT), plus environment, hardware, software, deployment, performance, reliability, scalability, security, ergonomics, licensing, compatibility and support.

Four attributes on every item#

Priority — Hot, High, Medium (default) or Low. Hot is a management override: the item goes ahead of everything, even High. Priority is usually agreed with the customer.
Complexity of implementation, excluding testing effort — Challenge (architecturally significant with serious technology risk; set by the project manager after a change control board decision), Solution (architecturally significant and central to the solution; set by the project manager with the architect), Normal (default), or Easy (quick-change level; may be left out of traceability checks).
Cost — total estimated effort in person-hours, at least one hour, set by the project manager and recalculated during impact analysis of a change.
Assigned To — who will implement the item, set by the project manager.

How to apply it#

Start small. Configure STKR, BR, BRULE, UC (or UREQ), FR, NFR and TERM first. Add the constraint types once stakeholders and architects start raising them.
Define link rules. Allow only the links in the chain above, for example FR to UC and STKR to BR.
Add the four attributes with defaults: Medium priority, Normal complexity.
Write down who may set what. For example, only the project manager may set Cost and Assigned To, and Hot needs a named approver.
Build three standing reports: STKR items with no BR or BRULE link (requests without a business reason), FRs with no UC (orphans), and the list of Hot items (should stay short).
Recalculate Cost whenever a change request touches an item.

Template#

Template

| ID | Type | Statement | Traces to | Priority | Complexity | Cost (h) | Assigned to |
|----|------|-----------|-----------|----------|------------|----------|-------------|
|    |      |           |           | Medium   | Normal     |          |             |

Example#

Items from The Workshop, a fictional chain of bike-repair workshops:

ID	Type	Statement	Traces to
`ANSW-012`	ANSW	Front-desk lead: “Most of our calls are customers asking whether their bike is ready.”	—
`STKR-004`	STKR	Customers want to know repair status without calling.	`BR-002`
`BR-002`	BR	Reduce status calls to the front desks.	—
`BRULE-007`	BRULE	A job is ready only after a mechanic signs off the final safety check.	—
`UC-05`	UC	Check repair status.	`STKR-004`
`FR-031`	FR	The system shall show the current status of each of the customer’s repair jobs.	UC-05, BRULE-007
`TECH-02`	TECH	The chosen platform supports email and SMS notifications only.	—

FR-031 gets Priority High, Complexity Normal, Cost 16 h. A request to add app push notifications later collides with TECH-02, so it is visible at once as a constraint question for the architect, not a simple feature.

Pitfalls#

“Hot” for everything. If more than a handful of items are Hot, the label means nothing. Require an approver.
Stale cost. Cost that is not updated after changes makes impact analysis useless.
Types without link rules. Types are only labels until you decide what must trace to what and report on the gaps.

Sources and further reading#

A. Pererva, V. Ivanova. The Analyst’s Path: A Practical Guide (in Russian), section 4.2.4.
K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013 — for the academic classification this scheme complements.