Différence entre les spécifications fonctionnelles et techniques
J'écris une spécification pour un projet et j'ai du mal à séparer la spécification fonctionnelle de la spécification technique (voir http://www.joelonsoftware.com/articles/fog0000000035.html ).
Par exemple, j'essaie de spécifier le comportement lorsqu'un utilisateur demande une liste d'objets Foo sur lesquels il a une visibilité. Dans la spécification fonctionnelle, dois-je décrire ce qui est retourné avec précision (c'est-à-dire la structure d'un objet Foo) ou simplement que le système en retourne une liste et ensuite mettre les détails de l'objet Foo dans la spécification technique?
La conception est pour une API au cas où cela ferait une différence. Je ne trouve pas beaucoup d'exemples de la façon dont une telle spécification d'API est écrite.
Spécifications techniques est un terme large. Il décrit toute caractéristique d'un système d'ingénierie qui doit se conformer à une métrique spécifique, avec un certain degré d'erreur.
Spécifications fonctionnelles décrivent le comportement attendu d'un système logiciel. Spécifications du programme décrire ce que le logiciel est censé accomplir. Ceci diffère d'une fonctionnalité spécification en ce que, tandis qu'une spécification de programme décrit ce que fait le système, la spécification fonctionnelle décrit la manière dont il le fait.
Je vous suggère de travailler pendant un certain temps avec cas d'utilisation. Au niveau utilisateur, les cas d'utilisation sont la façon dont vous décrivez le comportement du système, tandis qu'au niveau du code, la façon dont vous décrivez le comportement du système est avec des tests unitaires. Les deux techniques peuvent être utilisées pour dériver des spécifications fonctionnelles. Lorsque vous étoffez le comportement du système avec des cas d'utilisation, il devrait devenir plus clair à quoi devrait ressembler l'API.
Vous commencez par créer une liste informelle de cas d'utilisation. Ce document résume le processus, tout comme celui-ci . Une fois que vous avez des cas d'utilisation, vous pouvez commencer à en créer des exigences fonctionnelles.
Exemple
Lorsque le véhicule réservé n'est pas disponible en raison de retours tardifs, le client est informé de la situation et informé des autres types de véhicules disponibles. Le client se voit offrir une incitation à accepter un autre type de véhicule. Si le client n'est pas satisfait, la réservation est annulée sans pénalité. Le client accepte un autre type de véhicule ou annule la réservation.
Plusieurs exigences fonctionnelles peuvent être dérivées de ce cas d'utilisation:
- Le système doit indiquer quand un véhicule n'est pas disponible et la raison.
- Le système doit fournir une liste des autres véhicules disponibles.
- Le système doit fournir une liste des incitations possibles.
- Le système doit permettre de choisir un autre véhicule.
- Le système doit permettre d'annuler la réservation.
Etc. À partir d'une telle liste d'exigences fonctionnelles, les éléments qui doivent être présents dans l'API devraient devenir facilement apparents.