Pourquoi les exigences sont-elles importantes en génie logiciel ?

Dans cet article, nous examinons l'importance des exigences dans le développement de logiciels et les raisons pour lesquelles négliger l'étape des exigences n'est pas une bonne idée lors de la création d'une application.

" Un logiciel de travail sur une documentation complète. " Ceci fait partie du Manifeste Agile.

À première vue, cette déclaration peut sembler impliquer que les exigences sont sans conséquence et ne méritent pas le temps. Certains développeurs et leurs clients renoncent à une documentation appropriée. Mais c'est une erreur.

Commençons par une petite explication des exigences en termes de développement logiciel.

Quelles sont les exigences en matière de développement d'applications ?

Ce n'est pas comme si la définition des exigences change de manière significative lorsqu'elle est appliquée au développement de logiciels. Les exigences spécifient simplement quelles fonctionnalités un produit doit inclure et comment ces fonctionnalités doivent fonctionner. La façon dont vous les abordez est ce qui est important.

La collecte et l'analyse des exigences sont l'une des premières étapes du processus de développement logiciel dans les méthodologies Agile et Waterfall. Au cours de la phase des exigences de la phase de validation de l'idée, un accord doit être conclu entre le client et le développeur sur ce que le produit final doit faire exactement et comment. Les exigences en matière de développement d'applications sont généralement assez détaillées.

Comment définir les exigences logicielles

Il peut y avoir plusieurs types d'exigences dans le développement de logiciels.

Besoins de l'entreprise

Pourquoi le client a-t-il besoin de l'application ? Au premier coup d'œil, ces informations peuvent apparaître inutiles voire redondantes. Après tout, vous avez un client qui veut vous payer pour créer une application. Pourquoi devriez-vous vous soucier de leurs raisons ?

Eh bien, si vous êtes fier de ce que vous faites et que vous vous efforcez de créer des produits de qualité, vous devriez vous soucier du pourquoi autant que du quoi et du comment.

L'importance des exigences métier est qu'elles fournissent une vision de l'objectif final. Avec l'objectif en vue, les développeurs peuvent définir des priorités. Ils peuvent également appliquer leur expertise pour offrir de meilleures solutions pour atteindre ces objectifs. Il y a une raison pour laquelle l'analyse commerciale est incluse dans le processus de développement de la plupart des entreprises.

Sans exigences commerciales claires, de mauvaises décisions peuvent être prises. Des décisions qui ralentiront le développement, perturberont les délais et entraîneront des étapes de développement supplémentaires.

Logiciels requis

Il existe deux types d'exigences : fonctionnelles et non fonctionnelles. En termes simples, la distinction est la suivante :

Les exigences fonctionnelles sont les quelles exigences — À quoi ce système est-il conçu ? Comme leur nom l'indique, ils décrivent les fonctionnalités du logiciel.

Les exigences non fonctionnelles sont les exigences de comment — Comment ce système fera-t-il ce pour quoi il est conçu ? Ces exigences décrivent comment chaque fonctionnalité doit se comporter dans quelles conditions, quelles limitations il doit y avoir, et ainsi de suite.

Les deux vont de pair. Les exigences non fonctionnelles complètent et définissent les exigences fonctionnelles. Par exemple, imaginons que nous créons une application de messagerie.

Les principales exigences fonctionnelles, dans ce cas, seraient :

1. L'application doit pouvoir envoyer des messages.
2. L'application doit prendre en charge le transfert de fichiers et de médias.
3. Etc.

Celles-ci sont assez simples et il est facile de comprendre pourquoi les exigences fonctionnelles sont importantes : elles décrivent la fonctionnalité. Dans cet exemple, le les exigences non fonctionnelles peuvent être les suivantes :

1. Le service doit offrir des fonctionnalités complètes dans tous les principaux navigateurs : Microsoft Edge, Google Chrome (deux dernières versions), Mozilla Firefox (deux dernières versions), Opera, Safari (dernière version).
2. Les mises en page mobiles doivent être prises en charge.
3. Etc.

Comme tu peux le voir, les exigences fonctionnelles sont essentiellement une liste de fonctionnalités qui doivent être incluses dans le système . En revanche, les exigences non fonctionnelles sont spécifiques. Ils sont nécessaires pour définir les conditions de développement et de test.

Il est vrai que le processus itératif Agile implique la possibilité d'introduire des changements à n'importe quel stade de développement , mais cela n'implique pas de renoncer complètement aux exigences. Vous avez juste besoin de les rendre flexibles.

Sans paramètres précis spécifiés, il est impossible de comprendre si une fonctionnalité est conçue exactement comme elle devrait l'être.

Les exigences doivent être soigneusement analysées et documentées. Pourquoi? Parce que tant de choses peuvent mal tourner si elles ne le sont pas.

L'épée de Damoclès des besoins sans-papiers

L'importance des exigences logicielles est mieux comprise par les spécialistes de l'assurance qualité. Lorsque les exigences du projet ne sont pas définies correctement, les AQ reçoivent le plus gros coup. Imaginez que vous essayez de déterminer si un logiciel est implémenté correctement sans directives claires sur ce qu'il doit faire et comment il doit le faire. C'est la folie totale.

Cependant, ce problème n'affecte pas seulement les testeurs. Ne pas avoir de spécifications officielles signifie ce qui suit :

