Comment distinguer l'expression des besoins fonctionnels et non-fonctionnels

Bonsoir,

Lors de l'analyse des besoins, on doit faire la distinction entre besoins fonctionnels et besoins non-fonctionnels. Dans des exemples, cela parait toujours simple mais lorsque l'on doit mettre cela en pratique, les choses se compliquent... lol donc un petit éclaircissement pourrait faire du bien... :D

En fait, besoin fonctionnel, est-ce que c'est bien tout ce qui est fonctions du système ? au sens qu'est-ce que le système fait ? pour quoi il est fait ? ses fonctionnalités ? ou il y a également une nuance entre les fonctions et les fonctionnalités d'un système ?

Les besoins non-fonctionnels seraient alors plus des caractéristiques, des contraintes techniques.. ?

Exemple :
De ce fait, en cours, on nous a demandé d'analyser un système qui permet d'écouter de la musique en streaming sur internet, par exemple, spotify, deezer... quels pourraient-être les besoins fonctionnels et non-fonctionnels ?

Si on se base vraiment sur ce que fait le système, on aurait juste envie de dire :
- le système doit permettre d'écouter une musique
Et éventuellement :
- le système permet de créer une playlist
- le système permet de rechercher une musique...

Mais ca ne fait pas énormément de besoins fonctionnels et notre prof nous dit d'en trouver au moins une dizaine... 8O
Faut-il entrer plus dans les détails ? Mais je pensais qu'il fallait rester à un haut niveau pour les besoins fonctionnels ?

Concernant les non-fonctionnels, j'aurais envie de dire :
- le système doit jouer une musique rapidement : dans les 2 secondes après le click
- le système ne doit pas utiliser plus de 50% de la bande passante de l'internaute

Enfin, j'ai l'impression de me perdre un peu... peut être que quelqu'un pourrait m'éclaircir avec ses propres mots... ?

Merci d'avance
Bonne soirée

Michael

On pourrait simplifier et vulgariser (pardon aux puristes) en disant :

• Les besoins fonctionnels répondent aux points précis du cahier des charges, et sont donc requis par le client.
  Ils ne sont pas négociables en général, c'est le "besoin primaire" du client.
