Skip to content

Latest commit

 

History

History
56 lines (45 loc) · 5.51 KB

srs.md

File metadata and controls

56 lines (45 loc) · 5.51 KB
Raw

SRS

  • Specification format

    This format is used to define Sysem overall requirements, and pin them to a specific architecture outline. This replaces SRS completely. This document is a basis for SDD/HLD document.

  • General Definition

    • Purpose
    • applicable docs
    • Abbreviations

  • Introduction

    • XXX Overall system description
    • External data interfaces
    • Terms and definitions

  • Functional requirements

    • Operations
    • Sync mechanism
    • HMI / UI
    • Control
    • Subsystems
      • Rinse and repeat per system
    • Testability
    • Clock

  • Non functional requirements

    • Performance
    • Maintainability
    • Security
    • Scalability
    • Extensibility
    • Modularity
    • Verification

  • Top level architecture

    • Open architecture - (layers: open, backend, orchestration, operatingsystem, cross cutting concerns (tracing, logging, monitoring - and security))
    • Layered architecture !NOTE: This is still relevant as it represents the logical layering of microservices and units of work
    • External interface
      • Data
      • Display
      • Network (also include deployment vs lan network diagram)
    • Internal third parties and tools

Have all user stories defined For each user story describe how is it tested

Requirements checklist

General (SRS requirements) Checklist Is a functional overview of the system provided? Have the software and hardware environments been specified? If assumptions that affect implementation have been made, are they stated? Has every definition, acronym and abbreviation been defined in the Glossary? Are all the definitions, acronyms and abbreviations in the Glossary correct? Are all the requirements, interfaces, constraints, definitions, etc. listed in the appropriate sections? Interface Checklist Are all inputs to the system specified? Are all outputs from the system specified? Are all interface requirements between hardware, software, personnel, and procedures included? Behavioral Requirements Checklist Have all requirements described in the problem statement and in subsequent communications with the customer been specified? Are all inputs to a function sufficient to perform the required function? Are undesired events/inputs considered and their required responses specified? Non-Behavioral Requirements Checklist Is the reliability specified, including the consequences of software failure, the vital information that needs to be protected from failure, and the strategy for error detection and recovery? Are planned changes specified (i.e., maintainability)? Are acceptable trade-offs between competing non-behavioral properties specified? Requirements Quality Does each requirement avoid conflicts with other requirements? Does each requirement have a priority? Are the priorities reasonable? (e.g. essential program functionality should not be on a low priority) Do the requirements avoid specifying design? Are the requirements at a fairly consistent level of detail? should any requirement be specified in more detail? Should any requirement be specified in less detail? Are the requirements clear enough to be turned over to an independent group for implementation and still be understood? Is each requirement testable? Will it be possible for independent testing to determine whether each requirement has been satisfied?

List of nun-functional requirements and -ilities

Performance – for example Response Time, Throughput, Utilization, Static Volumetric Scalability Capacity Availability Reliability Recoverability Maintainability Serviceability Security Regulatory Manageability Environmental Data Integrity Usability Interoperability

Accessibility Adaptability Auditability and control Availability (see service level agreement) Backup Capacity, current and forecast Certification Compliance Configuration management Cost, initial and Life-cycle cost Data integrity Data retention Dependency on other parties Deployment Development environment Disaster recovery Documentation Durability Efficiency (resource consumption for given load) Effectiveness (resulting performance in relation to effort) Emotional factors (like fun or absorbing or has "Wow! Factor") Environmental protection Escrow Exploitability Extensibility (adding features, and carry-forward of customizations at next major version upgrade) Failure management Fault tolerance (e.g. Operational System Monitoring, Measuring, and Management) Integrability ability to integrate components Internationalization and localization Interoperability Legal and licensing issues or patent-infringement-avoidability Maintainability (e.g. Mean Time To Repair - MTTR) Management Modifiability Network topology Open source Operability Performance / response time (performance engineering) Platform compatibility Privacy (compliance to privacy laws) Portability Quality (e.g. faults discovered, faults delivered, fault removal efficacy) Readability Reliability (e.g. Mean Time Between/To Failures - MTBF/MTTF ) Reporting Resilience Resource constraints (processor speed, memory, disk space, network bandwidth, etc.) Response time Reusability Robustness Safety or Factor of safety Scalability (horizontal, vertical) Security (cyber and physical) Software, tools, standards etc. Compatibility Stability Supportability Testability Throughput Transparency Usability (Human Factors) by target user community Volume

some functional :

Business Rules Transaction corrections, adjustments and cancellations Administrative functions Authentication Authorization levels Audit Tracking External Interfaces Certification Requirements Reporting Requirements Historical Data Legal or Regulatory Requirements