Les différents
niveaux de besoins

Le but de cet article est d'énumérer les niveaux de besoins lors de l’analyse d’une solution logicielle.

Il y a 3 niveaux de besoins

Le mot «besoins» signifie différentes choses pour différentes personnes. Autrement dit, si vous parlez à un utilisateur et demander ce qu’est un besoin et si vous parlez à un développeur, vous aurez un sens différent du mot besoin. Par conséquent, je préfère parler des différents niveaux de besoins. Les besoins d’affaires peuvent être répartis en un ou plusieurs besoin des utilisateurs et besoins fonctionnels

Niveau 1: Besoins d'affaires (Business requirements)

Ce sont les objectifs de haut niveau de l'organisation ou du client demandant le système ou le produit. Vous le placez que dans le document de portée (Scope document). L'organisation doit mettre en place un portail client en ligne qui donnera la liste de tous ses produits.

Niveau 2: Les besoins des utilisateurs (User requirements)

Ils décrivent les tâches que les utilisateurs doivent pouvoir effectuer à l'aide du nouveau produit. Ceux-ci sont mieux décrits sous la forme de cas d'utilisation (Use cases).

Niveau 3: Les besoins fonctionnels (Functional requirements)

Vous devez extraire et tirer les besoins fonctionnelles des cas d'utilisation. Par exemple, si nous prenons l'exigence de l'entreprise, «l'organisation doit mettre en place un portail client en ligne qui donnera la liste de tous ces produits." Cela peut être décomposé en:

• Le système doit prendre en charge jusqu'à 5 photos par produit
• Le système doit enregistrer un produit par nom, description, prix et catégorie

Je tiens également à préciser qu’un bon document des besoins doit inclure une section pour les besoins non-fonctionnels. Bande passante de réseau suffisante et temps réponse de l’application peuvent être des besoins non-fonctionnel d'un système.

Ces concepts peuvent être illustrés par ce qui suit:

Je veux aussi ajouter qu’un analyste d'affaires doit prioriser les besoins pour se concentrer sur les besoins les plus importants. Un bon outil pour cela est l'analyse « MoSCow ». Il divise les exigences en quatre catégories: doit (Must), devrait (Should), pourrait (Could), et ne sera pas fait (Won’t).

Must: Décrit une exigence qui doit être satisfaite. Il s'agit d'une condition obligatoire pour que le logiciel soit considéré comme un succès.

Should: Représente un élément de haute priorité qui devrait être inclus dans la solution, s’il est possible de le réaliser.

Could: Décrit une exigence qui est considéré comme souhaitable mais pas nécessaire. Nous devons considérer temps et ressources.

Won’t: Représente une exigence que les parties prenantes ont convenu de ne sera pas mettre en œuvre dans la version actuelle, mais peut être envisagées pour l'avenir.

En conclusion, Il est important de comprendre qu’il existe une hiérarchie dans les différents niveaux de besoins.

Oracle® & Oracle® E-Business Suite
are registered trademarks of Oracle Corporation