• Les besoins non-fonctionnels sont soit des besoins optionnels, soit des besoins/contraintes liés à l'implémentation (contraintes de langage ou de plate-forme, par exemple) et à l'interopérabilité générale (ne pas bouffer toutes les ressources de la machine par exemple).
  Ils peuvent être fixés par le client (fonctions optionnelles), ou par le développeur (contraintes d'implémentation).

A noter que quelque chose qui pourrait ressembler à un besoin fonctionnel peut ne pas l'être : par exemple, le client peut demander quelque chose comme "Supporter 100 connexions simultanées, si possible 1000." : le besoin fonctionnel est alors d'en supporter 100, à toi de voir si en supporter 1000 (et ça, c'est un besoin non-fonctionnel !) est jouable ou pas.
Si oui, tu fais plaisir à ton client au prix d'une constante différente dans ton code, et potentiellement ça t'aidera à faire passer la pilule sur une exigence client où tu n'as pas été très performant.
Si non, c'est une dérogation déjà tacitement acceptée par le client.

La liste des besoins finaux (fonctionnels ou pas) sera donc écrite dans la spécification du logiciel, qui est la réponse au cahier des charges après analyse plus ou moins poussée de ce dernier. Cela demande un minimum d'expérience pour faire des spécifications qui ne te mettront pas direct dans le mur au moment de la conception et du codage... Notamment en ce qui concerne le chiffrage du temps de développement !!
Pour les besoins non-fonctionnels, on reste en général flou et/ou on spécifie explicitement que l'élément est optionnel. Par contre, on fixe en général à ce moment-là les besoins non-fonctionnels que l'on sait pouvoir/devoir tenir par expérience.


Dans ton cas, comme besoins fonctionnels, tu as au moins :

• Pouvoir accéder à n'importe quelle ressource musicale sur le net, ce qui implique :
  • Un système de choix des URL source,
  • Un sous-système de lecture depuis cette URL.
• La capacité à gérer la plupart des formats connus et utilisés sur le net.
• Assurer les fonctions de lecture de base : lecture, pause, stop, avance/retour rapide si c'est possible (pas possible avec une web radio par exemple), contrôle du volume, égaliseur de son.

Et avec ça, tu n'as pas grand-chose si tu y réfléchis bien... OK, ça fait ouin-ouin dans les haut-parleurs, mais c'est quelque chose faisable en ligne de commande si nécessaire ! ;)

En besoins non-fonctionnels, tu peux avoir par exemple :

• Utiliser quelque chose de pratique pour la récupération des données depuis le net : API/librairies de téléchargement/streaming dédiées, ou clients HTTP/FTP, au lieu d'une bête socket TCP/IP.
• Avoir une belle IHM, ergonomique et pratique à utiliser.
• Être écrit dans un langage portable, avec des librairies tierces portables et/ou remplaçables aisément.
• Pouvoir tourner sur un système datant d'il y a cinq ans.
• Pour le décodage du son, utiliser des librairies tierces et/ou des codecs système. Penser que cela implique aussi la GÉNÉRATION du son lui-même, donc le pilotage de la carte audio et/ou des API dédiées.
• Rester décents sur la consommation de temps CPU.
• Éviter les IHM trop petites ou trop grandes.
• La consommation de bande passante est liée directement au débit de la musique, ce n'est donc pas une réelle contrainte...
  Toutefois, il faudra sûrement prévoir un système de mise en cache en cas de très gros débits avec de petites connexions.
• Stocker un historique des musiques lues pour une recherche simplifiée.
• Système de playlist, bookmarks, etc. pour rendre la navigation agréable.
• Etc.

La liste des besoins non-fonctionnels est virtuellement illimitée, à toi de voir ce qui est faisable "pour pas cher" (et qui plait le plus au client), et ce qui est un gadget coûteux en temps de développement et dont le client, au final, se contrefiche... C'est un équilibre parfois délicat.

En général, c'est soit plus ou moins indiqué dans le cahier des charges, soit il te faut faire une STB (Spécification Technique de Besoins) auprès du client, ce qui revient en gros à faire ton enquête sur ce qu'il veut vraiment (et c'est rarement ce qu'il a écrit à l'origine... :mouarf:). Il te faut aussi un peu de bon sens : mets-toi à la place du client, en tant qu'utilisateur de ton produit, et demandes-toi si ça te plairait de l'utiliser ! ;)

A contrario, les besoins fonctionnels, eux, sont toujours explicites et clairement indiqués, même si une simple exigence peut être décomposée en multiples besoins fonctionnels élémentaires (exemple : "Stocker les résultats en base de données" sous-entend un sacré paquet de besoins fonctionnels élémentaires).


Est-ce un peu plus clair pour toi ?

Citation:

---

Envoyé par Mac LAK

On pourrait simplifier et vulgariser (pardon aux puristes) en disant :[list][*]Les besoins fonctionnels répondent aux points précis du cahier des charges, et sont donc requis par le client.

---

Oui dans un cas réel, il y a tout d'abord le cahier des charges et une discussion avec le client sur lesquels s'appuyer, ce qui doit rendre alors les choses surement plus réalistes que dans mon exercice.

Citation:

---

Envoyé par Mac LAK

Dans ton cas, comme besoins fonctionnels, tu as au moins :

• Pouvoir accéder à n'importe quelle ressource musicale sur le net, ce qui implique :
  • Un système de choix des URL source,
  • Un sous-système de lecture depuis cette URL.
• La capacité à gérer la plupart des formats connus et utilisés sur le net.
• Assurer les fonctions de lecture de base : lecture, pause, stop, avance/retour rapide si c'est possible (pas possible avec une web radio par exemple), contrôle du volume, égaliseur de son.

Et avec ça, tu n'as pas grand-chose si tu y réfléchis bien...

---

Donc la dizaine de besoins fonctionnels qui nous est demandée est un peu utopique pour ce système.. ? lol ! Le problème, c'est qu'ils nous disent de trouver autant de besoins fonctionnels et seulement 2 besoins non-fonctionnels... ? (alors que pour les non-fonctionnels, c'est quasi illimités en tournant autour du sujet comme vous l'avez si bien dit..)
Peut-on décomposer les fonctions de lecture chacune en besoin fonctionnel ?

Citation:

---

Envoyé par Mac LAK

[*]Stocker un historique des musiques lues pour une recherche simplifiée.[*]Système de playlist, bookmarks, etc. pour rendre la navigation agréable.

---

Je les voyais en besoins fonctionnels moi... ce n'est pas possible ? :?

Si j'arrive à cette liste, qu'en pensez-vous ?

Besoins fonctionnels :
1) Le système doit jouer de la musique.
2) L'internaute doit être capable de chercher une musique.
3) L'internaute peut créer une playlist.
4) L'internaute peut supprimer une playlist seulement si il en est l'auteur.
5) L'internaute peut répéter une musique.
6) L'internaute peut jouer une playlist aléatoirement.
7) L'internaute peut augmenter le volume.
8) L'internaute peut baisser le volume.
9) Le système doit sauvegarder les recherches pour un accès plus rapide.
10) L'internaute peut activer l'égaliseur de son.
11) L'internaute peut partager une playlist

