Requirements Best Practices
Write better requirements using the INCOSE 42 rules for requirements engineering excellence.
Overview
Good requirements are the foundation of successful projects. Poorly written requirements lead to:
- Misunderstandings between teams
- Costly rework during development
- Failed tests and missed deadlines
- Safety and compliance issues
NirmIQ helps you apply industry best practices through:
- AI Import with Methodology - AI uses your best practices to structure requirements
- Smart Import - Pattern detection finds "shall" statements and requirement IDs
- Quality Indicators - Visual cues for requirement quality (coming soon)
The 42 INCOSE Rules
The International Council on Systems Engineering (INCOSE) defines 42 rules for writing good requirements, organized into 6 categories:
Category 1: Clarity (Rules 1-8)
Rule 1: Use "Shall" for Requirements
Mandatory requirements MUST use "shall":
| Keyword | Meaning | Use For |
|---|---|---|
| shall | Mandatory requirement | Core requirements |
| will | Statement of fact | Declarations, not requirements |
| should | Goal or preference | Non-mandatory guidelines |
| may | Optional capability | Nice-to-have features |
Examples:
- Good: "The system shall respond within 200ms"
- Bad: "The system should respond quickly"
Rule 2: One Requirement Per Statement
Each statement should address only ONE capability. Split compound requirements.
Bad:
REQ-001: The system shall log errors and send alerts and notify administrators.
Good:
REQ-001: The system shall log errors to persistent storage.
REQ-002: The system shall send alerts for critical errors.
REQ-003: The system shall notify administrators via email.
Rule 3: Active Voice
Use active voice, not passive.
| Passive (Avoid) | Active (Preferred) |
|---|---|
| "Errors shall be logged by the system" | "The system shall log errors" |
| "Data shall be encrypted" | "The system shall encrypt data" |
Rule 4: Consistent Terminology
Use the same term for the same concept throughout your document.
- Define terms in a glossary
- Don't mix "system", "application", "software" for the same thing
- Establish naming conventions early
Rule 5: Avoid Vague Terms
Eliminate these words:
- adequate, appropriate, reasonable
- user-friendly, efficient, flexible
- sufficient, effective, fast
Replace with measurable criteria:
| Vague | Specific |
|---|---|
| "fast response" | "response within 200ms" |
| "user-friendly" | "operable by users with 1 hour training" |
| "efficient" | "completes in under 5 seconds with <10% CPU" |
Rule 6: Avoid Escape Clauses
Eliminate these phrases:
- "if possible"
- "as appropriate"
- "as required"
- "to the extent practical"
- "when necessary"
Requirements must be unconditional or have specific conditions.
Rule 7: No Negative Requirements (When Possible)
Bad: "The system shall not allow unauthorized access" Good: "The system shall restrict access to authorized users only"
Rule 8: Use Correct Grammar and Spelling
- Proofread all requirements
- Use consistent capitalization
- Use proper punctuation
Category 2: Completeness (Rules 9-15)
Rule 9: Specify Units of Measure
All quantitative values shall include units.
Bad: "Response time shall be less than 5" Good: "Response time shall be less than 5 seconds"
Rule 10: Define Acronyms
- Spell out on first use
- Include in glossary
- Example: "Failure Mode and Effects Analysis (FMEA)"
Rule 11: Include Tolerances
Specify acceptable ranges.
Bad: "Temperature shall be 25 degrees" Good: "Temperature shall be 25 +/- 2 degrees Celsius"
Rule 12: Specify Conditions
State when/where the requirement applies.
Example: "Under normal operating conditions (0-40C, sea level), the system shall..."
Rule 13: Specify Frequency/Duration
Bad: "The system shall back up data" Good: "The system shall back up data every 24 hours, retaining backups for 30 days"
Rule 14: Include Boundary Conditions
Document what happens at limits:
- Startup behavior
- Shutdown procedures
- Error conditions
- Edge cases
Example: "Upon startup, the system shall complete initialization within 30 seconds"
Rule 15: Specify Interfaces Completely
Include:
- Protocol
- Data format
- Timing constraints
- Error handling
Example: "The system shall communicate via REST API using JSON format with 5-second timeout"
Category 3: Correctness (Rules 16-21)
Rule 16: Requirements Must Be Achievable
- Technically feasible with current technology
- Within budget and schedule constraints
- Flag unrealistic requirements for review
Rule 17: Requirements Must Be Verifiable
Must be testable by one of:
- Inspection - Visual examination
- Analysis - Mathematical/logical proof
- Demonstration - Functional exercise
- Test - Measurement against criteria
Bad: "The system shall be reliable" Good: "The system shall achieve 99.9% uptime measured monthly"
Rule 18: No Implementation Details
Requirements state WHAT, not HOW.
Bad: "The system shall use MySQL database" Good: "The system shall persist data in a relational database"
Exception: Specific technology may be a constraint requirement.
Rule 19: Requirements Must Not Conflict
- Check for contradictions between requirements
- Resolve conflicts with stakeholders
- Document conflict resolution decisions
Rule 20: Each Requirement Must Be Necessary
- Every requirement must trace to a need
- Remove "gold plating"
- Ask: "What happens if we don't implement this?"
Rule 21: Requirements Must Be Consistent with Standards
- Reference applicable standards
- Ensure compliance with regulations
Examples:
- "The system shall comply with IEC 62304 Class B"
- "The system shall meet ISO 26262 ASIL-B requirements"
Category 4: Traceability (Rules 22-27)
Rule 22: Unique Identifiers
Every requirement must have a unique ID following your hierarchy scheme.
Examples: SYS-001, SUB-001, CMP-001
Rule 23: Trace to Source
Link to:
- Stakeholder need
- Regulation
- Higher-level requirement
Document rationale for derived requirements.
Rule 24: Trace to Verification
Link each requirement to:
- Test cases
- Verification method (Inspection, Analysis, Demonstration, Test)
Rule 25: Maintain Parent-Child Relationships
- System requirements decompose to subsystem requirements
- Track allocation to components
- Build traceability matrix
Rule 26: Version Control
- Track requirement changes
- Maintain change history
- Include baseline information
Rule 27: Track Requirement Status
Standard statuses:
- Draft - Under development
- Approved - Reviewed and accepted
- Implemented - Code complete
- Verified - Testing passed
- Deleted - No longer applicable
Category 5: Specificity (Rules 28-34)
Rule 28: Be Specific About Performance
Quantify: speed, accuracy, capacity, throughput.
Bad: "The system shall respond quickly" Good: "The system shall respond within 200ms for 95% of requests"
Rule 29: Specify Operating Environment
Document:
- Temperature range
- Humidity
- Altitude
- EMI conditions
Example: "The system shall operate at temperatures from -20C to +55C"
Rule 30: Specify User Characteristics
Document:
- Training level required
- Physical capabilities assumed
Example: "The system shall be operable by personnel with basic computer skills"
Rule 31: Specify Data Requirements
Document:
- Retention period
- Accuracy requirements
- Format specifications
Example: "The system shall retain audit logs for 7 years"
Rule 32: Specify Reliability Requirements
Include:
- MTBF (Mean Time Between Failures)
- MTTR (Mean Time To Repair)
- Availability percentage
Example: "The system shall achieve MTBF of 10,000 hours"
Rule 33: Specify Safety Requirements
Include:
- Hazard mitigation
- Fail-safe behavior
- Reference safety standards
Example: "Upon critical failure, the system shall enter safe state within 100ms"
Rule 34: Specify Security Requirements
Include:
- Authentication method
- Authorization levels
- Encryption requirements
Example: "The system shall authenticate users using multi-factor authentication"
Category 6: Structure (Rules 35-42)
Rule 35: Use Consistent Requirement Format
Template:
[ID] The [system/component] shall [action] [object] [condition] [constraint]
Example:
REQ-001: The system shall encrypt all data at rest using AES-256.
Rule 36: Group Related Requirements
Organize by:
- Function
- Component
- Lifecycle phase
Maintain logical flow within groups.
Rule 37: Prioritize Requirements
Use consistent scheme:
- Critical, High, Medium, Low
- Or MoSCoW: Must, Should, Could, Won't
Include priority in requirement metadata.
Rule 38: Separate Functional and Non-Functional
Group separately:
- Functional - What the system does
- Non-Functional - Quality attributes (performance, safety, security)
Rule 39: Use Requirements Templates
Standardize format across project with mandatory fields:
- ID
- Text
- Type
- Priority
- Status
- Verification Method
Rule 40: Include Rationale
Document WHY the requirement exists.
Example: "Rationale: Required for FDA 21 CFR Part 11 compliance"
Rule 41: Define Hierarchy Levels
Standard hierarchy:
- Level 1: Stakeholder/User Needs
- Level 2: System Requirements
- Level 3: Subsystem Requirements
- Level 4: Component Requirements
- Level 5: Design Requirements
Rule 42: Review and Validate
- Peer review all requirements
- Validate with stakeholders
- Use checklists to verify quality
Requirement Types
When writing or importing requirements, classify them appropriately:
| Type | Description | Keywords |
|---|---|---|
| Functional | What the system does | perform, execute, process, calculate, display |
| Performance | How well it performs | speed, latency, throughput, accuracy, capacity |
| Interface | How it connects | API, protocol, format, communicate, integrate |
| Safety | Hazard prevention | safe, hazard, fail-safe, emergency, protect |
| Security | Protection from threats | authenticate, authorize, encrypt, access control |
| Reliability | Dependability | MTBF, availability, fault tolerance, redundancy |
| Usability | User experience | intuitive, accessible (quantify!) |
| Maintainability | Ease of maintenance | modular, documented, configurable |
| Constraint | Limitations | maximum, minimum, within, not exceed |
| Verification | Testing requirements | test, verify, validate, demonstrate |
Using Best Practices in NirmIQ
With AI Import
Upload the INCOSE methodology document with your requirements document:
- Go to Import Requirements
- Select AI-Powered Import
- Upload your requirements Word document
- Upload the methodology document (optional but recommended)
- AI will apply the 42 rules when structuring requirements
Download INCOSE Methodology Document
With Smart Import
Smart Import automatically detects:
- "Shall", "must", "will" keywords
- Requirement ID patterns (REQ-001, SYS-001)
- Document structure (headings, bullets)
No methodology document needed - patterns are built-in.
Quality Checklist
Before finalizing any requirement, verify:
- Uses "shall" for mandatory requirements
- Contains only ONE requirement per statement
- Is written in active voice
- Uses consistent terminology
- Has no vague or ambiguous terms
- Has no escape clauses
- Includes units of measure where applicable
- Is achievable and verifiable
- Does not specify implementation (unless constraint)
- Has unique identifier
- Is traceable to source
- Has assigned type and priority
- Is grammatically correct
Related Topics
- Smart Import (No AI) - Pattern-based Word document import
- AI Import - AI-powered document processing
- Creating Requirements - Manual requirement creation
- Hierarchy Management - Organizing requirements
References
- INCOSE Guide for Writing Requirements (2017)
- ISO/IEC/IEEE 29148:2018 - Systems and Software Engineering
- IEEE 830 - Recommended Practice for Software Requirements Specifications