specl-specification.yaml

---
identity:
  company: DevFactory
  version: 2.0

#
# This document represents an L1 specification which describes in thorough 
# technical detail a single Milestone; it can consist of a single file, or
# multiple files, imported via referencing.
#
# Syntax is [SpecL Markdown](https://...) (i.e. Markdown + Gherkin).
# 

title: >
  L1 Spec: {/Metadata/Product Name} - 
  {/Metadata/Release Name} - 
  M{/Metadata/Milestone Number}

header: >
  L1 Spec: **Milestone {/Metadata/Milestone Number}**
  Release {/Metadata/Release Name}
  {/Metadata/Product Name}

footer: >
  L1 schema version {schema: version} - Author: {/Metadata/Owner | "Unknown"} - {schema: company | "DF"}

schema:

  #
  # This is expected to be the first section of the Spec and it contains
  # complete identification information.
  # 
  Metadata:
   
    # Short Capitalized Product Name.
    Product Name: "MySuperProduct"
    
    # Usually a version number, but can be a name also.
    Release Name: 1.23

    # (optional) Link to the parent L2 Spec (if any).
    L2 Spec Link: "https://drive.google.com/akhifk3..."

    # A simple integer denoting the milestone count.
    Milestone Number: 3

    # A name for this milestone.
    Milestone Name: "Optimization"

    # A ticket code, such as JIRA-123.
    JIRA Ticket: "CMSP-291"
      
    # [email protected]
    Owner: "[email protected]"

    # URI always pointing to the original spec.
    Original: "{this}"

  #
  # Complete this list to introduce any acronyms or jargon used in this spec.
  #
  Glossary:
    - 
      Term: 
      Definition: 

  #
  # Capabilities fall into a number of different Capability Types. This is expected
  # to expand over time as our product management and engineering practices evolve. 
  # Any TPM should feel empowered to define a new capability type and template and 
  # add it to this repository.
  #
  Capabilities:
    - 
      Summary: All GET API calls return under 20ms.
      Definition: >
        Feature: Some terse yet descriptive text of what is desired
          Textual description of the business value of this feature
          Business rules that govern the scope of the feature
          Any additional information that will make the feature easier to understand

          Scenario: Some determinable business situation
            Given some precondition
              And some other precondition
            When some action by the actor
                And some other action
                And yet another action
              Then some testable outcome is achieved
                And something else we can check happens too

          Scenario: The system is responsive with 100k users registered
          Given there are 100,000 users registered on the system
           When I create a new account
           Then I should be taken to my dashboard within 5ms

           Scenario: The system is responsive with 1000 concurrent users on the homepage
           Given 1000 users are hitting the homepage simultaneously
            Then each user should get a response within 2ms