Besoins non-fonctionnels :
1) Le système doit jouer une musique rapidement : elle doit démarrer dans les 2 secondes suivant un click.
2) Le système ne doit pas utiliser plus de 50% de la bande passante de l'utilisateur.

En tout cas merci pour vos réponses, avec des mots différents, ca permet d'avancer.. ;)

Bonne journée

Citation:

---

Envoyé par italiasky

Oui dans un cas réel, il y a tout d'abord le cahier des charges et une discussion avec le client sur lesquels s'appuyer, ce qui doit rendre alors les choses surement plus réalistes que dans mon exercice.

---

En l'occurrence, ton CdC, c'est ton énoncé... ;)

Citation:

---

Envoyé par italiasky

Donc la dizaine de besoins fonctionnels qui nous est demandée est un peu utopique pour ce système.. ? lol ! Le problème, c'est qu'ils nous disent de trouver autant de besoins fonctionnels et seulement 2 besoins non-fonctionnels... ? (alors que pour les non-fonctionnels, c'est quasi illimités en tournant autour du sujet comme vous l'avez si bien dit..)
Peut-on décomposer les fonctions de lecture chacune en besoin fonctionnel ?

---

Je trouve que ça fait beaucoup, mais d'un autre côté, j'ai peu détaillé les besoins fonctionnels dans ma précédente réponse, tu remarqueras... :mrgreen:

Citation:

---

Envoyé par italiasky

Je les voyais en besoins fonctionnels moi... ce n'est pas possible ? :?

---

Est-ce demandé explicitement ? Est-ce nécessaire pour écouter de la musique ?
Si tu réponds "non" aux deux questions, c'est un besoin non fonctionnel.

Citation:

---

Envoyé par italiasky

Besoins fonctionnels :
1) Le système doit jouer de la musique.
2) L'internaute doit être capable de chercher une musique.
3) L'internaute peut créer une playlist.
4) L'internaute peut supprimer une playlist seulement si il en est l'auteur.
5) L'internaute peut répéter une musique.
6) L'internaute peut jouer une playlist aléatoirement.
7) L'internaute peut augmenter le volume.
8) L'internaute peut baisser le volume.
9) Le système doit sauvegarder les recherches pour un accès plus rapide.
10) L'internaute peut activer l'égaliseur de son.
11) L'internaute peut partager une playlist

---

Comme je te l'ai dit, c'est une question d'énoncé... Si l'énoncé dit par exemple "comme Winamp", ce sont des besoins fonctionnels. Si c'est "comme le magnétophone par défaut", c'est bien trop. C'est là que la phase de rédaction des STB (= dans ton cas, questions au prof) entre en jeu, afin de raffiner le besoin réel et/ou le niveau de détail demandé dans les besoins fonctionnels.
De plus, certains points ne sont pas assez détaillés (le 1), et d'autres artificiellement découpés (7 & 8 => contrôle du volume).

Citation:

---

Envoyé par italiasky

Besoins non-fonctionnels :
1) Le système doit jouer une musique rapidement : elle doit démarrer dans les 2 secondes suivant un click.
2) Le système ne doit pas utiliser plus de 50% de la bande passante de l'utilisateur.

