Writing good requirements is essential for ensuring that everyone involved in a project—stakeholders, engineers, testers—has a clear and shared understanding of what needs to be built. Below are some best practices and tips for writing effective, high-quality requirements. We made to examples, the construction of a house and the design of a ship.

1. Use Simple, Clear Language

• Avoid ambiguity: Use clear, precise language to describe the requirements. Avoid terms that can be interpreted in multiple ways.
• Be concise: Write short, to-the-point statements that clearly describe the functionality or constraint. Avoid unnecessary words or details.
• Use active voice: State the requirement directly. For example, instead of “The system should allow…” say “The system shall allow…”.

Example:

• House Example:
  • Ambiguous: “The house should be big.”
  • Clear: “The house shall have a total living area of 3,000 square feet, including 4 bedrooms, 3 bathrooms, a kitchen, and a living room.”
• Ship Example:
  • Ambiguous: “The ship should be fast.”
  • Clear: “The ship shall achieve a cruising speed of 25 knots in calm waters.”

2. Make Requirements Testable

• Every requirement must be verifiable through testing. If you can’t define a test case for a requirement, it’s not specific enough.
• Include acceptance criteria for each requirement, stating the conditions under which the requirement will be considered met.

Example:

• House Example:
  • Non-testable: “The house should be energy-efficient.”
  • Testable: “The house shall achieve an energy efficiency rating of at least 85 on the HERS Index (Home Energy Rating System).”
• Ship Example:
  • Non-testable: “The ship should be seaworthy.”
  • Testable: “The ship shall withstand Category 3 hurricane conditions, withstanding wind speeds up to 130 mph and waves up to 40 feet high.”

Clearly defined testable requirements help verify whether construction or design meets the necessary standards.

3. Ensure Requirements Are Complete

• A good requirement must provide enough detail so that developers and testers can implement and verify it without having to make assumptions.
• If a requirement relies on another functionality or condition, mention it explicitly.

Example:

• House Example:
  • Incomplete: “The house shall have a roof.”
  • Complete: “The house shall have a pitched roof with a 30-degree incline, made from asphalt shingles, designed to withstand 120 mph wind loads.”
• Ship Example:
  • Incomplete: “The ship shall have lifeboats.”
  • Complete: “The ship shall have 8 lifeboats, each capable of carrying 25 people, compliant with SOLAS (Safety of Life at Sea) regulations, and equipped with food, water, and communication devices.”

Providing full details ensures that builders and designers know exactly what is expected and reduces assumptions.

4. Keep Requirements Consistent

• Ensure that requirements do not contradict each other. For example, if one requirement says “users must log in,” another shouldn’t say “guests can access without logging in.”
• Use consistent terminology. For instance, don’t refer to the same feature as both “user profile” and “account settings” in different places.

Example:

• House Example:
  • Inconsistent: One requirement states, “The house shall be built with concrete walls,” while another says, “The house shall use brick walls.”
  • Consistent: “The house shall have concrete walls for the basement and brick walls for the exterior of the first and second floors.”
• Ship Example:
  • Inconsistent: One requirement states, “The ship shall be powered by diesel engines,” while another says, “The ship shall be powered by electric motors.”
  • Consistent: “The ship shall be powered by a hybrid propulsion system, using diesel engines and electric motors, capable of switching between the two for fuel efficiency.”

Consistent requirements prevent confusion and ensure the project moves forward smoothly.

5. Make Requirements Traceable

• Every requirement should have a unique identifier (e.g., REQ-001) so it can be easily referenced and traced back to business objectives or user needs.
• Link requirements to higher-level goals, use cases, or user stories.

Example:

• House Example:
  • Traceable: “REQ-001: The house shall include a rainwater collection system to reduce reliance on municipal water supply.” (Linked to customer’s request for eco-friendly features.)
• Ship Example:
  • Traceable: “REQ-005: The ship shall meet the IMO (International Maritime Organization) emission standards for sulfur oxides and nitrogen oxides.” (Linked to regulatory requirements.)

Traceable requirements allow you to easily verify why a particular feature or design decision was made.

6. Prioritize Requirements

• Use a method like MoSCoW (Must have, Should have, Could have, Won’t have) to indicate the importance of each requirement. This helps focus on what’s essential and what can be deferred or adjusted.
• Include the priority in the requirement documentation.

Example:

• House Example:
  • “REQ-002 (Must Have): The house shall have a foundation that meets local building codes.”
  • “REQ-003 (Could Have): The house shall include a home automation system for lighting and temperature control.”
• Ship Example:
  • “REQ-004 (Must Have): The ship shall include a navigation system compliant with maritime safety standards.”
  • “REQ-005 (Should Have): The ship shall feature a luxury dining hall for 200 passengers.”

Prioritization helps ensure critical elements are addressed first and informs decision-making when constraints arise.

7. Focus on What, Not How

• Requirements should focus on what the system needs to do, not how the system will achieve it. The “how” is for the design and development phases.

Example:

