NixosTegraX1/SRS

From air
Revision as of 10:05, 6 February 2017 by Vincent.Turrin (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

The document provides a template of the Software Requirements Specification (SRS). It is inspired of the IEEE/ANSI 830-1998 Standard.


Read first:

Document History
Version Date Authors Description Validator Validation Date
0.1.0 TBC TBC TBC TBC TBC


1. Introduction

1.1 Purpose of the requirements document

1.2 Scope of the product

This project aims to port NixOS to an ARM architecture and more specifically to integrate it on a Nvidia TegraX1 card.

1.3 Definitions, acronyms and abbreviations

Docker:A system of light virtualisation, sharing the kernel of the launching machine, providing an independant file system.

Package:A software package is an archive file containing a computer program as well as necessary metadata for its deployment.

Package manager:Tool that automates the process of installing, upgrading, configuring, and removing computer programs.

1.4 References

1.5 Overview of the remainder of the document

2. General description

2.1 Product perspective

This project consists of porting NixOS to a new architecture meaning we mainly need to work on the assembly code below the OS abstraction layer.

2.2 Product functions

At the end, we should be able to boot NixOS on a TegraX1 card.

2.3 User characteristics

The user should be able to easily install the OS on his system.

2.4 General constraints

2.5 Assumptions and dependencies

The user needs a system embedding an ARM 64bits CPU.

3.Specific requirements, covering functional, non-functional and interface requirements

  • document external interfaces,
  • describe system functionality and performance
  • specify logical database requirements,
  • design constraints,
  • emergent system properties and quality characteristics.

3.1 Requirement X.Y.Z (in Structured Natural Language)

Function:

Description:

Inputs:

Source:

Outputs:

Destination:

Action:

  • Natural language sentences (with MUST, MAY, SHALL)
  • Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
  • Mathematical Notations
  • Tabular notations for several (condition --> action) tuples

Non functional requirements:

Pre-condition:

Post-condition:

Side-effects:

4. Product evolution

5. Appendices

6. Index