---

Non pour le deuxième : cela ne dépend que du débit de la musique en question, et non pas de ton programme. Remplace par "charge CPU" plutôt.

Citation:

---

Envoyé par italiasky

En tout cas merci pour vos réponses, avec des mots différents, ca permet d'avancer.. ;)

---

De rien !

Citation:

---

Envoyé par Mac LAK

On pourrait simplifier et vulgariser (pardon aux puristes) en disant :

• Les besoins fonctionnels répondent aux points précis du cahier des charges, et sont donc requis par le client.
  Ils ne sont pas négociables en général, c'est le "besoin primaire" du client.
• Les besoins non-fonctionnels sont soit des besoins optionnels, soit des besoins/contraintes liés à l'implémentation (contraintes de langage ou de plate-forme, par exemple) et à l'interopérabilité générale (ne pas bouffer toutes les ressources de la machine par exemple).
  Ils peuvent être fixés par le client (fonctions optionnelles), ou par le développeur (contraintes d'implémentation).

A noter que quelque chose qui pourrait ressembler à un besoin fonctionnel peut ne pas l'être : par exemple, le client peut demander quelque chose comme "Supporter 100 connexions simultanées, si possible 1000." : le besoin fonctionnel est alors d'en supporter 100, à toi de voir si en supporter 1000 (et ça, c'est un besoin non-fonctionnel !) est jouable ou pas.

---

Bonjour,

@Mac J'émets de gros doutes sur ta vulgarisation. Personnellement d'après mes dernières lectures (par exemple UML 2 de P. Roques), les besoins fonctionnels sont la description des fonctionnalités de l'application, c'est-à-dire les réponses à la question : "à quoi sert l'application?"

Les besoins non-fonctionnels sont davantage liés à la question "comment les fonctionnalités de l'application doivent être réalisées?" -> avec une IHM de telle sorte, avec tel langage, avec telle architecture, avec des contraintes sur les temps de réponses...
Bien sûr, en général le besoin fonctionnel est explicitement dans le cahier des charges, car personne ne va s'amuser à perdre du temps et de l'argent à développer des fonctionnalités non requises par le client! Mais la réciproque est fausse...

Pour reprendre, dans ton exemple "Supporter 100 connexions simultanées, si possible 1000", il s'agit clairement d'une exigence technique et donc d'un besoin non fonctionnel (que ce soit pour 100 ou pour 1000), car cela ne décrit pas quelle fonctionnalité le système doit fournir mais comment il doit les fournir

Citation:

---

Envoyé par montesq

@Mac J'émets de gros doutes sur ta vulgarisation. Personnellement d'après mes dernières lectures (par exemple UML 2 de P. Roques), les besoins fonctionnels sont la description des fonctionnalités de l'application, c'est-à-dire les réponses à la question : "à quoi sert l'application?"

---

Oui, c'est ce que je dis en parlant de besoin explicite demandé par le client. Toutefois, un point t'as peut-être échappé : le client demande rarement les choses avec un vocabulaire technique, c'est un "raccourci" que j'ai utilisé dans mon explication.

Citation:

---

Envoyé par montesq

Les besoins non-fonctionnels sont davantage liés à la question "comment les fonctionnalités de l'application doivent être réalisées?" -> avec une IHM de telle sorte, avec tel langage, avec telle architecture, avec des contraintes sur les temps de réponses...

---

Relis ma réponse : "Les besoins non-fonctionnels sont des besoins/contraintes liés à l'implémentation et à l'interopérabilité générale. Ils peuvent être fixés par le client, ou par le développeur."

Citation:

---

Envoyé par montesq

Bien sûr, en général le besoin fonctionnel est explicitement dans le cahier des charges, car personne ne va s'amuser à perdre du temps et de l'argent à développer des fonctionnalités non requises par le client! Mais la réciproque est fausse...

---

Quelle réciproque ? Qu'un besoin non-fonctionnel peut être spécifié dans le cahier des charges, ou qu'un besoin fonctionnel peut ne PAS être spécifié dans le CdC ?

Citation:

---

Envoyé par montesq

Pour reprendre, dans ton exemple "Supporter 100 connexions simultanées, si possible 1000", il s'agit clairement d'une exigence technique et donc d'un besoin non fonctionnel (que ce soit pour 100 ou pour 1000), car cela ne décrit pas quelle fonctionnalité le système doit fournir mais comment il doit les fournir

---

Non, c'est un besoin fonctionnel. Le CdC indiquera en général quelque chose comme "tous les employés doivent pouvoir accéder en même temps à l'application", ou "le système doit pouvoir traiter N requêtes par jour", ou toute autre formulation "vague" qu'il faudra traduire en langage technique. De plus, en fonction de la nature du produit demandé par le CdC, un besoin fonctionnel peut parfaitement être exprimé sous forme d'une exigence technique.

De plus, il est très fréquent qu'un client fournisse une demande sous forme de "plage de valeurs", ou d'énumération de possibilités, ou toute autre formulation pouvant, au final, être traduite en langage technique par une borne minimale (à tenir impérativement) et une borne maximale (au delà de laquelle il est inutile, et forcément coûteux, d'aller).

Dans un tel cas, une même exigence initiale se traduit bel et bien en un besoin fonctionnel (la borne minimale), et un besoin non-fonctionnel (la borne maximale). Tu as en plus une exigence technique qui se rajoute, et qui ne concerne pas réellement le client : il FAUT se débrouiller pour garantir la borne minimale (respect CdC) SANS dépasser la borne maximale (argent gâché).

N'oublie pas non plus qu'un besoin (fonctionnel ou pas) peut également être une exigence technique, tout comme besoins et exigences techniques peuvent être totalement décorrélés.
Pour le premier exemple, tu peux avoir par exemple un besoin fonctionnel "doit tourner sur l'intranet de la société", qui est bien entendu une exigence technique également.
L'autre cas, c'est "on va la développer en Java plutôt qu'en PHP" : ça n'a rien à voir avec un quelconque besoin du client, c'est un choix plus ou moins arbitraire parmi un éventail de possibilités d'implémentation. Mais ça compte si la boîte possède majoritairement des devs Java plutôt que PHP.

Reprenons le raisonnement du début:
1° besoin fonctionnel = exigences qui décrivent les fonctionnalités de l'application = "quelles sont les fonctionnalités de l'application?" = "à quoi sert l'application"?
Ex:
-l'application sert à gérer la base de donnée client (description très macro)
-l'application doit permettre de rechercher un dossier client dans la base
...

Est-ce que tu es d'accord sur ce point?

2° besoin non fonctionnel = toutes les exigences qui ne sont pas "fonctionnelles".

Est-ce que l'exigence "Supporter 100 connexions simultanées" répond à la question "à quoi sert l'application?" Non, elle répond plutôt à la question "comment doit se comporter l'application?".
Est-ce que tu peux développer une application dont l'unique "fonctionnalité" est "supporter 100 connexions simultanées"?
Non, cela ne veut rien dire! Ce n'est pas une fonctionnalité (=besoin fonctionnel) mais bien bien une contrainte non-fonctionnelle.
Par contre l'appli peut avoir comme unique fonctionnalité "rechercher un dossier client dans une base".

Citation:

---

Envoyé par montesq

Reprenons le raisonnement du début:
1° besoin fonctionnel = exigences qui décrivent les fonctionnalités de l'application = "quelles sont les fonctionnalités de l'application?" = "à quoi sert l'application"?
Ex:
-l'application sert à gérer la base de donnée client (description très macro)
-l'application doit permettre de rechercher un dossier client dans la base
...

Est-ce que tu es d'accord sur ce point?

2° besoin non fonctionnel = toutes les exigences qui ne sont pas "fonctionnelles".

Est-ce que l'exigence "Supporter 100 connexions simultanées" répond à la question "à quoi sert l'application?" Non, elle répond plutôt à la question "comment doit se comporter l'application?".
Est-ce que tu peux développer une application dont l'unique "fonctionnalité" est "supporter 100 connexions simultanées"?
Non, cela ne veut rien dire! Ce n'est pas une fonctionnalité (=besoin fonctionnel) mais bien bien une contrainte non-fonctionnelle.
Par contre l'appli peut avoir comme unique fonctionnalité "rechercher un dossier client dans une base".

---

De mon point de vue, ce n'est pas exigence fonctionnelle mais, une exigence client. Cela peut faire partie des contraintes d'un besoin fonctionnel.

Citation:

---

Envoyé par csperandio

De mon point de vue, ce n'est pas exigence fonctionnelle mais, une exigence client. Cela peut faire partie des contraintes d'un besoin fonctionnel.

---

Ce n'est pas une exigence fonctionnelle mais cela peut faire partie des contraintes d'un besoin fonctionnel. :)
Ok dans ce cas là, est-ce que l'on pourrait utiliser un vocabulaire moins ambivalent et dire :
"c'est une exigence non-fonctionnelle qui s'inscrit dans le cadre des besoins utilisateurs/métier" (si on est d'accord que besoin fonctionnel pour toi= besoin métier pour moi, en opposition à l'expression des besoins techniques)?

De mes souvenirs de cours, on avait le cahier des charges TECHNIQUE et le cahier des charges FONCTIONNELS.

Le technique regroupe les besoins purement 'software/hardware' tandis que le fonctionnel regroupe les besoins utilisateur - dans le cas de l'exemple de deezer il s'agit des besoins de l'internaute.

Citation:

---

Envoyé par montesq

Ce n'est pas une exigence fonctionnelle mais cela peut faire partie des contraintes d'un besoin fonctionnel. :)
Ok dans ce cas là, est-ce que l'on pourrait utiliser un vocabulaire moins ambivalent et dire :
"c'est une exigence non-fonctionnelle qui s'inscrit dans le cadre des besoins utilisateurs/métier" (si on est d'accord que besoin fonctionnel pour toi= besoin métier pour moi, en opposition à l'expression des besoins techniques)?

---

On peut le faire comme ça :)