• House Example:
  • Bad: “The house shall use metal studs in the walls.”
  • Good: “The house shall have walls that meet fire safety standards and local building codes.” (The contractor can decide whether to use metal or wooden studs based on what’s best for the situation.)
• Ship Example:
  • Bad: “The ship shall use fiberglass for the hull.”
  • Good: “The ship’s hull shall be constructed from materials that meet international safety standards for passenger vessels.”

This approach gives engineers and builders flexibility in choosing the best materials and methods for construction or design.

8. Use Structured Formats

• Use a standard format or template for writing requirements. This ensures uniformity and makes it easier for all team members to read and interpret the requirements.

Example Format (for Functional Requirements):

House Example (Functional Requirement Format):

• ID: REQ-001
• Title: Living Room Area
• Description: The house shall include a living room with an area of at least 400 square feet.
• Priority: Must Have
• Acceptance Criteria:
  • The living room dimensions shall measure at least 20 feet by 20 feet.
  • The living room shall be located on the ground floor and have access to natural light from at least two windows.
• Dependencies: The foundation and framing must be complete before work on the living room can begin.

Ship Example (Functional Requirement Format):

• ID: REQ-007
• Title: Lifeboat Capacity
• Description: The ship shall include lifeboats with a total capacity for at least 150% of the maximum passenger load.
• Priority: Must Have
• Acceptance Criteria:
  • The ship shall have 10 lifeboats, each capable of carrying 50 passengers.
  • Lifeboats must comply with SOLAS (Safety of Life at Sea) standards and be accessible within 5 minutes of an emergency signal.
• Dependencies: Lifeboats must be installed after the ship’s upper deck is completed.

Structured formats ensure clarity and easy tracking of requirements.

9. Avoid Negative Requirements

• Write requirements in a positive form (what the system should do) instead of stating what the system should not do. Negative requirements can create confusion.

Example:

• House Example:
  • Negative: “The house should not have any wooden parts exposed.”
  • Positive: “The house’s exterior shall be fully covered with weather-resistant materials, such as brick or siding.”
• Ship Example:
  • Negative: “The ship should not capsize in rough waters.”
  • Positive: “The ship shall be designed to remain stable and upright in waves up to 50 feet high.”

Positive requirements are easier to understand and implement.

10. Collaborate with Stakeholders

• Always involve stakeholders when drafting requirements. They can provide valuable input, correct assumptions, and clarify business needs.
• Conduct review sessions to ensure alignment and avoid miscommunication.

Example

• House Example: Collaborate with the homeowner to finalize design choices such as room layout, materials, and features.
• Ship Example: Work with the ship’s owner and regulatory bodies to ensure all safety standards and operational requirements are met.

Regular reviews and updates ensure that all parties are on the same page and that evolving needs are addressed.

Common Requirement Formats

1. User Stories (Agile):
   • “As a [role], I want [goal] so that [benefit].”
   • Example: “As the ship’s captain, I want an advanced navigation system so that I can safely guide the ship through narrow passages.”
2. Use Case:
   • Describes an interaction between the user and the system to achieve a goal.
   • Example: “The ship shall provide passengers with internet access while at sea.”
3. Functional Requirement:
   • Describes specific functionality that the system must perform.
   • Example: “The ship shall include a desalination system that converts seawater into potable water at a rate of 500 gallons per hour.”
4. Non-functional Requirement:
   • Defines how the system performs certain actions (e.g., performance, security, usability).
   • Example: “The ship’s navigation system shall respond to user input within 2 seconds”

Example of a Good Requirement

Requirement: Lifeboat Capacity and Safety

• ID: REQ-SHP-012
• Title: Lifeboat Capacity and Safety Standards
• Description: The ship shall be equipped with lifeboats capable of accommodating 150% of the maximum passenger capacity, ensuring that all passengers and crew can safely evacuate in the event of an emergency.
• Priority: Must Have
• Acceptance Criteria:
  1. The ship shall have a total of 12 lifeboats, each with a capacity to carry 100 passengers.
  2. Lifeboats shall be accessible from both sides of the ship within 5 minutes of an emergency signal.
  3. Each lifeboat shall be fully equipped with emergency supplies, including water, food, and communication devices, as per SOLAS (Safety of Life at Sea) regulations.
  4. Lifeboats shall be deployable in sea conditions up to Beaufort scale 6 (strong breeze, waves up to 13 feet).
  5. Lifeboats shall be inspected and certified by a third-party safety organization before the ship’s maiden voyage.
• Dependencies: Lifeboat installation can only proceed after the ship’s upper deck construction is complete.
• Regulatory Compliance: This requirement is in accordance with SOLAS Chapter III, Regulation 21, covering the survival craft and rescue boat standards.

Conclusion

Writing good requirements is about clarity, testability, and traceability. By focusing on specific, measurable, and unambiguous statements that reflect the stakeholders’ needs, you’ll ensure that developers, testers, and other project participants can deliver exactly what is required. Always involve stakeholders in the process and keep the language simple, structured, and consistent throughout the documentation.