RICM4 2017 2018 - Entrepreneur AUBERT COURTIAL/ SRS

From air
(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

1. Introduction

1.1 Purpose of the requirements document

This Software Requirements Specification (SRS) identifies the requirements for the Entrepreneur project. The purpose of the present document is to explain how we organize our project, the different steps of the conception and the project achievement.

1.2 Scope of the product

  • The purpose of this project is to create a web application for an association.
  • Social entrepreneurs can use this web application to find skills according to their project.
  • The main theme is sharing skills.
  • Anyone can go on this web application and share their skills.

1.3 Definitions, acronyms and abbreviations

Meteor : Framework used for this project.

1.4 References

1.5 Overview of the remainder of the document

2. General description

2.1 Product perspective

This project is a web application targeting social entrepreneurs to share skills with each other.

The website will be created with the framework Meteor.

2.2 Product functions

The user can log thanks to user account and :

  • Find a skill and offer a meeting.
  • Offer his own skill.
  • Respond to other user interested in his offers.
  • Manage his account and offers.

2.3 User characteristics

Simple user who just need to know how to log, create a account, and use a website. But the website is mainly aiming at social entrepreneurs.

2.4 General constraints

The security of the web application : Users must not be allowed to modify the database themselves.

2.5 Assumptions and dependencies

The website depends on the framework Meteor and the different packages installed. It also depends on bootstrap for the css.

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 SearchBar

Function: Search in the database using the input

Description: Search in the skill offers database using the words given as an input

Inputs: Words as String

Source: Wep application

Outputs: Skill offer list that matches the words given in parameters

Destination: Web application


  • Read the input
  • Search in the database using the words in the input search bar
  • Display the skill offers that matches the input.

Non functional requirements: None

Pre-condition: Internet connection

Post-condition: None

3.2 Create, modify or delete skill offers

Function: Create, modify or delete the user skill offers

Description: A user will be able to create an offer and modify or delete his offers which will modify the database of these offers.

Inputs: Filled fields needed to create or modify an offer, simple click to delete an offer.

Source: Wep application

Outputs: Confirmations

Destination: Server

Action: Add, modify or delete entry in the offer database

Non functional requirements: None

Pre-condition: Internet connection, the user must be log in and have his email verified.

Post-condition: None

3.3 Browse offers and ask for appointment

Function: Display offers and allow users to ask for an appointment

Description: The offers of the database must be display and every users can ask for an offer with the author of the offer

Inputs: Clicks on links, text for a message to the authors.

Source: Wep application

Outputs: Display of offers

Destination: Web application


  • Will go through the database and display the offers on the main page.
  • Send emails for appointments confirmation

Non functional requirements: None

Pre-condition: Internet connection, the user must be log in and have his email verified to ask for appointments.

Post-condition: None

4. Product evolution

The features that won't be finished can then be implemented by someone else. The web application is currently working even without some features, someone else can just add them.

5. Appendices

6. Index