System Requirements Specification Project Odin

Kyle Erwin Joshua Cilliers Jason van Hattum Dimpho Mahoko Keegan Ferrett Note: This document is constantly under revision due to our chosen methodology, and is subject to change.

Current version: v1.0

Contents

Contents Introduction . . . . . . Overall Description . Specific Requirements Appendices . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. 1 . 3 . 6 . 13

Introduction This section describes the scope of Project Odin, as well as an overview of the contents of the SRS document. Additionally, the purpose of the document is defined as well as a list of abbreviations and definitions.

.1

Purpose

The purpose of this document is to provide a thorough description of the requirements for Project Odin. The requirements, constraints, interfaces and interactions with other systems will be described in this document. This document is intended as a point of reference for the client, as well as a means of keeping track of our decisions and the project for us as the development team.

.2

Scope

"Project Odin" is a tool for generating computational models via a simple drag-and-drop interface. The idea is that an average user with little to no programming experience will be able to build highly complex models, for a range of tasks such as machine learning, statistical analysis or image manipulation. Users will also be able to create projects which will each contain a computational model, which will then be able to be used as a component in another persons model. In this way, large, complex models can be built up from components which consist of models themselves. Project authors will be able to share their projects, including a description, and be able to view the usages and popularity of their components.

.3

Definitions, Acronyms and Abbreviations • User - A user that is using the application. • Model - A computational model built in the application. • Project - A computational model that has been shared. • Component - A project that is used in another project. • Odin - This product.

.4

References

Empty for now. 1

.5

Overview

This document includes 4 sections: 1. Introduction 2. Overall Description 3. Specific Requirements 4. Appendices The sections are laid out as follows: Section 2 - Overall Description Section 2 provides an overview of the systems functionality and it’s interaction with other systems. This chapter also outlines the users of the system and their interaction with it. Finally, the constraints and assumptions are defined. Section 3 - Specific Requirements Section 3 starts off by outlining the specific requirements for each external interface, followed by a description of the function requirements. This is followed by the performance requirements and design constraints. Section 3 then describes the attributes or non-functional requirements of the system, including it’s reliability, security, availability and interoperability. Finally, any other requirements not under the preceding categories are listed. Appendices The appendices are empty for now.

2

Overall Description This section will provide an overview of the systems functionality and it’s interaction with other systems. This chapter will also outline the users of the system and their interaction, as well as the development constraints and assumptions made.

.1

Product Perspective

System Interfaces There are zero interfaces between this system and other pre-existing systems at this time. User Interfaces Will be expanded upon The user interface primarily makes use of a drag-and-drop component based system. Each component acts as a function which can be made up of further components. Users add components in to a workspace where they can add links between components by dragging from one component’s input or output nodes to those of another component. The navbars and other sections of the interface are all stylized with Materialize, so as to have a unified theme and styling. These navbars will contain the functionality needed to handle the management of the components created using the system. This part of the interface will be expanded upon further into the project. Hardware Interfaces The only hardware interfaces used by this system are network interfaces such as Ethernet and/or WiFi. Software Interfaces The only software interfaces used by this system are the operating system (Linux), and any software required for network communication. Communications Interfaces Interfaces used for communication are TCP sockets and HTTP requests. 3

Memory Interfaces There are zero memory interfaces used by this system at this time. Operations Interfaces Empty for now. Site Adaptation Requirements Very few site adaptation requirements are present, save for the need to install the software on the server and use it on the clients side. Software required to run the server: An operating system, and Python 3.4 for the CLI.

.2

Product Functions

The overarching goal of this project is to allow mathematicians and other people who are not proficient programmers to develop and share computational models. Functions • Design and implement computational models using a variety of mathematical operators. • Share computational models to be used as components in other computational models. • Execute computational models with a set of inputs and return an output. • Provide user interfaces for all of the above.

.3

User Characteristics

Main user groups: • Mathematicians • Researchers • Casual users Mathematicians Mathematicians will use the product to design, develop and test mathetical models. They will also probably share their models for use by the general community. What we know: 4

• They are educated. • They are likely older than 25. • They likely are relatively computer literate, but not completely. • They can think logically and solve problems effectively. • They might prefer shortcuts and more efficient ways to do things over a amateur-friendly interface. Researchers Researchers will use the product to test out theories and hypotheses, most likely about things related to Computer Science such as Articial Intelligence. What we know: • They are educated. • They are likely even older. • They are likely very computer literate. • They are likely logical and good at problem solving. Casual Users Casual users may just use the product as a means to find out the result of some mathetical problem, without exploiting the full power of the system. The product is not aimed at these people. What we know: • Their education is unknown. • Due to the complexity of the models used by the system, they are likely adults.. • Their computer literacy is unknown. • They would probably prefer a more amateur-friendly interface.

.4

Constraints

Empty for now.

.5

Assumptions and Dependencies

Empty for now.

5

Specific Requirements This section starts off by outlining the specific requirements for each external interface, followed by a description of the function requirements. It then continues with the performance requirements and design constraints, as well as the the attributes or non-functional requirements of the system. Finally, any other requirements not under the preceding categories are listed.

