Difference between revisions of "Proj-2013-2014-Open DynDNS/SRS"
Line 90: | Line 90: | ||
-Server -> any public ISP subscription network. |
-Server -> any public ISP subscription network. |
||
+ | |||
+ | The daemon on the client side makes use of various IP detecting websites to determine the correct public IP address of itself. |
||
* '''Local''' |
* '''Local''' |
||
-Daemon and client -> any traditional network of a small company |
-Daemon and client -> any traditional network of a small company |
||
+ | |||
+ | mDNS clients are installed on each participating machine in the multicast network for the distributed protocole to function. It should be reminded that mDNS is installed above a standard internal DNS system and therefore the updates should be taken into account by the DNS server. |
||
==2.2 Product functions== |
==2.2 Product functions== |
Revision as of 12:08, 10 March 2014
The document provides a template of the Software Requirements Specification (SRS). It is inspired of the IEEE/ANSI 830-1998 Standard.
Read first:
- http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
- http://en.wikipedia.org/wiki/Software_requirements_specification
- IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998
Version | Date | Authors | Description | Validator | Validation Date | |
---|---|---|---|---|---|---|
0.1.0 | 27/1/2014 | Lionel Boey | Projet requirement | Thomas Calmant | 28/1/2014 | |
0.1.1 | 10/2/2014 | Lionel Boey | Overview of project | Thomas Calmant | 11/1/2014 | |
1.0.0 | 17/2/2014 | Lionel Boey | Preliminary contract | Thomas Calmant | 18/2/2014 |
1. Introduction
1.1 Purpose of the requirements document
The purpose of this Software Requirement Document (SRS) is to provide detailed overview of our 4th year RICM project called Open DynDNS. Being an open-source project, this document can be used as a guideline and reference to potentiel future contributors and designers to take part in software delivery lifecycle (SDLC) processes.
In short, this document defines how our client, team and our tutor see the product and its functionality by understanding the user interface, hardware and software requirements.
1.2 Scope of the product
- This project aims to provide open-source DNS solution for end-users who often find themselves in changing network environment (Dynamic IP address, hostname etc)
- These users would like to dynamically configure their own DNS server and make their servers accessible from the said network
1.3 Definitions, acronyms and abbreviations
- DNS : Domain Name System
- BIND : Berkeley Internet Name Domain
- REST : Representational state transfer
- JSON : JavaScript Object Notation
- Kivy : open source Python library for developing multitouch application software with a natural user interface (NUI).
- Flask : A lightweight web application framework written in Python
1.4 References
- FLASK : Tutorials on Flask API and its REST-ful methodes
- Wikipedia : General definitions on various notions
- Kivy : Quickstart guide on Kivy on Android tablettes
- UbuntuForums : Bind9 server set-up and configurations
- MQTT : Tutorial on MQTT
- WhatsMyIP : Various network diagnostic tools
1.5 Overview of the remainder of the document
The following parts of this document provide a general description of the project.
Section 2 describes the characteristics of the users of this application, some of the constraints encountered while working on the project and a few assumptions and dependencies made by the developers
Section 3 provides primarily technical documentations for developers such as the hardware used for this application, the functional requirements, data requirements and constraints and assumptions made while designing and implementing the Open DynDNS solution. It also gives the user viewpoint of product. Section 4 is for supporting information.
2. General description
This section of the SRS should describe the general factors that affect 'the product and its requirements. It should be made clear that this section does not state specific requirements; it only makes those requirements easier to understand.
2.1 Product perspective
The daemon/server couple shoule be capable of deploying into any traditional network. For each version of the project :
- Public
-Daemon -> public wifi network.
-Server -> any public ISP subscription network.
The daemon on the client side makes use of various IP detecting websites to determine the correct public IP address of itself.
- Local
-Daemon and client -> any traditional network of a small company
mDNS clients are installed on each participating machine in the multicast network for the distributed protocole to function. It should be reminded that mDNS is installed above a standard internal DNS system and therefore the updates should be taken into account by the DNS server.
2.2 Product functions
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and dependencies
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: To dynamically updates the public IP address of a host on a DNS server whenever the host is mobile and is located in a foreign network
Description: Implement an open source dynamic DNS server and demon to run on various device (PC, laptop, Android tablet etc)
Inputs: Dynamic IPs
Source: Users who host their websites or depositories behind a router/modem with dynamic IP
Outputs: Dynamic DNS updates
Destination: Open DynDNS server
Action:
- Open DynDNS client must notify OpenDynDNS server whenever it detects a change in IP adress on the host
- Open DynDNS server updates shall not be modified by non-recognizable device
Non functional requirements:
- Open DynDNS client may be run on various device such as a laptop, PC or an Android tablet.
Pre-condition:
- Hardware
- Raspberry PI - Android tablette (Nexus 10) - 2 machine running on Linux
- Software
- Ubuntu desktop - MQTT sensors - Flask API and Flask REST-ful - Kivy - Liclipse for Python
Post-condition:
- User must be situated in a foreign network with different public IP address before launching the daemon
Side-effects: