Identifier des besoins fonctionnels
Les besoins sont communément appelés fonctionnels ou non fonctionnels. Les besoins fonctionnels décrivent les tâches que la solution doit effectuer ou ses comportements, et les besoins non transversales décrivent généralement les aspects non comportementaux de la solution, par exemple les besoins de performance. Cette rubrique couvre les considérations relatives aux besoins fonctionnels.
Chaque besoin fonctionnel doit clairement capturer le qui, le quoi et le pourquoi du besoin. Si le besoin est trop général, il doit être fractionné en parties plus petites.
Exemples de besoins fonctionnels
Les scénarios suivants décrivent des exemples simples de besoins fonctionnels :
En tant que vendeur, je dois pouvoir fermer une opportunité comme perdue, puis saisir pourquoi elle a été perdue afin que nous puissions améliorer nos tactiques de vente à l’avenir.
En tant que responsable des ventes, je dois pouvoir approuver une remise sur un devis afin de pouvoir réduire le prix total et accorder une remise au client.
En tant que comptable, je veux être empêché de fermer un traitement par lots contenant des éléments en attente afin de ne pas avoir à le rouvrir plus tard.
Ces situations communiquent le qui, le quoi et le pourquoi d’un besoin.
Les exemples suivants sont des besoins mal formulés :
Les opportunités peuvent être gagnées ou perdues.
Le prix doit refléter les remises.
Dans la liste Élément du lot, si vous cliquez sur le bouton Fermer le lot, qui est le troisième bouton à partir de la gauche, cela devrait fermer le lot s’il ne contient aucun élément susceptible de l’empêcher de se produire.
Lorsque vous recueillez des besoins de toutes sortes, il est utile de les mapper vers le processus au lieu de simplement répertorier les fonctionnalités et les fonctions. Créez un récit pour un utilisateur et décrivez comment il utilisera avec succès le système que vous concevez. Vous pouvez écrire ou dessiner sur un tableau blanc, utiliser un outil pour schématiser un processus ou utiliser toutes les méthodes qui fonctionneront pour votre équipe à la phase de planification dans laquelle vous vous trouvez. Votre équipe va décortiquer les unités en petits éléments exploitables plus tard.
Critères d’acceptation
Il est important de bien comprendre comment un besoin est considéré comme satisfait. Souvent, documenter la satisfaction vous permettra de déterminer si le besoin est suffisamment détaillé et de la bonne taille. Cette approche est également utile pour tester les équipes lorsqu’elles évaluent la mise en œuvre du besoin. Enfin, la satisfaction du besoin doit être examinée avec la partie prenante pour s’assurer qu’elle est réelle, car elle permet d’empêcher le débordement du périmètre. L’architecte de la solution doit rechercher des critères d’acceptation qui ne peuvent pas être satisfaits, puis négocier en vue de parvenir à un compromis réalisable.
Capturer les exceptions
En général, un simple besoin tel que la clôture d’une transaction peut suivre un chemin simple et seulement quelques chemins d’exception. Veillez à rechercher et identifier ces exceptions lors de la capture du chemin de réussite. Lorsque vous passez à la conception, vous ne voulez pas concevoir principalement pour les exceptions. Elles doivent être traitées comme telles, mais si vous ne savez pas qu’elles existent, vous devrez remanier la conception plus tard. En outre, n’oubliez pas de capturer la fréquence à laquelle l’exception se produit, car certaines exceptions sont mieux gérées par la procédure et/ou le processus et non par la personnalisation du logiciel.
Éviter le débordement du périmètre
Sans contrôle, chaque projet agrandirait le périmètre par rapport à ce qui était envisagé et budgété. L’architecte de la solution doit être vigilant dans la recherche de besoins qui dépassent le périmètre des hypothèses d’origine. Le processus de gouvernance du projet doit être utilisé pour évaluer comment les gérer une fois qu’elles ont été identifiées. Souvent, ces besoins hors périmètre acceptées à des fins d’inclusion peuvent entraîner une modification de commande, selon la structure contractuelle du projet. Ignorer le fait que le périmètre augmente peut facilement entraîner l’échec du projet.
Exercice : rechercher les besoins fonctionnels
Passez en revue les équipes de la banque Woodgrove et identifiez les chevauchements probables entre les équipes dans la fonctionnalité dont elles auront besoin pour faire leur travail.
Croissance des entreprises et gestion d’actifs : comptes commerciaux avec moins de 1 milliard de dollars US de transactions annuelles. La croissance dans ce sens se réfère aux prêts qui sont utilisés pour réinvestir dans la société. Ces clients partagent un groupe de gestionnaires de comptes ; ils ne sont pas attribués à un individu.
Fortune 500 : chaque client de cette division se voit attribuer un gestionnaire de compte senior comme contact principal pour toutes les questions bancaires. Lorsqu’une entreprise est gérée dans cette division, elle y reste, même si elle quitte la liste de Fortune 500.
Gestion de portefeuille de groupe : cette équipe gère les comptes parent/enfant sous un même parapluie pour les entreprises avec plusieurs organisations.
Développement de nouvelles activités : cette division commercialise principalement de nouvelles activités. Lorsqu’un compte est qualifié et actif, il passe à l’équipe de gestion appropriée.
Secteur public/gouvernement/enseignement supérieur : la banque Woodgrove est un prêteur privilégié de nombreux gouvernements souverains du monde entier et d’universités privées. Cette équipe s’occupe également de quelques organismes sans but lucratif à volume élevé desservis par la banque.
Prêts à la consommation : cette équipe est la plus petite, car la banque Woodgrove se concentre sur les produits commerciaux. Cependant, les prêts à la consommation à volume élevé sont disponibles au cas par cas. Cette équipe n’est pas annoncée aux prospects externes, mais principalement utilisée par les cadres des entreprises clientes.
Gestionnaires de relations : cette équipe est composée de membres de chacune des autres équipes, ce qui garantit une expérience cohérente, car les comptes peuvent se déplacer entre les équipes et interagir d’autres manières. Cette équipe établit également des meilleures pratiques pour les utilisateurs.