.1

External Interface Requirements

.2

Functional Requirements

CLI - Command Line Interface (Odin-CLI)

Figure 1: Use Case Diagram for Odin-CLI

Shell • R1.1 - Important - There should be some way for users to find the functions of CLI commands. • R1.2 - Critical - The CLI should always provide clear, concise and expressive information messages to keep the user informed. • R1.3 - Critical - The CLI should always provide clear, concise and expressive error messages when something goes wrong. 6

Variables • R2.1 - Critical - The CLI should store variables in the current session. • R2.2 - Critical - Users should be able to create variables. • R2.3 - Critical - Users should be able to assign values to the variable. • R2.4 - Critical - Users should be able to view the value of a variable. • R2.5 - Critical - Users should be able to view all the variables in the session. • R2.6 - Critical - Users should be able to delete variables. Operations • R3.1 - Critical - Users should be able to perform both multi-operand and single-operand operations with variables. • R3.2 - Critical - Components should be able to be added to be used as operations. Session • R4.1 - Critical - Users should be able to execute the session and view the result. • R4.2 - Critical - The CLI should be able to send the variables (as a .json file) and the operations (as text) to the daemon. • R4.3 - Critical - The CLI should interpret the results of the execution as received from the daemon. Daemon and Execution Engine (Odin-Daemon) Communication with CLI • R5.1 - Critical - The Daemon must always maintain a secure and reliable chain of communication with the CLI Shell. • R5.2 - Critical - The C++/JSON Parser should always produce error-free interpretations of the JSON objects passed to it. • R5.3 - Important - The Calculations passed to the Daemon should always first be stripped down to their most basic operations by the CLI. • R5.4 - Important - The Daemon will always return the results of calculations and/or appropriate error messages to the CLI. 7

Calculations • R6.1 - Critical - Users should not be able to interact with the Daemon directly. All interaction should be handled by the CLI. • R6.2 - Important - The Daemon will only perform calculations on the four basic operations, addition, subtraction, multiplication and division. • R6.3 - Critical - The Daemon will further treat all calculations as matrix based operations. • R6.4 - Critical - The Daemon will cater to calculations of matrices of ANY rank. Front-End User Interface (Odin-Web)

Figure 2: Use Case Diagram for Odin-CLI

Odin Application Programming Interface (Odin-API) Empty for now.

.3

Quality Requirements

Requirements are denoted by being either high, average, or low priority so as to indicate which requirements have to be met first. The CLI and Daemon need to focus on performance gains over nearly every8

thing else and as a result all performance related requirements are automatically labelled as being the highest priority. CLI - Command Line Interface (Odin-CLI) The CLI should always be as smooth and usable as possible - it acts as a user interface for the system. • Priority - high: Performance - There should be minimal (ideally zero) input lag when typing in the CLI. • Priority - high: Performance - Communication between the CLI and the Daemon should be as fast as possible. The standard will be less than a second for the platforms to send initial acknowledgements (ACK) to each other. From there communications will vary based on calculation times. • Priority - high: Performance - Interpretation and parsing of both the session and the result from the daemon should be as fast as possible. • Priority - average: Auditability - Whenever there is a delay that cannot be helped, the user should be informed. Daemon and Execution Engine (Odin-Daemon) The Daemon will be the workhorse of the system, and as such needs to perform reliably and consistently for as long as possible • Priority - high: Performance - The workload of the daemon will mostly consist of the calculations it performs, and as such nearly everything else will need to be offloaded elsewhere to minimize computational load. • Priority - high: Performance - The Daemon will have to meet a performance metric of x number of base calculations per second. (still to be decided - This remains a difficult task due to the complication of the Daemon performing all calculations as if on N-Rank matrices). • Priority - high: Reliability - The Daemon should strive to avoid hard crashes at all costs. A benchmark will be conducted to ensure it can run a full day with constant calculations being fed to it without crashing. Front-End User Interface (Odin-Web) • Priority - high: Performance - The drag-and-drop system needs to render as quickly as possible, preferably in under 3 seconds. • Priority - high: Performance - The drag-and-drop system needs to avoid producing input lag by being too heavy on system resources. • Priority - high: Security - The system must ensure the security of all users’ sensitive information by storing usernames and passwords as little as possible and by NEVER storing them in an unhashed format. 9

• Priority - high: Performance/Scalability - The system must be able to scale to a large number of on screen components, preferably 50, before noticing any performance loss. Odin Application Programming Interface (Odin-API) • Priority - high: Performance - The API must always respond to requests, either with a result, or with an appropriate error message. • Priority - high: Security - The system must ensure the security of all users’ sensitive information by storing usernames and passwords as little as possible and by NEVER storing them in an unhashed format.

.4

Design Constraints

Emphasis was placed on the usage of the following technologies or architectures by the client for certain parts of the project. • CLI: Python • Daemon: C++ • Web: Bootstrap • API: Express • DB system: Mongo • Web-Frontend: Angular 4 Empty for now.

.5

Software System Attributes

