RICM4 2017 2018 - ChatBot / SRS

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

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

The SRS is a document describing the software system of our DashBoard project for OAR. It describes how the system is supposed to work with functional and non functional requirements.

1.2 Scope of the product

The “Service d’Accueil Handicap” (Disabled Welcoming Service) located in Saint-Martin d’Hères allows more than 900 residents each year to benefit from personal advices and support services for disabled students.

Due to a strong affluence and limited space, a need for automation has been felt by the SAH’s team.

The ChatBot project aims to provide a solution to this problem.

1.3 Definitions, acronyms and abbreviations

A ChatBot is a conversation program which conducts a conversation via auditory or textual methods.

1.4 References

• The main page of the project: https://air.imag.fr/index.php/Chatbot_pour_borne_d%27accueil_handicap

• The UML:

2. General description

2.1 Product perspective

Getting involved in other institutions linked to the health sector.

Building a system capable of recognizing vocal phrases for visually impaired individuals.

2.2 Product functions

Providing an answer adapted to the requests of a disabled user thanks to an automaton.

It should be able to lead a discussion in a logical and consistent way from the beginning to the end of it, which means its interactions have to be as close as possible from the ones a real human would have.

It also needs to collect some important informations about the user it’s discussing with.

This conversation will take place on a web/mobile app.

2.3 User characteristics

Disabled students (essentially deaf and dumb individuals) living in Grenoble and studying in the Grenoble-Alpes University.

2.4 General constraints

Disablement of users. Web hosting, database and user files.

2.5 Assumptions and dependencies

The disabled student must have an access to a smartphone or a computer in order to use the application.

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 1 :

Function:

Description:

Inputs:

Source:

Outputs:

Destination:

Action:

Non functional requirements:

Pre-condition:

Post-condition:

Side-effects:

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

Not acting only for disabled students but also for a wider pool of individuals.

5. Appendices

SRS related documents used to establish this page :

• 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