Topic · 40 notes
Requirements Engineering
Practical requirements engineering beyond the BABOK Guide: requirement levels and types, writing quality requirements, key documents and templates, traceability and change control, and what changes for agile, COTS, outsourced, BI and embedded projects.
Levels and Types of Requirements
Wiegers and Beatty's three levels of requirements (business, user, functional), where NFRs and business rules fit, and what stays out of the SRS.
non functional requirementsClassifying Requirements and Non-Functional Categories
Wiegers' map of requirement types, four practical categories of non-functional requirements, and the quality characteristics of a requirement and of a set.
requirements managementA Conceptual Model of Requirement Types
A practical scheme for tagging requirements in a tracker: sixteen types with short codes, NFR sub-types, and four attributes on every item.
non functional requirementsSoftware Quality Attributes
Sixteen quality attributes after Wiegers and Beatty, a five-step way to elicit them, Planguage for writing testable targets, and how attributes trade off.
requirements qualityHow to Write Good Requirements
Sentence templates, style rules, weak words to avoid, and quick tests for hidden gaps, with before/after rewrites of weak requirements.
ambiguityAmbiguity and the Right Level of Detail
How much detail a requirement needs, and three simple heuristics (memorization, keywords, emphasis) for finding hidden ambiguity before it costs you.
elicitationFinding Missing Requirements
Signs that elicitation is done for now, assumed vs. implied requirements, and eight systematic checks (including CRUD and boundary checks) for gaps.
business rulesA Taxonomy of Business Rules
Facts, constraints, action enablers, inferences and computations: how to classify, write, catalog and link business rules without copying them into specs.
stakeholdersUser Classes and Product Champions
Group users by the work they do, decide which classes matter most, and give each key class a product champion who speaks for it (Wiegers and Beatty).
stakeholdersThe Customer's Rights and Responsibilities
Wiegers and Beatty's customer bill of rights and responsibilities, decision rules, and a sign-off that records agreement without freezing requirements.
problem analysisProblem Analysis and Project Scope
Leffingwell and Widrig's five steps of problem analysis, the problem statement, three elicitation syndromes, and how to cut scope to what can be built.
stakeholdersThe Product Champion Role
Leffingwell and Widrig's product champion: the person who owns the product vision, drives requirements to closure, and says no to feature creep.
elicitationRole Playing
Do the user's job yourself to understand it, or, when you cannot, use scripted walkthroughs and CRC cards (Leffingwell and Widrig).
elicitationStoryboarding
Show users a cheap, rough story of the future system to get their reaction before anything is built: passive, active and interactive storyboards.
business requirementsThe Vision and Scope Document
How to write a vision and scope document that fixes business objectives, success metrics and project boundaries before anyone writes a feature list.
rupThe RUP Vision Document
What goes into a RUP Vision document, how vision differs from scope, and how to keep the Vision current across releases with a Delta Vision.
elicitationA Stakeholder Requests Template
A structured template for recording what one stakeholder told you, with a built-in recap step and a separate place for your own hypotheses.
srsSoftware Requirements Specification (SRS)
How to structure an SRS, choose between a traditional and a use-case-based layout, label each requirement, and handle open issues and screens.
requirements managementThe Requirements Management Plan
What a requirements management plan should settle: traceability rules, attributes, statuses, baselines and change control, with a copyable outline.
standardsGOST Standards for Automated Systems
What GOST 34.601-90, GOST 34.602-89 and GOST 19.201-78 are, where you meet them, and how a GOST technical specification maps to a Vision and an SRS.
elicitationEliciting and Documenting Requirements (BCS)
The BCS route from terms of reference to a baselined requirements catalogue: OSCAR, tacit knowledge, analysis filters, validation and MoSCoW.
requirements processA Four-Stage Requirements Method (Khimonin)
Khimonin's four stages from product concept to functional specification, with scenario-based elicitation and MoSCoW-driven use case analysis.
specificationOrganizing Requirements for Complex Systems
How to split requirements across documents for systems of subsystems, product families, future releases, and marketing versus product needs.
use casesCockburn's Three Named Goal Levels
Cockburn's summary, user-goal and subfunction levels for use cases, with simple tests for writing each use case at the right height.
use casesBusiness vs. System Use Cases
The difference between business and system use cases, how to move from one to the other, and which workflow notation suits a business analyst.
analysis modelsDialog Maps and Event-Response Tables
Two analysis models from Wiegers and Beatty: dialog maps for user interface navigation, and event-response tables for systems driven by external events.
reportingSpecifying Reports and Dashboards
Questions to ask, a copyable report specification, and a method for dashboard requirements that starts from the decisions users make.
traceabilityRequirements Traceability
How to link requirements to their origins and to design, code and tests, which links are worth keeping, and how to build a traceability matrix.
prioritizationPrioritizing Requirements in Practice
Practical requirement prioritization: why everything ends up 'high', five techniques compared, and a worked value, cost and risk example.
change controlManaging Requirements Changes
A practical change control process: a short policy, a change control board, the request life cycle, impact analysis and change metrics.
reuseReusing Requirements
How to reuse requirements across projects: what is worth reusing, copy vs. reference vs. versioned reuse, common barriers, and what makes reuse stick.
troubleshootingDiagnosing Requirements Problems
Work back from a project symptom to its likely cause in requirements work, then pick a remedy: a guide across ten problem areas.
process improvementImproving Your Requirements Process
How to improve the way a team handles requirements: build real commitment, find root causes, run a four-step improvement cycle, and draw a roadmap.
agileRequirements in Agile Projects
How requirements work changes on agile projects: same information, different timing and depth, one backlog, epics and stories, early quality attributes.
cotsRequirements for Off-the-Shelf (COTS) Solutions
What changes when you buy instead of build: how detailed to be, a scoring method for comparing packages, implementation requirements and process change.
enhancementRequirements for Enhancement and Replacement Projects
Requirements work when a system already exists: gap analysis, protecting performance, software archaeology, staged replacement and transition needs.
outsourcingRequirements for Outsourced Projects
Why outsourced development needs earlier, more precise requirements, and how to run the tender, reviews, questions, changes and acceptance.
process automationRequirements for Business Process Automation
Deriving software requirements from business processes: current and future models, an eight-step sequence, KPIs on process steps, and when not to automate.
business intelligenceRequirements for Business Intelligence Projects
Eliciting requirements for analytics and BI systems: start from the decisions people make, then define information use, data needs and analysis.
embedded systemsRequirements for Embedded and Real-Time Systems
Requirements for products that combine software and hardware: allocating requirements, state and event models, interface specs and timing.
Main sources for this section#
- K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013.
- D. Leffingwell, D. Widrig. Managing Software Requirements: A Unified Approach. Addison-Wesley, 2000.
- A. Cockburn. Writing Effective Use Cases. Addison-Wesley, 2000.
- D. Paul, D. Yeates, J. Cadle (eds.). Business Analysis, 2nd ed. BCS, 2010.