How to Write

How to Write a Supplementary Specification

Posted on by Anthony James
19
Aug

How to Write a Supplementary Specification

I caught up with Klara, our content development manager, to learn more about Supplementary Specifications and get some context on when you’d use this instead of other more commonly used specifications docs, such as BRS and SRS documents. I also wanted to know how it differs from the more commonly used Product Requirements Specification.

What is a Supplementary Specification?

Sean: “So, Klara, to get started, can you put some context on this type of spec? I haven’t heard of it before and it sounds very similar to other types of specs. Just what is a supplementary spec?”

Klara: “Hi Sean, so yes, there is some overlap. You can see it as a document for capturing non-functional requirements and other system-wide requirements that don’t fit neatly into use cases or other more specific requirement documents.”

Sean: “So how does it differ from other specification documents”

Klara: “A few ways. Let’s zero in on a few areas:

  1. Context
  • Supplementary Specification: Focuses on non-functional requirements (such as performance, reliability, usability) and concerns that affect the entire system.
  • Other specifications, such as Software Requirements Specifications, typically describe functional requirements, specific features, or user interactions.
  1. Scope
  • Supplementary Specification: System-wide, applies to the entire project.
  • Other specifications: May be feature-specific or component-specific.
  1. Level of detail
  • Supplementary Specification: Often higher-level, describing overarching quality attributes and constraints.
  • Other specifications: Can be more detailed, describing specific behaviors or interactions.
  1. Relationship to use cases
  • Supplementary Specification: Complements use cases by capturing requirements that don’t fit well into the use case format.
  • Use Case Specification: Focuses on describing specific user-system interactions and scenarios.
  1. Timing in the development process
  • Supplementary Specification: Often developed early in the project and updated throughout.
  • Other specifications: May be created at various stages, depending on the development methodology.
  1. Audience
  • Supplementary Specification: Often used by architects, designers, and testers to ensure system-wide qualities are addressed.
  • Other specifications: May be more targeted to specific development teams or stakeholders.”

Who Writes the Supplementary Specification?

Sean: “Ok, that really helps position it. So, who actually writes this document? The BA?”

Klara: “It’s often more of a mix. Because of the nature of the document, in that it doesn’t fit neatly into more traditional SDLC document, it can often be a more collaborative effort. However, typically, the BA ‘own’ it. Here’s a bit more detail about who writes it:

  1. Business Analysts
  • Often take the lead in coordinating the creation of the document
  • Gather and document non-functional requirements from stakeholders
  • Ensure alignment with business goals and user needs
  1. Systems Architects
  • Contribute technical constraints and system-wide quality attributes
  • Provide input on architectural decisions that affect non-functional requirements
  • Help define performance, scalability, and reliability requirements
  1. Product Managers
  • Provide input on product vision and strategic goals
  • Help prioritize non-functional requirements
  • Ensure alignment with market needs and competitive positioning
  1. Software Developers
  • Contribute to technical feasibility assessments
  • Provide input on development constraints and best practices
  • Help define maintainability and coding standards
  1. Compliance Officers
  • Contribute regulatory and compliance requirements
  • Ensure alignment with legal standards and industry regulations
  1. Subject Matter Experts
  • Provide domain-specific requirements and constraints
  • Help define business rules that affect the entire system

The actual writing is often done by the Business Analyst or a dedicated Technical Writer, but the content is a collaborative effort.

I’d also add that the specific roles involved will vary depending on the nature of the project. You may not need them all. Depends.”

Download Supplementary Specification

Sean: “Thanks for that. So where can we learn more about this document?”

Klara: “We’ve just added it to the shop now, so you can download it over here.”

Sean: “And where can people find you if they want to reach out?”

Klara: “Twitter, for sure. And LinkedIn where I publish our newsletter.”

Learn More

Anthony James