Developpez.com

Plus de 2 000 forums
et jusqu'à 5 000 nouveaux messages par jour

Projets : Recueil des besoins
Comment distinguer les besoins fonctionnels et non-fonctionnels ?

Le , par italiasky, Membre habitué
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...

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...
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


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de csperandio csperandio - Membre régulier http://www.developpez.com
le 18/09/2009 à 19:06
Citation Envoyé par montesq  Voir le message
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
Avatar de macos macos - Futur Membre du Club http://www.developpez.com
le 18/09/2009 à 21:11
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....

Avatar de csperandio csperandio - Membre régulier http://www.developpez.com
le 19/09/2009 à 1:02
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
Avatar de grob1212 grob1212 - Membre du Club http://www.developpez.com
le 19/09/2009 à 6:56
Citation Envoyé par csperandio  Voir le message
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
Avatar de csperandio csperandio - Membre régulier http://www.developpez.com
le 19/09/2009 à 11:44
Citation Envoyé par grob1212  Voir le message
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.
Avatar de Mac LAK Mac LAK - Inactif http://www.developpez.com
le 19/09/2009 à 19:46
Citation Envoyé par montesq  Voir le message
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...
Avatar de mongeolive mongeolive - Membre à l'essai http://www.developpez.com
le 21/09/2009 à 13:22
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).
Avatar de Franck SORIANO Franck SORIANO - Membre expert http://www.developpez.com
le 21/09/2009 à 13:29
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).
Avatar de Mac LAK Mac LAK - Inactif http://www.developpez.com
le 21/09/2009 à 13:31
Citation Envoyé par mongeolive  Voir le message
- 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...
Avatar de mongeolive mongeolive - Membre à l'essai http://www.developpez.com
le 21/09/2009 à 15:11
Citation Envoyé par Mac LAK  Voir le message
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 ?
Avatar de Saad Fahmi Saad Fahmi - Membre à l'essai http://www.developpez.com
le 20/01/2014 à 0:38
C'est très simple les amis

les besoins fonctionnels:
ce que l'utilisateur attend en terme de fonctionnalités.
par exemple: dans une calculatrice doit faire la somme, le produit... afficher les résultats...... ce sont les nécessaires.

les besoins non fonctionnels:
ce sont les besoins qui permettraient d'améliorer la qualité des services de l'application.
par exemple: Sécurité- Capacité- Disponibilité- Ergonomie- Documentation

dans notre exemple "calculatrice" on peut mettre un onglet aide, ou un tutoriel.. ou aussi on peut fournir plusieurs thèmes pour l'affichage
la calculatrice fonctionne toujours avec tutoriel ou sans tutoriel, avec un joli thème ou en noir et blanc
donc ce sont des besoins non fonctionnels, on a besoin d'une application ergonomique même si une application en noir et blanc réalise les mêmes taches
Offres d'emploi IT
Chef de projet - data warehouse h/f
DAILYMOTION - Ile de France - Paris (75017)
Développeur back-end h/f
Antadis - Ile de France - Rambouillet (78120)
Développeur Informatique H/F
BOURSE DE L'IMMOBILIER - Aquitaine - Bordeaux (33300)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil