Requirements specification is the process of documenting requirements in a well-organized way suitable for comprehension by their intended audiences. The quality of how requirements are written directly impacts project success.
🧠 Memory Trick: Two Goals of Writing Requirements
Think 'SAME MATCH' - Everyone reads it the SAME way, and it MATCHES what the author meant!
Think: "Can Customers Find New Products Using Verification"
1️⃣ Complete
Contains all necessary information for the reader to understand it.
Use TBD (To Be Determined) to flag gaps
Resolve all TBDs before implementation
2️⃣ Correct
Accurately describes a capability that meets stakeholder needs.
No conflicts with other requirements
Verify against source of requirement
3️⃣ Feasible
Must be possible to implement within constraints.
Consider technical limitations
Consider time, budget, and staff
Use prototypes to evaluate feasibility
4️⃣ Necessary
Provides business value or meets a real need.
Differentiates product in marketplace
Required for compliance
If asked "why?" - there should be an answer
5️⃣ Prioritized
Ranked according to importance.
Should be collaborative activity
Helps manage limited resources
Essential for handling changes
6️⃣ Unambiguous
Has only one interpretation.
All readers understand it the same way
Use peer reviews to verify clarity
7️⃣ Verifiable
Testers can determine if it was properly implemented.
Not a matter of opinion
Should be objective analysis
📋 PAST EXAM QUESTION (Quiz 2)
Q: Which of the following property does NOT correspond to a good Software Requirements Specification (SRS)?
a) Verifiable
b) Ambiguous ✓ (CORRECT ANSWER)
c) Complete
d) Traceable
📚 Characteristics of Requirements Collections
Complete
All necessary requirements are present. Any specification containing TBDs is incomplete.
Consistent
Requirements don't conflict with each other or with higher-level requirements.
💡 Tip
Record the originator of each requirement to go back to in case of conflict
Modifiable
To make your SRS modifiable:
Maintain a history of changes
Learn connections between requirements
Use unique labels for each requirement
Avoid redundancy - don't repeat requirements
Cross-reference related items
Traceable
Can be linked backward to its origin and forward to design, code, and tests.
Unique identifiers are essential
Avoid combining multiple requirements in one statement
✍️ Guidelines for Writing Requirements
1. System or User Perspective
Formula: [optional precondition] [optional trigger event] the system shall [expected system response]
📘 Example
✓ "If the requested chemical is found in the chemical stockroom, the system shall display a list of all containers of the chemical that are currently in the stockroom."
💡 Writing Style Tips
Put the punch line (functionality) FIRST
Use complete sentences with proper grammar
Keep sentences SHORT and DIRECT
Avoid jargon - define specialized terms in glossary
Be consistent with keywords (use 'shall' consistently)
Use ACTIVE VOICE not passive
2. Active Voice vs Passive Voice
❌ PASSIVE (Ambiguous)
"Upon product upgrade shipment, the serial number will be updated on the contract line."
❓ Who updates it? System or user?
✓ ACTIVE (Clear)
"When Fulfillment confirms that they shipped a product upgrade, the system shall update the customer's contract with the new product serial number."
3. Individual Requirements - Avoid Combining
⚠️ Warning Signs
"and" - might join two requirements
"or" - creates ambiguity
"and/or" - avoid at all costs!
"unless" - indicates exception (split into two)
"except" - multiple conditions
"but" - contradictory conditions
📘 Example: The "unless" Problem
❌ "The Buyer's credit card on file shall be charged for payment, unless the credit card has expired."
Problem: What happens when card is expired? Not specified!
✓ Better: Split into TWO requirements:
"If the Buyer's credit card on file is active, the system shall charge the payment to that card."
"If the Buyer's credit card on file has expired, the system shall allow the Buyer to either update the current credit card information or enter a new credit card for payment."
4. Avoiding Ambiguity - Main Sources
Source 1: Fuzzy Words
⚠️ Avoid These Words
reasonably, appropriately, generally, approximately
usually, systematically, quickly
user-friendly, flexible, robust
Source 2: Boundary Values
📘 Example of Unclear Boundaries
❌ "Vacation requests of up to 5 days do not require approval. Vacation requests of 5 to 10 days require supervisor approval."
Problem: What happens at EXACTLY 5 days? EXACTLY 10 days?
✓ Better: Use "through", "inclusive", "exclusive"
"Vacation requests of 5 or fewer days do not require approval. Vacation requests of longer than 5 days through 10 days require supervisor approval."
Source 3: Negative Requirements
❌ NEGATIVE
"Prevent the user from activating the contract if the contract is not in balance."
Double negative - confusing!
✓ POSITIVE
"The system shall allow the user to activate the contract only if the contract is in balance."
Clear and direct!
🔄 Sample Requirements: Before and After
Example 1: The Background Task Manager
❌ BEFORE (Multiple Problems)
"The Background Task Manager shall provide status messages at regular intervals not less than every 60 seconds."
Problems:
What are the status messages?
How are they provided?
Timing is unclear
NOT VERIFIABLE!
✓ AFTER (Clear & Complete)
"The BTM shall display status messages in a designated area of the user interface."
"The BTM shall update the messages every 60 ± 5 seconds."
"The messages shall remain visible continuously during background processing."
"The BTM shall display the percent completed."
"The BTM shall display a 'Done' message when completed."
"The BTM shall display a message if the task has stalled."
🏷️ Labeling Requirements
Method 1: Sequence Number
UC-9, FR-26, NFR-15
✓ Pros: Easy to retain unique ID if requirements are moved
❌ Cons: No logical grouping, labels tell you nothing about intent
Method 2: Hierarchical Numbering
3.2.4.3 is a child requirement of 3.2.4
⚠️ TRAP with Hierarchical Numbering
Word processors don't generate persistent labels. Insert, move, merge, or delete and labels WILL CHANGE!
Mitigation: Number major sections hierarchically, then use text code + sequence (e.g., Section 3.5: ED-1, ED-2)
Method 3: Hierarchical Textual Tags
📘 Example
Tag:Print.ConfirmCopies
(Part of print function, relates to number of copies)