Logiciels requis

Les exigences logicielles sont la description des caractéristiques et des fonctionnalités du système cible. Les exigences traduisent les attentes des utilisateurs vis-à-vis du produit logiciel. Les exigences peuvent être évidentes ou cachées, connues ou inconnues, attendues ou inattendues du point de vue du client.

Ingénierie des exigences

Le processus pour rassembler les exigences logicielles du client, les analyser et les documenter est appelé ingénierie des exigences.

Le but de l'ingénierie des exigences est de développer et de maintenir un document sophistiqué et descriptif sur la spécification des exigences système.

Processus d'ingénierie des exigences

Il s'agit d'un processus en quatre étapes, qui comprend:

  • Étude de faisabilité
  • Rassemblement des exigences
  • Spécification des exigences logicielles
  • Validation des exigences logicielles

Voyons brièvement le processus -

Étude de faisabilité

Lorsque le client s'approche de l'organisation pour obtenir le produit souhaité développé, il se fait une idée approximative de toutes les fonctions que le logiciel doit exécuter et de toutes les fonctionnalités attendues du logiciel.

En se référant à ces informations, les analystes effectuent une étude détaillée pour savoir si le système souhaité et ses fonctionnalités sont réalisables à développer.

Cette étude de faisabilité est centrée sur l'objectif de l'organisation. Cette étude analyse si le produit logiciel peut être concrètement matérialisé en termes de mise en œuvre, de contribution du projet à l'organisation, de contraintes de coût et selon les valeurs et objectifs de l'organisation. Il explore les aspects techniques du projet et du produit tels que la convivialité, la maintenabilité, la productivité et la capacité d'intégration.

Le résultat de cette phase devrait être un rapport d'étude de faisabilité qui devrait contenir des commentaires et des recommandations adéquats pour la direction quant à savoir si le projet doit être entrepris ou non.

Rassemblement des exigences

Si le rapport de faisabilité est positif pour entreprendre le projet, la phase suivante commence par la collecte des exigences de l'utilisateur. Les analystes et les ingénieurs communiquent avec le client et les utilisateurs finaux pour connaître leurs idées sur ce que le logiciel doit fournir et les fonctionnalités qu'ils souhaitent inclure dans le logiciel.

Spécification des exigences logicielles

SRS est un document créé par un analyste système après que les exigences ont été collectées auprès de diverses parties prenantes.

SRS définit comment le logiciel prévu interagira avec le matériel, les interfaces externes, la vitesse de fonctionnement, le temps de réponse du système, la portabilité du logiciel sur diverses plates-formes, la maintenabilité, la vitesse de récupération après un crash, la sécurité, la qualité, les limitations, etc.

Les exigences reçues du client sont écrites en langage naturel. Il est de la responsabilité de l'analyste système de documenter les exigences dans un langage technique afin qu'elles puissent être comprises et utiles par l'équipe de développement logiciel.

SRS devrait proposer les fonctionnalités suivantes:

  • Les exigences des utilisateurs sont exprimées en langage naturel.
  • Les exigences techniques sont exprimées dans un langage structuré, utilisé à l'intérieur de l'organisation.
  • La description de la conception doit être écrite en pseudo-code.
  • Format des formulaires et des impressions d'écran GUI.
  • Notations conditionnelles et mathématiques pour les DFD, etc.

Validation des exigences logicielles

Une fois les spécifications des exigences développées, les exigences mentionnées dans ce document sont validées. L'utilisateur peut demander une solution illégale et peu pratique ou des experts peuvent interpréter les exigences de manière incorrecte. Cela se traduit par une énorme augmentation du coût s'il n'est pas étouffé dans l'œuf. Les exigences peuvent être vérifiées par rapport aux conditions suivantes -

  • S'ils peuvent être mis en œuvre pratiquement
  • S'ils sont valides et selon la fonctionnalité et le domaine du logiciel
  • S'il y a des ambiguïtés
  • S'ils sont complets
  • S'ils peuvent être démontrés

Processus d'élicitation des besoins

Le processus d'élicitation des exigences peut être décrit à l'aide du diagramme suivant:

  • Requirements gathering - Les développeurs discutent avec le client et les utilisateurs finaux et connaissent leurs attentes vis-à-vis du logiciel.
  • Organizing Requirements - Les développeurs hiérarchisent et organisent les exigences par ordre d'importance, d'urgence et de commodité.

  • Negotiation & discussion - Si les exigences sont ambiguës ou s'il y a des conflits dans les exigences des différentes parties prenantes, si elles le sont, elles sont alors négociées et discutées avec les parties prenantes. Les exigences peuvent alors être hiérarchisées et raisonnablement compromises.

    Les exigences proviennent de diverses parties prenantes. Pour supprimer l'ambiguïté et les conflits, ils sont discutés pour plus de clarté et d'exactitude. Les exigences irréalistes sont raisonnablement compromises.

  • Documentation - Toutes les exigences formelles et informelles, fonctionnelles et non fonctionnelles sont documentées et mises à disposition pour le traitement de la phase suivante.

