0% ont trouvé ce document utile (0 vote)
24 vues11 pages

Format ERS

Ce document fournit une spécification des exigences logicielles pour un projet. Il comprend des sections pour introduire l'objectif et le périmètre, définir des termes clés, lister des documents connexes et décrire les exigences fonctionnelles et non fonctionnelles. Il inclut également une section pour des cas d'utilisation avec des résumés et des diagrammes. Le but est de rassembler toutes les exigences du système afin de fournir une description complète avant le développement du logiciel.

Transféré par

ScribdTranslations
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd
0% ont trouvé ce document utile (0 vote)
24 vues11 pages

Format ERS

Ce document fournit une spécification des exigences logicielles pour un projet. Il comprend des sections pour introduire l'objectif et le périmètre, définir des termes clés, lister des documents connexes et décrire les exigences fonctionnelles et non fonctionnelles. Il inclut également une section pour des cas d'utilisation avec des résumés et des diagrammes. Le but est de rassembler toutes les exigences du système afin de fournir une description complète avant le développement du logiciel.

Transféré par

ScribdTranslations
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd

Spécification des exigences du logiciel <Nom du projet> <x.y.

z>

Spécification des Exigences du Logiciel


<Nom du Projet
Version : <x.y.z>

Description du processus : L'objectif de ce document est de rassembler tous les


exigences du système, cela décrit les fonctions du système, les exigences non fonctionnelles,
caractéristiques du design, et d'autres éléments nécessaires pour fournir une description
complète et compréhensive des exigences pour le logiciel à développer.

1
Spécification des Exigences du Logiciel <Nom du Projet> <x.y.z>

Historique des révisions


Version Date Auteur Description
<x.y.z> <jj/mm/aa> nombre especificaciones

2
Spécification des Exigences du Logiciel <Nom du Projet> <x.y.z>

3
Spécification des exigences du logiciel <Nom du projet> Version : <x.y.z>

4
Spécification des exigences logicielles <Nom du Projet> <x.y.z>

Indice du Contenu

Spécification des exigences du logiciel...................................................................................................................4


1. Introduction
1.1 Objectif
1.2 Portée
1.3 Définition Acronymes et Abbréviations...........................................................................................................4
Documents relatifs.................................................................................................................................4
1.5 Vision Général
2. Exigences Fonctionnels.......................................................................................................................................4
3. Exigences Non fonctionnels
3.1 Utilisabilité.............................................................................................................................................................5
3.2 Fiabilité
3.3 Sécurité.............................................................................................................................................................5
3.4 Performance...........................................................................................................................................................5
3.5 Entretien y Mise à jour...........................................................................................................................5
3.6 Portabilité y Opérabilité.............................................................................................................................6
3.7 Limitation de Design...........................................................................................................................................6
3.8 Exigences de Documentation en Ligne et de Systèmes d'Aide.............................................................6
3.9 Interfaces
[Link] d'utilisation
4.1 Résumé et Acteurs..................................................................................................................................................7
4.2 Spécifications des Cas d'Utilisation..........................................................................................................................7
4.3 Diagramme

5
Spécification des Exigences du Logiciel <Nom du Projet> <x.y.z>

Spécification des Exigences du Logiciel


1. Introduction

1.1 Objectif
Mentionner l'objectif de ce document (cela devrait être relativement court).

1.2 Portée
Décrire la portée, mentionner les projets associés et déterminer ce qui est affecté par cela
document

1.3 Définition, Acronymes et Abréviations


Dans cette section, il faut montrer les définitions de tous les termes, acronymes et abréviations
requis nécessaires pour comprendre ce document, celles-ci doivent également être reflétées dans le glossaire du
système.

1.4 Documents connexes


Pour pouvoir visualiser les références à d'autres documents, il faut remplir le tableau qui est affiché.
À suivre :

Titre Date Organisation Identifiant du


document
titre <jj/mm/aa> nombre Id documento

Vue d'ensemble
Décrire le contenu de la Spécification des Exigences Fonctionnelles du Logiciel et expliquer
organisation de ce document.

2. Exigences Fonctionnelles
Les exigences fonctionnelles d'un système décrivent la fonctionnalité ou les services attendus.
que ce dernier fournira. Dans cette section, il faut décrire ce que le système devra faire, les facteurs
qui affectent le produit et satisfont les exigences. Il faut remplir le tableau suivant :

Nom de l'exigence : Mettre le nom du besoin fonctionnel.