• Il n'y a pas de compréhension claire de ce qui constitue un produit fini ou même une caractéristique.
• Le client ne sait pas à quoi s'attendre à la fin du développement et ce pour quoi il paie.
• Les développeurs sont laissés pour compte, devant déterminer les spécificités des fonctionnalités en fonction de ce qui a été dit et de la façon dont ils l'ont eux-mêmes compris.
• Bugs. Ils sont partout.

Des exigences non documentées conduisent à une mauvaise communication de tous les côtés. Il n'est pas rare qu'un client et un développeur comprennent les mêmes termes différemment. Surtout si nous parlons d'une société de développement d'externalisation qui n'est pas intimement familiarisée avec l'activité du client.

Une mauvaise communication, à son tour, ouvre la voie à des remaniements, des changements et des corrections de bogues constants. Il y a une chance que tout se passe comme prévu sans exigences documentées, mais c'est mince. Habituellement, cette chaîne se termine par des délais perturbés et des coûts qui montent en flèche.

Pour assurer un développement fluide du projet, toutes les parties du produit et le processus de son développement doivent être compris par chaque membre de l'équipe de la même manière. Pour s'assurer que les développeurs voient chaque fonctionnalité du produit exactement comme le client le fait, une spécification des exigences logicielles (SRS) est réalisée.

Le diable est dans les détails : qu'est-ce qui fait une bonne spécification des exigences logicielles ?

Désormais, les spécifications réelles des exigences logicielles peuvent être exceptionnellement détaillées ou simplement un aperçu des fonctionnalités. Le niveau de détail dépend d'un certain nombre de facteurs.

Les exigences de haute qualité sont facilement comprises par toutes les personnes impliquées dans le projet. Cela inclut le client, qui peut ou non être bien versé dans les aspects techniques. Certaines entreprises exigent une liste d'exigences exceptionnellement technique et détaillée, tandis que d'autres préfèrent des exigences en termes simples.

Quel que soit le niveau de technologie de votre documentation, il existe des règles générales pour gérer les exigences logicielles. Il existe même une norme officielle : IEEE Std 830-1998, « Pratique recommandée pour les spécifications des exigences logicielles ». Voici ce que devrait être un bon SRS, selon la norme :

• Corriger . Celui-ci est facile. L'exactitude du SRS est vérifiée par le client et le développeur sur la base de l'accord qu'ils ont. Le SRS doit être conforme aux spécifications techniques et à tous les autres documents régissant le projet.

• Sans ambiguïté . L'un des principaux objectifs d'un SRS est d'éliminer les problèmes de communication. C'est pourquoi chaque spécification d'exigence doit être écrite pour n'avoir qu'une seule interprétation possible. Il n'est pas rare qu'un SRS inclue un glossaire.

• Complet . Plus l'application est complexe, plus le SRS doit être détaillé. Un SRS complet couvre tous les aspects, des exigences de performance à la fonctionnalité. Il fixe également certaines limites à la conception. Cependant, il ne spécifie jamais une conception exacte. Il ne propose que des paramètres.

• Cohérent . La cohérence interne signifie qu'aucune déclaration dans un SRS ne contredit d'autres déclarations dans le même SRS. C'est une autre raison d'inclure un glossaire — afin que tout objet, processus et spécification dans le document soit désigné par un terme précis.

• Classé pour l'importance et/ou la stabilité . Dans la plupart des cas, il existe des exigences indispensables et des exigences souhaitées. Il est important que les spécifications des exigences logicielles indiquent clairement les deux types. Cela aidera les développeurs et les chefs de projet lorsqu'ils créeront un plan étape par étape pour le projet.

• Vérifiable . Il doit y avoir un moyen de tester chaque exigence que vous incluez dans le SRS. Pour être considérées comme vérifiables, les exigences doivent contenir des concepts mesurables et concrets.

• Modifiable . Il s'agit de la structure SRS. Afin de ne pas perturber le flux de travail du projet lorsque vous devez mettre en œuvre des modifications, le SRS doit être clair et facile à modifier, et les exigences ne doivent pas être répétées.

• Traçable . Il devrait être facile d'identifier la source de chaque exigence définie dans le SRS.

Ce sont des recommandations . En réalité, les entreprises peuvent renoncer à certains de ces points selon le projet, le client et l'équipe. Mais il est toujours bon d'avoir des conseils.

Les exigences sont pratiques, que vous soyez spécialisé dans le développement d'applications iOS et Android ou le développement Web. Ce sont des documents à usage général. Et leur apparence dépend généralement des développeurs et de leurs clients.

Étant donné qu'un SRS doit être facile à comprendre pour toutes les parties concernées, la meilleure façon de le concevoir est également discutable. Certains préfèrent les tableaux, d'autres les listes. Certains développeurs préfèrent leurs spécifications sous forme visuelle sous forme de diagrammes de flux de données et de graphiques. Il n'y a pas une seule bonne façon de faire un document de spécification des exigences.

Conclusion

Voici les points les plus courants lorsque les exigences logicielles sont utiles :

• Comprendre le but
• Estimation des coûts de développement
• Création d'un planning complet
• Établir des priorités

Que ce soit pour documenter les exigences est quelque chose que chaque développeur décide pour lui-même. Et la valeur des besoins varie en fonction de l'ampleur du projet. Chez Mind Studios, nous préférons que les choses soient en ordre, nous documentons donc toutes les exigences . Si vous êtes intéressé par notre façon de procéder ou si vous avez des questions sur la valeur des exigences en général, contactez-nous via notre formulaire de contact .