Techniques d'élicitation des exigences

L'élicitation des exigences est le processus qui permet de connaître les exigences d'un système logiciel prévu en communiquant avec le client, les utilisateurs finaux, les utilisateurs du système et d'autres personnes qui ont un intérêt dans le développement du système logiciel.

Il existe différentes manières de découvrir les exigences

Entrevues

Les entretiens sont un moyen efficace pour recueillir les exigences. L'organisation peut mener plusieurs types d'entretiens tels que:

  • Entretiens structurés (fermés), où chaque information à recueillir est décidée à l'avance, ils suivent fermement le modèle et le sujet de la discussion.
  • Entretiens non structurés (ouverts), où les informations à recueillir ne sont pas décidées à l'avance, plus flexibles et moins biaisés.
  • Entretiens oraux
  • Entretiens écrits
  • Entretiens individuels qui ont lieu entre deux personnes de l'autre côté de la table.
  • Entretiens de groupe qui ont lieu entre des groupes de participants. Ils aident à découvrir toute exigence manquante car de nombreuses personnes sont impliquées.

Enquêtes

L'organisation peut mener des enquêtes auprès de diverses parties prenantes en interrogeant leurs attentes et leurs exigences par rapport au système à venir.

Questionnaires

Un document avec un ensemble prédéfini de questions objectives et des options respectives est remis à toutes les parties prenantes pour y répondre, qui sont collectées et compilées.

Une lacune de cette technique est que si une option pour un problème n'est pas mentionnée dans le questionnaire, le problème peut être laissé sans surveillance.

Analyse des tâches

Une équipe d'ingénieurs et de développeurs peut analyser l'opération pour laquelle le nouveau système est requis. Si le client dispose déjà d'un logiciel pour effectuer certaines opérations, il est étudié et les exigences du système proposé sont collectées.

Analyse de domaine

Chaque logiciel appartient à une catégorie de domaine. Les experts du domaine peuvent être d'une grande aide pour analyser les exigences générales et spécifiques.

Réflexion

Un débat informel a lieu entre les différentes parties prenantes et toutes leurs contributions sont enregistrées pour une analyse plus approfondie des besoins.

Prototypage

Le prototypage consiste à créer une interface utilisateur sans ajouter de fonctionnalités détaillées permettant à l'utilisateur d'interpréter les fonctionnalités du produit logiciel prévu. Cela permet de donner une meilleure idée des besoins. S'il n'y a pas de logiciel installé chez le client pour référence du développeur et que le client n'est pas conscient de ses propres exigences, le développeur crée un prototype basé sur les exigences initialement mentionnées. Le prototype est montré au client et les commentaires sont notés. Les commentaires des clients servent d'entrée pour la collecte des exigences.

Observation

Une équipe d'experts visite l'organisation ou le lieu de travail du client. Ils observent le fonctionnement réel des systèmes installés existants. Ils observent le flux de travail à la fin du client et comment les problèmes d'exécution sont traités. L'équipe elle-même tire quelques conclusions qui aident à former les exigences attendues du logiciel.

Caractéristiques des exigences logicielles

La collecte des exigences logicielles est la base de tout le projet de développement logiciel. Par conséquent, ils doivent être clairs, corrects et bien définis.

Une spécification complète des exigences logicielles doit être:

  • Clear
  • Correct
  • Consistent
  • Coherent
  • Comprehensible
  • Modifiable
  • Verifiable
  • Prioritized
  • Unambiguous
  • Traceable
  • Source crédible

Logiciels requis

Nous devrions essayer de comprendre quel type d'exigences peuvent survenir lors de la phase d'élicitation des exigences et quels types d'exigences sont attendues du système logiciel.

Les exigences logicielles générales doivent être classées en deux catégories:

Exigences fonctionnelles

Les exigences, qui sont liées à l'aspect fonctionnel du logiciel, entrent dans cette catégorie.

Ils définissent les fonctions et fonctionnalités à l'intérieur et à partir du système logiciel.

Exemples -

  • Option de recherche donnée à l'utilisateur pour rechercher à partir de diverses factures.
  • L'utilisateur doit pouvoir envoyer n'importe quel rapport à la direction.
  • Les utilisateurs peuvent être divisés en groupes et les groupes peuvent recevoir des droits distincts.
  • Doit se conformer aux règles commerciales et aux fonctions administratives.
  • Le logiciel est développé en gardant la compatibilité descendante intacte.

Prérogatives non fonctionnelles

Les exigences, qui ne sont pas liées à l'aspect fonctionnel du logiciel, entrent dans cette catégorie. Ce sont des caractéristiques implicites ou attendues du logiciel, dont les utilisateurs font l'hypothèse.