Identification du besoin : Identification de l'exigence fonctionnelle (avec un numéro ou un)


ensemble de caractères qui doit être reflété dans la section de
définition, acronymes et abréviations.
Caractéristiques : Cette caractéristique a été précédemment définie dans le document
Vision du système. Ces caractéristiques sont celles qui génèrent
chacun des requis qui seront exprimés dans ce tableau.

6
Spécification des Exigences du Logiciel <Nom du Projet> <x.y.z>

Ici, une description de l'exigence fonctionnelle doit être effectuée. Des informations doivent être fournies.
suffisamment de manière à servir d'aide pour le développeur du système. Tout
La représentation graphique doit être annexée dans cette section.
Priorité Haute / Haute Moyenne / Moyenne / Moyenne
Baja / BajaLa priorité est :<placer l'une des
options

7
Spécification des exigences du logiciel <Nom du projet> <x.y.z>

3. Exigences Non Fonctionnelles


Décrivez les exigences non fonctionnelles pour ce document. Les exigences non fonctionnelles
ils ont à voir avec les caractéristiques qui, d'une manière ou d'une autre, peuvent limiter le système, comme : le
performance (en temps et espace)
disponibilité de l'équipement), maintenance, sécurité, portabilité, normes, etc.

3.1 Utilisabilité
Dans cette section, tous les exigences qui affectent l'utilisabilité doivent être incluses. Cela doit
inclure : le temps qu'un utilisateur mettra à apprendre à utiliser le système et cela pourrait être expliqué par
À quelle vitesse l'apprentissage doit-il être, les temps mesurables des tâches pour les tâches typiques et les
exigences pour se conformer aux normes.

3.2 Fiabilité
Ici, les exigences de fiabilité du système doivent être détaillées. Décrivez les caractéristiques.
de fiabilité expliqué la possibilité pour le système d'effectuer les fonctions pour lesquelles il a été conçu
conçu sans présenter de défauts. Parmi ces exigences, on peut mentionner des caractéristiques telles que la
disponibilité, le pourcentage de pannes maximum, etc.

3.3 Sécurité
Ici, les exigences de sécurité du système doivent être détaillées. Cela inclut si l'accès au
le système sera contrôlé par des noms d'utilisateur et des mots de passe, que seuls les utilisateurs avec
les privilèges d'administrateur pourront accéder aux fonctions administratives et les utilisateurs normaux
ils ne pourront pas.

3.4 Performance
Dans cette section, les caractéristiques de performance du système doivent être reflétées. Il faut
especificar: el tiempo de respuesta para una transacción (promedio), capacidad (número de clientes
et transactions), performance du traitement (Ex. transactions par seconde) et lorsque le
le système s'est dégradé, quel est le mode de fonctionnement acceptable.

3.5 Maintenance et Mise à Jour


Dans ce paragraphe, les exigences de maintenance et de mise à jour doivent être reflétées.
la capacité de maintenance est la compétence que l'on a pour apporter des modifications au produit dans le
le temps et la capacité de mise à jour est la compétence qui permet de livrer les versions de
produit à bas coût pour les clients avec un minimum de temps de téléchargement. Une caractéristique clé
pour soutenir cet objectif, il y a le téléchargement automatique de correctifs ou de mises à jour
de l'équipe de l'utilisateur final. Nous devons également utiliser des formats pour les fichiers de données qui incluent
des métadonnées suffisantes pour nous permettre de transformer en toute sécurité les informations existantes du
utilisateur pendant une mise à jour.

3.6 Portabilité et Opérabilité


Spécifier les exigences de soutenabilité et d'opérabilité du système. La soutenabilité la
habilité à fournir un support technique efficace et à bon prix et l'opérabilité est la capacité que
il doit héberger et faire fonctionner le logiciel en tant qu'ASP (Fournisseur de Services d'Applications).

8
Spécification des exigences logicielles <Nom du Projet> <x.y.z>

3.7 Limitation de Design


Dans cette section, toutes les limitations de conception du système construit doivent être indiquées.
Cela signifie les décisions de conception qui ont été attribuées de manière obligatoire. Par exemple :
langages de logiciel, exigences du processus logiciel, utilisation des outils de développement
composants achetés, etc.

3.8 Exigences de Documentation en Ligne et de Systèmes d'Aide


Dans le cas où cela existerait, les exigences doivent être décrites pour la documentation en ligne du
utilisateur, systèmes d'aide, aide concernant les avis, etc.

