Comment rédiger le brief d’une application sur mesure sans écrire de spécifications techniques.

Un mémoire de développement n'a pas besoin de commencer par un diagramme de base de données. Il doit expliquer un travail que quelqu'un devrait être en mesure de remplir et le résultat dont votre entreprise a besoin.

Le but du premier mémoire est de rendre le projet discutable. Vous pouvez laisser les choix techniques ouverts tout en étant précis sur le travail que l'application doit soutenir.

Commencez par un utilisateur et une tâche

La création d'un portail donne le nom d'un type de logiciel.Laissez un client agréé soumettre une demande de service et voir sa progression.

Dans cet exemple, un membre du personnel doit examiner la demande et mettre à jour son état. Cela signifie que le mémoire contient déjà deux rôles différents et un dossier partagé.

Évitez de commencer par une application pour tout le monde. Différents utilisateurs peuvent avoir besoin de différentes permissions, écrans et informations. Décidez quel rôle compte le plus dans la première version.

Expliquez ce qui se passe aujourd'hui

Décrivez les étapes actuelles dans un langage ordinaire. Peut-être un client envoie-t-il des informations par courriel, un fonctionnaire les copie dans un tableur et une autre personne envoie une mise à jour.

Un exemple expurgé du formulaire ou du dossier actuel peut être plus utile qu'une présentation polie. Supprimez les renseignements personnels et les renseignements confidentiels avant de les partager.

Décrivez un voyage complet

Suivez un dossier représentatif du début à la fin. Qu'est-ce qui commence ? Quelle information est requise ? Qui prend la prochaine décision ? Qu'est-ce qui la juge complète ?

Inclure une ou deux exceptions importantes. Une demande peut être incomplète, un examinateur peut la rejeter ou un utilisateur peut devoir corriger une erreur. Ces cas aident à distinguer une application de travail d'une démonstration du chemin idéal.

Vous n'avez pas besoin d'inventer chaque événement rare à ce stade. Concentrez-vous sur les exceptions qui empêcheraient le flux de travail principal d'être utile.

Nommer les données et les dépendances

Énumérez les documents importants : utilisateurs, demandes, produits, réservations, fichiers ou tout autre ensemble d'informations. Expliquez d'où ils viennent et qui est responsable de les maintenir.

Pour une intégration, nommez l'autre service et fournissez sa documentation lorsqu'elle est disponible. Connectez-vous à notre CRM. Le détail utile est quel enregistrement doit se déplacer, dans quelle direction et après quel événement.

Déterminez si les dessins, le contenu des produits, l'accès aux comptes ou les règles d'affaires sont déjà disponibles.

Définir la première version utile

Un premier portail pourrait soutenir la création d'une demande, l'examiner et montrer l'état. Messagerie, rapport avancé et une application mobile pourrait être des discussions plus tard plutôt que des exigences non parlées de la première construction.

Ce n'est pas une instruction pour construire quelque chose d'incomplète. Le workflow choisi devrait fonctionner du début à la fin. La limite est entre les workflows complets, pas entre un écran attrayant et la logique dont il a encore besoin.

Écrire un exemple d'acceptation

Essayez une phrase que quelqu'un pourrait tester:

Un client agréé peut soumettre une demande, voir son statut après la signature et voir seulement ses propres demandes. Un membre du personnel autorisé peut mettre à jour le statut, et le client voit ce changement.

Il s'agit d'une exigence illustrative, et non d'une description d'un projet client existant. Elle rend le comportement attendu beaucoup plus clair qu'un portail moderne et sécurisé.

Ajouter des contraintes pratiques

Indiquez le moment choisi, qu'il s'agisse d'une préférence ou d'une date externe fixe, et l'échelle budgétaire où elle est connue.

Décrivez également les attentes en matière de libération et de transfert. Qui sera propriétaire de l'hébergement et des comptes ? Un autre développeur doit-il recevoir le code ? Ces questions affectent la livraison même lorsqu'elles n'apparaissent pas sur un écran.

Un bref que vous pouvez utiliser

Nous voulons construire: l'application ou le workflow. Les principaux utilisateurs sont: les personnes et les rôles. Ils doivent : la tâche principale et le résultat final. Aujourd'hui, cela se produit par: le processus actuel. La première version doit comprendre: le flux de travail complet essentiel. Il doit se connecter à: les systèmes et la documentation connus. Nous avons déjà: conceptions, contenu, comptes ou exemples de données. Toujours indécis: questions à résoudre. Calendrier, budget et décideur : les contraintes pratiques.

Utilisez quelques phrases claires pour chaque partie. Le brief est un point de départ pour définir le projet, pas un test que vous devez passer avant de parler avec un développeur.

Discutez d'une application web personnalisée ou Envoyez votre mémoire.