Exigences logicielles

Les exigences logicielles sont la description des caractéristiques et des fonctionnalités du système cible. Les exigences transmettent 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 visant à recueillir les exigences logicielles du client, à les analyser et à les documenter est connu sous le nom d’ingénierie des exigences.

Le but de l’ingénierie des exigences est de développer et de maintenir un document sophistiqué et descriptif ‘Spécification des exigences du système’.

Processus d’ingénierie des exigences

C’est un processus en quatre étapes, qui comprend –

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

Voyons brièvement le processus –

Étude de faisabilité

Lorsque le client approche l’organisation pour obtenir le produit souhaité développé, il arrive avec 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 font une étude détaillée pour savoir si le système souhaité et ses fonctionnalités sont réalisables.

Cette étude de faisabilité est axée sur l’objectif de l’organisation. Cette étude analyse si le produit logiciel peut être matérialisé de manière pratique en termes de mise en œuvre, de contribution du projet à l’organisation, de contraintes de coûts et selon les valeurs et les objectifs de l’organisation. Elle explore les aspects techniques du projet et du produit tels que la facilité d’utilisation, la maintenabilité, la productivité et la capacité d’intégration.

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

Recueil des exigences

Si le rapport de faisabilité est positif pour entreprendre le projet, la phase suivante commence par le recueil 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 devrait fournir et quelles fonctionnalités ils veulent que le logiciel inclue.

Spécification des exigences du logiciel

Le SRS est un document créé par l’analyste système après la collecte des exigences auprès des différentes parties prenantes.

Le SRS définit la façon dont 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 plateformes, la maintenabilité, la vitesse de récupération après un plantage, la sécurité, la qualité, les limites, 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 en langage technique afin qu’elles puissent être comprises et utiles par l’équipe de développement du logiciel.

Le SRS doit présenter les caractéristiques suivantes :

• Les exigences des utilisateurs sont exprimées en langage naturel.
• Les exigences techniques sont exprimées dans un langage structuré, qui est utilisé à l’intérieur de l’organisation.
• La description de la conception doit être écrite en Pseudo code.
• Format of Forms and GUI screen prints.
• Conditional and mathematical notations for DFDs etc.

Software Requirement Validation

After requirement specifications are developed, the requirements mentioned in this document are validated. User might ask for illegal, impractical solution or experts may interpret the requirements incorrectly. This results in huge increase in cost if not nipped in the bud. Requirements can be checked against following conditions –

• If they can be practically implemented
• If they are valid and as per functionality and domain of software
• If there are any ambiguities
• If they are complete
• If they can be demonstrated

Requirement Elicitation Process

Requirement elicitation process can be depicted using the folloiwng diagram:

• Recueil des exigences – Les développeurs discutent avec le client et les utilisateurs finaux et connaissent leurs attentes vis-à-vis du logiciel.
• Organisation des exigences – Les développeurs hiérarchisent et classent les exigences par ordre d’importance, d’urgence et de commodité.
• Négociation & discussion – Si les exigences sont ambiguës ou s’il y a quelques conflits dans les exigences des différentes parties prenantes, si c’est le cas, elles sont alors négociées et discutées avec les parties prenantes. Les exigences peuvent alors être hiérarchisées et faire l’objet d’un compromis raisonnable.

  Les exigences proviennent de diverses parties prenantes. Pour lever l’ambiguïté et les conflits, elles sont discutées pour être claires et correctes. Les exigences irréalistes sont compromises raisonnablement.

• Documentation – Toutes les exigences formelles & 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 visant à découvrir 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 façons de découvrir les exigences

Entretiens

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

• Les entretiens structurés (fermés), où chaque information à recueillir est décidée à l’avance, ils suivent fermement le modèle et la matière de la discussion.
• Les 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 en tête-à-tête qui se déroulent entre deux personnes en face de la table.
• Entretiens de groupe qui se déroulent entre des groupes de participants. Ils aident à découvrir toute exigence manquante car de nombreuses personnes sont impliquées.

Sondages

L’organisation peut mener des sondages auprès de diverses parties prenantes en les interrogeant sur leurs attentes et exigences du système à venir.

Questionnaires

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

Un inconvénient de cette technique est que, si une option pour une certaine question n’est pas mentionnée dans le questionnaire, la question pourrait être laissée sans réponse.

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 nécessaire. Si le client possède déjà un logiciel pour effectuer une certaine opération, il est étudié et les exigences du système proposé sont recueillies.

Analyse de domaine

Tout logiciel entre dans une certaine catégorie de domaine. Les personnes expertes dans le domaine peuvent être d’une grande aide pour analyser les exigences générales et spécifiques.

Brainstorming

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

Prototypage