3.9 Interfaces
Dans ce chapitre, les interfaces que l'application doit prendre en charge sont définies, telles que : les interfaces
de l'utilisateur, interfaces de logiciel, interfaces de. Afin que le logiciel puisse être créé et testé
contre les exigences de l'interface, elle doit inclure la spécificité adéquate des protocoles,
ports, adresses logiques, etc.
S'il y a lieu, il est conseillé de faire référence aux normes de l'application
ocorporatifs.

3.9.1 Interfaces utilisateur


Décrire les interfaces utilisateur qui seront exécutées par le logiciel.

3.9.2 Interfaces de logiciel


Il faut décrire les interfaces logicielles vers d'autres composants du système. Elles peuvent être :
composants achetés, réutilisés ou réalisés pour des sous-systèmes hors du périmètre de
ce document.

3.9.3 Interfaces de Hardware


Ici, des commentaires sur toute interface matérielle qui doit être prise en charge sont décrits.
le logiciel, cela inclut : comportement, structure logique, etc.

3.9.4 Interfaces de Communications


Il faut définir les interfaces de communication avec les autres systèmes ou dispositifs tels que :
réseaux LAN et dispositifs série distants

[Link] d'utilisation

Résumé et Acteurs

9
Spécification des exigences logicielles <Nom du Projet> <x.y.z>

Cas d'utilisation Acteurs participants


Réaliser un résumé des cas d'utilisation Identifier les acteurs qui interviennent.

4.2 Spécifications des Cas d'Utilisation


Dans cette section, la spécification complète de chaque cas d'utilisation doit être recueillie. Cela inclut les champs :
nom
d'autres. Il faut élaborer un tableau de spécifications pour chaque cas d'utilisation.

Cas d'utilisation

Nombre Mettre le nom du cas d'utilisation.


Description Décrire la responsabilité et l'objectif du cas
de usage.
Exigence : Identifier les exigences qui couvrent ceci
cas d'utilisation.

Précondition : Cela a à voir avec les conditions dans lesquelles cela doit
être le système pour que le cas d'utilisation s'exécute.
Exemple : enregistrement et authentification du client.

Flux normal :
Dans le flux des cas d'utilisation, il est décrit ce que fait l'acteur et ce que fait le système en réponse.
Il s'exprime sous la forme d'un dialogue entre l'acteur et le système. Le flux de base du cas d'utilisation décrit
ce qui se passe à l'intérieur du système. Ce flux peut être représenté sous forme graphique. Il faut
prendre en compte que le flux d'un cas d'utilisation devrait avoir entre cinq et sept étapes
environ.

Acteur Système
Décrire chaque étape du flux réalisé par Décrire chaque étape du flux réalisé par quelque
un acteur ressource du système.2.4. 6.

Flux Alterné :
le flux alternatif reflète le comportement alternatif en raison des irrégularités qui se produisent dans
le flux d'événements normal. Ils peuvent être aussi longs que nécessaire pour décrire les événements
associés au comportement alternatif.

Acteur Système
Décrire chaque étape alternative du flux Décrire chaque étape alternative du flux réalisé par
réalisé par un acteur.1.1 2.1 3.1 quelque ressource du système.1.2 2.2 3.2

10
Spécification des exigences du logiciel <Nom du projet> Version : <x.y.z>

Cas d'utilisation

Poscondition Lister les conditions dans lesquelles se trouve le


système après avoir exécuté le système.
Exigences Spéciales Nommer et décrire toute exigence qui ne
a été englobé par le flux normal ou les alternés.
Points d'Extension : Il faut mentionner et décrire les points dans les
quel flux d'événements s'étend à d'autres
cas d'utilisation.

Remarque : Chaque étape du flux des événements doit être numérotée, en maintenant une séquence entre
les étapes du flux réalisées par un acteur et les étapes du flux réalisées par une ressource
système.

4.3 Diagramme
Dans cette section, les diagrammes de cas d'utilisation initiaux du système doivent être reflétés.
Les diagrammes de cas d'utilisation sont une représentation graphique d'une partie ou de tous les acteurs et
cas d'utilisation du système, y compris ses interactions et ceux-ci peuvent être développés en
un outil de modélisation visuelle. La construction du Diagramme des Cas d'Utilisation commence
avec l'élaboration du Diagramme de Cas d'Utilisation Initial, le raffinement de celui-ci peut
se contemplant dans des itérations ultérieures.

11

Vous aimerez peut-être aussi