Reliability Users should be able to trust that the system will perform as expected. • All components should fail as little as possible, and should fail gracefully if they do (with clear and expressive error messages). • The CLI and daemon should reliably communicate with each other, and inform the user if something goes wrong. • All mathematical functions in the daemon should be completely correct. • All user-made components should be testable and guaranteed to provide at least some output. 10

Security • The system must ensure the security of all users’ sensitive information by storing usernames and passwords as little as possible and by NEVER storing them in an unhashed format. Availability The system should endeavour to be online and usable whenever necessary. • The package manager (opm) should be online as much as possible - users should be able to install components whenever needed. • Whenever the CLI and Daemon are running simultaenously, they should be able to communicate flawlessly. Interoperability Empty for now.

.6

Use Cases

Create Projects • Priority: Critical • Pre-conditions: The user isn’t logged in or the chain-of-communication between services is broken. • Post-conditions: A new project must have been created under the user’s name. Register/Login • Priority: Critical • Pre-conditions: The user’s registration details are duplicates, or the user has entered his username and/or password incorrectly. • Post-conditions: The user should either be registered or they should be logged in. Create Models • Priority: Critical • Pre-conditions: The graphing service or design space malfunctions. • Post-conditions: The design space allows the user to create a new model. 11

Create Components • Priority: Critical • Pre-conditions: The system is unable to make requests to the API for the list of components. • Post-conditions: A new component must have been added to the design space’s drawing board. Browse Projects, Models, or Components • Priority: Critical • Pre-conditions: The system is unable to make requests to the API for the list of components, models, or projects. • Post-conditions: The appropriate list needs to be returned to the user. CRUD Operations On Models, Components, and/or Projects • Priority: Critical • Pre-conditions: The system is unable to make requests to the API to perform any of these operations. • Post-conditions: The API returns a message stating that the operation was successful. Execute Calculation • Priority: Critical • Pre-conditions: The Daemon has crashed or the chain-of-communication between systems has broken. • Post-conditions: The system returns the results to the user upon completion of the calculation

.7

Other Requirements

Empty for now.

12

Appendices Empty for now.

13

14

15

System Requirements Specification - GitHub

This section describes the scope of Project Odin, as well as an overview of the contents of the SRS doc- ument. ... .1 Purpose. The purpose of this document is to provide a thorough description of the requirements for Project Odin. .... Variables. • R2.1 - Critical - The CLI should store variables in the current session.

149KB Sizes 0 Downloads 105 Views

Recommend Documents

System Requirements Specification - GitHub
System Requirements Specification. Project Odin. Kyle Erwin. Joshua Cilliers. Jason van Hattum. Dimpho Mahoko. Keegan Ferrett. Note: This document is constantly under revision due to our chosen methodology, ... This section describes the scope of Pro

Modern Requirements Specification
However, trends in system development have made the numerous problems ... not only enabled better requirements management; they have also enabled the ..... requirements methods, and better-standardized content for our requirements.

Orc Protocol Specification - GitHub
Aug 15, 2017 - This specification documents the Orc network protocol in its entirety for the purpose of enabling .... services and authentication is performed by the nature of Tor's routing. Each Orc node ... associated with held contracts (5. Data T

Specification on Image Data File Version - GitHub
5.4.10 ShootingRecord heap ... the JFIF file format[1], as described below), sample software shall be provided openly to player vendors. ... In the separate "Decisions Concerning Extension" section, we define how various companies.

LERUKA LERUKA UseCase Specification: View public ... - GitHub
UseCase Name. Brief Description. Mockup. Flow of Events. Basic Flow. Narration. Alternative Flows. Special Requirements. Preconditions. Postconditions.

Hypervisor Top Level Functional Specification - GitHub
100. HvSendSyntheticClusterIpiEx . ...... That is, the hypervisor is free to deliver the interrupt ..... When a message is sent, the hypervisor selects a free message buffer. ...... The Flags field included an invalid mask value in the proximity doma

Anonymous Go-Kart: Specification Report Supervisor - GitHub
May 9, 2011 - [email protected] (83238549). Wim Looman ... Department of Computer and Electrical Engineering. University of ... kart, so that it can be easily controlled by a laptop. The second is to ..... BostonDynamicsTRQ6Sep09.pdf.

HELM Web-based Editor Requirements Specification V1_0.pdf ...
HELM Web-based Editor Requirements Specification V1_0.pdf. HELM Web-based Editor Requirements Specification V1_0.pdf. Open. Extract. Open with.

Software Requirements Specification versi 2.pdf
There was a problem loading this page. Retrying... Whoops! There was a problem previewing this document. Retrying... Download. Connect more apps... Try one of the apps below to open or edit this item. Main menu. Whoops! There was a problem previewing

HELM Web-based Editor Requirements Specification V1_0.pdf ...
3.1 Web-Editor Functional Requirements. ... 3.2 Non-Functional requirements . ... Page 3 of 15. HELM Web-based Editor Requirements Specification V1_0.pdf.

CBIR System - GitHub
Final result was a Matlab built software application, with an image database, that utilized ... The main idea is to integrate the strengths of content- and keyword-based image ..... In the following we present some of the best search results.