Le prototypage consiste à construire une interface utilisateur sans ajouter de fonctionnalité détaillée pour que l’utilisateur puisse interpréter les caractéristiques du produit logiciel prévu. Il permet de donner une meilleure idée des exigences. S’il n’y a pas de logiciel installé chez le client pour la référence du développeur et que le client ne connaît pas ses propres exigences, le développeur crée un prototype basé sur les exigences initialement mentionnées. Le prototype est montré au client et son retour est noté. Le feedback du client sert 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 chez le client et la façon dont les problèmes d’exécution sont traités. The team itself draws some conclusions which aid to form requirements expected from the software.

Software Requirements Characteristics

Gathering software requirements is the foundation of the entire software development project. Hence they must be clear, correct and well-defined.

A complete Software Requirement Specifications must be:

• Clear
• Correct
• Consistent
• Coherent
• Comprehensible
• Modifiable
• Verifiable
• Prioritized
• Unambiguous
• Traceable
• Credible source

Software Requirements

We should try to understand what sort of requirements may arise in the requirement elicitation phase and what kinds of requirements are expected from the software system.

Grandement, les exigences logicielles 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.

Elles définissent les fonctions et les fonctionnalités au sein 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 par mail n’importe quel rapport à la direction.
• Les utilisateurs peuvent être divisés en groupes et des droits distincts peuvent être attribués aux groupes.
• Doit être conforme aux règles de gestion et aux fonctions administratives.
• Le logiciel est développé en gardant la compatibilité descendante intacte.

Exigences non fonctionnelles

Les exigences, qui ne sont pas liées à l’aspect fonctionnel du logiciel, entrent dans cette catégorie. Il s’agit de 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
• Disaster recovery
• Accessibility

Requirements are categorized logically as

• Must Have : Software cannot be said operational without them.
• Should have : Enhancing the functionality of software.
• Could have : Software can still properly function with these requirements.
• Wish list : These requirements do not map to any objectives of software.

While developing software, ‘Must have’ must be implemented, ‘Should have’ is a matter of debate with stakeholders and negation, whereas ‘could have’ and ‘wish list’ can be kept for software updates.

User Interface requirements

UI is an important part of any software or hardware or hybrid system. A software is widely accepted if it is –

• easy to operate
• quick in response
• effectively handling operational errors
• providing simple yet consistent user interface

User acceptance majorly depends upon how user can use the software. UI is the only way for users to perceive the system. A well performing software system must also be equipped with attractive, clear, consistent and responsive user interface. Otherwise the functionalities of software system can not be used in convenient way. A system is said be good if it provides means to use it efficiently. User interface requirements are briefly mentioned below –

• Content presentation
• Easy Navigation
• Simple interface
• Responsive
• Consistent UI elements
• Feedback mechanism
• Default settings
• Purposeful layout
• Strategical use of color and texture.
• Fournir des informations d’aide
• Approche centrée sur l’utilisateur
• Paramètres d’affichage basés sur les groupes.

Analyste de système logiciel

L’analyste de système dans une organisation informatique est une personne, qui analyse l’exigence du système proposé et s’assure que les exigences sont conçues et documentées 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’exigences
• Validation des exigences
• Développer et mettre en œuvre un plan de gestion des exigences
• Documentation des exigences commerciales, techniques, exigences de processus et de produit
• Coordination avec les clients pour prioriser les exigences et lever et ambiguïté
• Finalisation des critères d’acceptation avec le client et les autres parties prenantes

Métriques et mesures logicielles

Les mesures logicielles peuvent être comprises comme un processus de quantification et de symbolisation de divers attributs et aspects des logiciels.

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

Les mesures logicielles sont une exigence fondamentale de l’ingénierie logicielle. Elles aident non seulement à contrôler le processus de développement du logiciel mais aussi à garder une excellente qualité du produit ultime.

Selon Tom DeMarco, un (ingénieur logiciel), « Vous ne pouvez pas contrôler ce que vous ne pouvez pas mesurer. » Par son propos, il est très clair à quel point les mesures logicielles sont importantes.

Voyons quelques mesures logicielles :

• Mesures de taille – LOC (Lines of Code), le plus souvent calculé en milliers de lignes de code source livrées, dénoté comme KLOC.

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

• Métrique de complexité – La complexité cyclomatique de McCabe quantifie la limite supérieure du nombre de chemins indépendants dans un programme, ce qui est perçu comme une complexité du programme ou de ses modules. Elle est représentée en termes de concepts de la théorie des graphes en utilisant le graphe de flux de contrôle.

• Métriques de qualité – Les défauts, leurs types et leurs causes, la conséquence, l’intensité de la gravité et leurs implications définissent la qualité du produit.

  The number of defects found in development process and number of defects reported by the client after the product is installed or delivered at client-end, define quality of product.

• Process Metrics – In various phases of SDLC, the methods and tools used, the company standards and the performance of development are software process metrics.
• Resource Metrics – Effort, time and various resources used, represents metrics for resource measurement.