Bonsoir,

pour faire assez clair:

besoin fonctionnel: cela exprime la réalisation d'un service
(ie: l'utilisateur à une IHM, le séquenceur permet etc.., messages, et l'applicatif rend les services
- le système doit permettre d'écouter une musique
Et éventuellement :
- le système permet de créer une playlist
- le système permet de rechercher une musique...



Concernant les non-fonctionnels, j'aurais envie de dire :
- une conception par UML non prévue
- compatibilité norme, version etc...
- maintenance sur plusieurs années
- utilisation de technologies précises.
- faire le café
- livraison, jalons, démonstration, preuve, vérification.
- design produit
- éléments génériques non fonctionnels
- contrainte ou lieux d'exigences de design
- compatibilité produit

Bref des exigences que ton application ne peut pas réaliser au sens
service fonctionnel. L'APPLICATION NE REND PAS LE SERVICE, cela ne
l'impacte pas dans la description du service

Par contre le cahier des charges TECHNIQUE contient les services
fonctionnel et non fonctionnel. exemple. société A et B se mettront d'accord sur le choix de l'outil (lorsqu'il n'est pas encore choisis) ou le nombre de licence etc...

Besoin d'un preuve, d'un délivrable documentaire, méthode, etc... (plan, etc...) gestions d'exigence etc....




:ccool::ccool:

Nous pouvons également dire qu'un besoin fonctionnel et ce que demande le client :)
J'ai travaillé sur un projet d'annuaire inversé et le client avait dit que la réponse devait être dans la demi-seconde. Nous pouvons dire que dans ce cas, c'est un besoin fonctionnel ;)

Citation:

---

Envoyé par csperandio

Nous pouvons également dire qu'un besoin fonctionnel et ce que demande le client :)
J'ai travaillé sur un projet d'annuaire inversé et le client avait dit que la réponse devait être dans la demi-seconde. Nous pouvons dire que dans ce cas, c'est un besoin fonctionnel ;)

---

AMHA, ce n'est pas un besoin fonctionnel, c'est une contrainte technique liée à la fonctionnalité, que le prestataire doit impérativement respecter.

Les contraintes sont également la formalisation explicite de ce que veux ou ne veux pas le client et qui vont permettre de guider le prestataire dans la manière de réaliser les fonctionnalités du projet.

J'aime assez bien l'idée de service rendu de macos, deux billets au dessus :)

