Format ERS
Format ERS
z>
1
Spécification des Exigences du Logiciel <Nom du Projet> <x.y.z>
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
5
Spécification des Exigences du Logiciel <Nom du Projet> <x.y.z>
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
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 :
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.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.
8
Spécification des exigences logicielles <Nom du Projet> <x.y.z>
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.
[Link] d'utilisation
Résumé et Acteurs
9
Spécification des exigences logicielles <Nom du Projet> <x.y.z>
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
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