Les exigences non fonctionnelles comprennent -

  • Security
  • Logging
  • Storage
  • Configuration
  • Performance
  • Cost
  • Interoperability
  • Flexibility
  • Reprise après sinistre
  • Accessibility

Les exigences sont classées logiquement comme

  • Must Have : Un logiciel ne peut pas être dit opérationnel sans eux.
  • Should have : Amélioration des fonctionnalités du logiciel.
  • Could have : Le logiciel peut toujours fonctionner correctement avec ces exigences.
  • Wish list : Ces exigences ne correspondent à aucun objectif du logiciel.

Lors du développement d'un logiciel, «doit avoir» doit être implémenté, «devrait avoir» est un sujet de débat avec les parties prenantes et de négation, alors que «pourrait avoir» et «liste de souhaits» peuvent être conservés pour les mises à jour logicielles.

Exigences de l'interface utilisateur

L'interface utilisateur est une partie importante de tout logiciel, matériel ou système hybride. Un logiciel est largement accepté s'il est -

  • facile à utiliser
  • réponse rapide
  • gérer efficacement les erreurs opérationnelles
  • fournissant une interface utilisateur simple mais cohérente

L'acceptation de l'utilisateur dépend principalement de la manière dont l'utilisateur peut utiliser le logiciel. L'interface utilisateur est le seul moyen pour les utilisateurs de percevoir le système. Un système logiciel performant doit également être équipé d'une interface utilisateur attrayante, claire, cohérente et réactive. Sinon, les fonctionnalités du système logiciel ne peuvent pas être utilisées de manière pratique. Un système est dit bon s'il fournit les moyens de l'utiliser efficacement. Les exigences d'interface utilisateur sont brièvement mentionnées ci-dessous -

  • Présentation du contenu
  • Navigation facile
  • Interface simple
  • Responsive
  • Éléments d'interface cohérents
  • Mécanisme de rétroaction
  • Paramètres par défaut
  • Mise en page ciblée
  • Utilisation stratégique de la couleur et de la texture.
  • Fournir des informations d'aide
  • Approche centrée sur l'utilisateur
  • Paramètres d'affichage basés sur les groupes.

Analyste système logiciel

L'analyste système dans une organisation informatique est une personne qui analyse les exigences du système proposé et s'assure que les exigences sont conçues et documentées correctement et correctement. Le rôle d'un analyste commence pendant la phase d'analyse logicielle du SDLC. Il est de la responsabilité de l'analyste de s'assurer que le logiciel développé répond aux exigences du client.

Les analystes système ont les responsabilités suivantes:

  • Analyser et comprendre les exigences du logiciel prévu
  • Comprendre comment le projet contribuera aux objectifs de l'organisation
  • Identifier les sources d'exigence
  • Validation de l'exigence
  • Élaborer et mettre en œuvre un plan de gestion des exigences
  • Documentation des exigences commerciales, techniques, de processus et de produit
  • Coordination avec les clients pour hiérarchiser les exigences et éliminer les ambiguïtés
  • Finaliser les critères d'acceptation avec le client et les autres parties prenantes

Métriques et mesures du logiciel

Les mesures logicielles peuvent être comprises comme un processus de quantification et de symbolisation de divers attributs et aspects d'un logiciel.

Les métriques logicielles fournissent des mesures pour divers aspects du processus logiciel et du produit logiciel.

Les mesures logicielles sont une exigence fondamentale du génie logiciel. Ils aident non seulement à contrôler le processus de développement logiciel, mais aussi à maintenir la qualité du produit final excellente.

Selon Tom DeMarco, un (ingénieur logiciel), "Vous ne pouvez pas contrôler ce que vous ne pouvez pas mesurer." Selon ses propos, l’importance des mesures logicielles est très claire.

Voyons quelques métriques logicielles:

  • Size Metrics - LOC (Lines of Code), principalement calculé en milliers de lignes de code source livrées, noté KLOC.

    Le nombre de points de fonction mesure la fonctionnalité fournie par le logiciel. Le nombre de points de fonction définit la taille de l'aspect fonctionnel du logiciel.

  • Complexity Metrics - La complexité cyclomatique de McCabe quantifie la limite supérieure du nombre de chemins indépendants dans un programme, qui est perçue comme la complexité du programme ou de ses modules. Il est représenté en termes de concepts de théorie des graphes en utilisant un graphe de flux de contrôle.

  • Quality Metrics - Les défauts, leurs types et causes, leurs conséquences, leur intensité et leurs implications définissent la qualité du produit.

    Le nombre de défauts constatés dans le processus de développement et le nombre de défauts signalés par le client après l'installation ou la livraison du produit chez le client définissent la qualité du produit.

  • Process Metrics - Dans les différentes phases du SDLC, les méthodes et outils utilisés, les standards de l'entreprise et les performances de développement sont des métriques de processus logiciels.
  • Resource Metrics - L'effort, le temps et les diverses ressources utilisées représentent des mesures pour la mesure des ressources.