Citation:

---

Envoyé par grob1212

AMHA, ce n'est pas un besoin fonctionnel, c'est une contrainte technique liée à la fonctionnalité, que le prestataire doit impérativement respecter.

Les contraintes sont également la formalisation explicite de ce que veux ou ne veux pas le client et qui vont permettre de guider le prestataire dans la manière de réaliser les fonctionnalités du projet.

J'aime assez bien l'idée de service rendu de macos, deux billets au dessus :)

---

C'est une contrainte technique pour les développeurs. Pas forcément pour le client. Tout cela dépend qui sont les destinataires du document. On sait bien que nous devons adapter le vocabulaire en fonction du public. C'est comme les cas d'utilisation, le client n'a que ceux du niveau système pas ceux du niveau fonction.

Citation:

---

Envoyé par montesq

Ok dans ce cas là, est-ce que l'on pourrait utiliser un vocabulaire moins ambivalent

---

C'est un peu le problème d'une réponse sur un forum, telle que posée par l'OP : le but n'est pas de faire un cours exhaustif et 100% exact, mais de "dégrossir" le topo. Il y a forcément des abus de langages, des raccourcis et des imprécisions dans une telle démarche de vulgarisation...

Je comprends parfaitement la frustration de italiasky, car les termes "besoins fonctionnels" et "non-fonctionnels" ont longtemps été ambigus pour moi.

