#requirements #systems #engineering #documentation #ops #mechanical #prgramming #electrical #strategy

1 Purpose

The purpose of this document is to standardize a process for capturing requirements.

2 Scope

The departments interacting with requirements:

• Strategy
• Operations
• Systems Engineering
• Mechanical Engineering
• Electrical Engineering
• Programming

3 Types of Requirements

Grayson Robotics uses three methods for gathering system requirements: User Story mapping, Use Cases, and Implementation requirements.

3.1 User Stories

A User Story is an informal narrative description of user needs and expectations that helps designers understand what the stakeholders wish to accomplish. User Story Mapping is a method for capturing a narrative description of stakeholder goals and strategy by way of dialogue between designers and stakeholders.

User stories are documented with Casual Use Cases and other informal written or visual methods. A user story may be composed of multiple documents and images.

3.2 Use Cases

Use cases are functional requirements in the form of a scenario and its accompanying context. Functional requirements describe system or sub-system behavior while carefully omitting implementation details. A use case scenario describes the interaction between the System Under Design (SUD) and other actors.

Use cases are categorized by their formality, being either Detailed or Brief. Formal use cases comprise the final design while casual use cases help designers understand the problem. Casual use cases may also serve as drafts for formal use cases.

Use cases may describe the behavior of: the system as a whole, a logical subsystem described by the Logical Architecture, or physical subsystem described by the Physical Architecture.

3.3 Implementation requirements

Implementation (Non-functional) requirements are constraints on the systems composition that can be thought of as implementation decisions.

Implementation requirements take the form of short, atomic, "shall" statements collected into tables.

4 Requirement document structures

Authors shall write requirements in accordance with the structures defined here:

• Brief Use Case Structure
• Detailed Use Case Structure
• Implementation requirement structure

4.1 Brief Use Case Structure

A Brief use case includes the following fields:

• Title
• Date
• Primary Actor: The stakeholder (including another system or sub-system) that initiates the interaction.
• Goal In Context: Goal of the primary actor wants to achieve by the end of the scenario.
• Scope: What system, subsystem, or component are we describing the behavior of?
• Precondition: What must be true before the scenario can start?
• Scenario: List of steps forming the interaction that describes SUD behavior.
• Notes: Any notes the author thinks will be useful later, especially for other team members.

4.2 Detailed Use Case Structure

A Detailed use case includes all fields from a Brief use case, except Scenario which is replaced by Main Success Scenario and Extensions:

• Stakeholders & Interests: A list of stakeholders and interests. These may be other systems or sub-systems.
• Secondary Actors: What other important actors will interact with the SUD during the scenario?
• Minimal Guarantees: What do we expect will happen even if their is a failure?
• Success Guarantees: What must happen to consider the interaction a success?
• Trigger: Describe the action taken by the Primary Actor that initiates the scenario.
• Main Success Scenario: The optimal and expected case where nothing goes wrong.
• Extensions: Extensions to the main scenario that deviate from the success scenario, whether failing or not.
• Response Time: How fast must the system respond to the trigger?
• Frequency: How often do we expect to initiate this scenario?
• Risks: Complexity, difficulty, technological challenge that could affect the completion of this requirement.
• Open Issues: Explicitly state any known-unknowns or known limitations.

4.3 Implementation requirement structure

As part of the title and file name, each requirement should have a unique numerical ID.

Document content:

• Scope: the subsystem or discrete component that the requirement applies to, if not the robot as a whole
• Timestamp w/date, time (24H), UTC offset
• Requirement text (shall statement)
• Version number: auto-incrementing on each change
• Author
• Priority: Mandated, High, Medium, Low
• Status: Accepted or Deleted
• Risks: Complexity, difficulty, technological challenge that could affect the completion of this requirement.