Après avoir beaucoup lu et progressé dans les méthodes de génie logiciel, la définition que je préfère est celle que je retire et comprends du livre "UML 2 et les design patterns, Analyse et conception orientées objet et développement itératif" de Craig Larman.
Craig Larman est un ardent défenseur des méthodes de développement itératives et agiles, et ce livre décrit plus précisément les éléments du Processus Unifié (Unified Process ou UP).
Je cite donc directement l'auteur, c'est toujours mieux qu'une explication foireuse :

"Dans la pratique, les besoins sont classés en besoins fonctionnels (comportementaux) ou non-fonctionnels (tous les autres)."

"Le processus unifié propose plusieurs artefacts pour organiser les besoins. Comme il est de règle, ils sont tous optionnels. Voici la liste des plus importants d'entre eux :

• Modèle de cas d'utilisation.
  Ensemble de scénarios typiques de l'utilisation d'un système. Il concerne avant tout les besoins fonctionnels (comportementaux).
• Spécifications Supplémentaires.
  Elles contiennent en substance tout ce qui ne se trouve pas dans les cas d'utilisation et concernent surtout les besoins non fonctionnels (les exigences de performance ou les licences).
  C'est ici que seront consignées certaines caractéristiques fonctionnelles, non exprimées (ou non exprimables) dans les cas d'utilisation (la génération d'états).
• etc..."

J'ai indiqué en gras dans le texte l'élément qui a pour moi le plus d'importance : la notion de besoins comportementaux, qui est pour moi une manière plus objective et qui a plus de sens de classer les besoins.
Aujourd'hui, si je dois écrire des spécifications, je les classe donc de la façon suivante :

- Les besoins comportementaux, qui peuvent être décrits par des cas d'utilisation. Il s'agit donc des services que rend le système à l'utilisateur. Tous les exemples cités par italiasky qui commencent par "L'internaute peut..." sont pour moi d'excellents débuts de cas d'utilisation.

- Les besoins non-comportementaux, qui ne peuvent pas être décrits par des cas d'utilisation. Il ne s'agit généralement pas de services rendus à l'utilisateur du système, mais souvent de contraintes techniques comme "Supporter 100 connexions simultanées".

Voici donc un peu la "méthode" objective que j'essaie d'appliquer aujourd'hui. Si un besoin peut être décrit dans un cas d'utilisation, alors il s'agit d'un besoin comportemental (fonctionnel). Sinon, il s'agit d'un besoin non-comportemental (non-fonctionnel).

Besoin fonctionnel = toutes les fonctionnalités dont le client à besoin pour son activité.
Besoin non-fonctionnel = tous le reste.

Très franchement, ce n'est qu'une classification de l'esprit qui n'a pas une grande importance.

Dans tous les cas, il faut respecter le cahier des charges du client et répondre à ses attentes. Que ce soit du fonctionnel ou du non fonctionnel ça ne change rien.

Ce qui est réellement important lors d'une analyse des besoins, et la rédaction des specs, c'est de faire la différence entre ce qui relève du besoin, et ce qui relève de la solution pour répondre au besoin.

Avec tous les problèmes qui en découlent :
- Faire la différence entre le besoin réel (qu'il faut satisfaire pour que le client soit content au final), le besoin perçu (ce que le client lui-même comprend de son besoin, qui n'est pas forcément ce dont il a réellement besoin), et le besoin exprimé (ce que le client croit exprimer dans son CdC, ce n'est pas forcément ce qu'on comprend en lisant son CdC).
- Très souvent (et j'aurais tendance à dire que c'est un comportement humain), le client perçoit un besoin, pense à une solution et exprime sa solution comme étant le besoin. Si on se contente de coder bêtement ce qu'il demande, on pourra toujours se retrancher derrière : "on a fait ce que vous nous aviez demandé", mais on ne répondra pas au besoin réel du client, et il ne sera pas content ! (même si contractuellement, on pourra peut-être le forcer à payer).

Citation:

---

Envoyé par mongeolive

- Les besoins non-comportementaux, qui ne peuvent pas être décrits par des cas d'utilisation. Il ne s'agit généralement pas de services rendus à l'utilisateur du système, mais souvent de contraintes techniques comme "Supporter 100 connexions simultanées".

---

Même là, ce n'est pas aussi clair et idéal : regarde l'exemple que je donnais, "tous les employés doivent pouvoir accéder en même temps à l'application"... C'est bien un service rendu à l'utilisateur (pas de file d'attente de connexion, notamment, ni de "verrou" de données interdisant de travailler en mode concurrent), et en plus c'est une contrainte technique.


C'est pour ça qu'en général, je préfère présenter au client quelque chose qui lui parle à LUI, c'est à dire classé en "exigences client / contraintes fournisseur" (avec liaisons éventuelles entre les deux), plutôt qu'une classification purement logicielle à laquelle, le plus souvent, il ne comprends rien... ;)

Citation:

---

Envoyé par Mac LAK

Même là, ce n'est pas aussi clair et idéal : regarde l'exemple que je donnais, "tous les employés doivent pouvoir accéder en même temps à l'application"... C'est bien un service rendu à l'utilisateur (pas de file d'attente de connexion, notamment, ni de "verrou" de données interdisant de travailler en mode concurrent), et en plus c'est une contrainte technique.

---

Tout n'est effectivement pas clair et idéal, ça serait trop facile ;).
Cependant, si je m'en tiens aux définitions des cas d'utilisation, et bien cet exemple n'est pas un besoin fonctionnel (je dirais plutôt comportemental). Dans l'exemple, l'utilisateur n'interagit pas directement avec le système pour obtenir un service.
Du point de vue du service rendu (du comportement), peut importe comment l'utilisateur accède "techniquement" au système. Ce qui compte c'est l'interaction qu'il a avec le système pour obtenir un résultat (doit-il s'identifier avec un mot de passe ?).
Permettre des connexions simultanées relève pour moi plutôt du non-comportemental.

Citation:

---

Envoyé par Franck SORIANO

Très franchement, ce n'est qu'une classification de l'esprit qui n'a pas une grande importance.
Dans tous les cas, il faut respecter le cahier des charges du client et répondre à ses attentes. Que ce soit du fonctionnel ou du non fonctionnel ça ne change rien.
Ce qui est réellement important lors d'une analyse des besoins, et la rédaction des specs, c'est de faire la différence entre ce qui relève du besoin, et ce qui relève de la solution pour répondre au besoin.

---

Je suis d'accord avec ça, c'est effectivement une classification de l'esprit, comme beaucoup d'autres choses en développement logiciel. Ce n'est bien sûr pas le plus important, mais comme tout autre classification, ça peut éclaircir la lecture et la compréhension des informations ou d'un document.
Cependant, je m'efforce d'essayer de donner mon point de vue théorique à la question posée au départ, car c'est un sujet qui m'intéresse beaucoup.
La conception orientée objet n'est elle pas aussi une classification de l'esprit dans ce cas ?