IEEE SRS Documents: Version légère lorsque vous travaillez avec des entrepreneurs extérieurs?
En règle générale, nous suivons un processus de développement agile qui a tendance à ne pas mettre l'accent sur les exigences d'écriture et les documents techniques que personne ne lira. Nous avons tendance à concentrer notre main-d'œuvre limitée aux activités de développement et de test avec la conception et le tableau blanc collaboratif comme mise au point essentielle.
Il existe une composante Web essentiellement autonome qui prendra quelques semaines à développer, mais ce travail peut être surtout parallèle à d'autres travaux de projet. Pour essayer de rattraper le temps, j'ai reçu un budget d'embauche d'un développeur sur Odesk pour compléter ce travail.
Alors que mon équipe n'est pas habituée à travailler d'un document SRS ferme, je me rends compte que, avec un développement externalisé qu'il est une bonne idée d'être aussi ferme et spécifique que possible, donc je me rends compte que je dois fournir des exigences détaillées et des spécifications techniques document pour ce travail à faire correctement.
Lorsque je vais écrire un document d'exigences, j'utilise généralement le modèle de document SRS standard IEEE SRS, mais je pense que c'est trop verbeux et probablement surtomuci pour ce que je dois communiquer à un développeur. Existe-t-il un autre document d'exigences qui est plus léger et également accepté par une grande organisation de normes comme l'IEEE?
En outre, comme ce qui sera développé en tant que module logiciel qui interagira avec d'autres modules logiciels, mes exigences devraient vraiment approfondir les spécifications techniques pour que les éléments fonctionnent correctement. Dans ce scénario, il est logique de fusionner les spécifications techniques et des exigences dans un seul document, et sinon, quelle est une alternative viable?
La meilleure option est probablement de prendre un Modèle existant ou deux (pour l'achat - également trouvé dans les annexes de exigences logicielles ) ou trois et les adapter. Supprimer les sections sans rapport avec vos besoins ou ajouter de nouvelles sections que vous aimez d'un modèle dans le reste d'un autre gabarit. Fusionner des sections ensemble si cela a du sens. Lorsqu'ils sont combinés, ceux-ci couvriraient probablement tous les types de question possibles qui pourraient être posés, il s'agit simplement d'une question de remplissage dans les détails où ils sont nécessaires.
L'adaptation ne ferait pas de correspondre aux modèles d'organisations de normes majeures, mais la mesure de l'adaptation est une composante essentielle des programmes d'amélioration et de déploiement de processus. Je ne pense pas que quiconque aurait un problème avec un modèle sur mesure, dans la plupart des cas. Pour moi, l'élimination explicite des sections rend un document plus agréable et plus lecteurs que de texte qui dit "ne s'applique pas".
En ce qui concerne les spécifications, je serais hésitant sur ce qui est fourni. Si vous fournissez des entrées dans un format spécifié, fournissez ce format. Si un autre système prendra des sorties, fournissez le format de sortie attendu. Celles-ci pourraient être des diagrammes de chemin de fer, des schémas XML, des cartes de mise en page d'octet et de tout exemple d'entrées/sorties (désinfectées, si nécessaire). Si vous spécifiez quelque chose qui doit être remplacé par un autre système, la spécification de l'interface publique peut également être nécessaire. Cependant, je recommanderais de laisser autant de marge de manœuvre au développeur que possible de concevoir et de créer un système autour de vos besoins.
Dans mes expériences, il existe souvent une séparation des exigences du système et une description détaillée des interfaces entre les composants. Je ne pense pas que cela soit toujours nécessaire, cependant. La conformité à une interface spécifiée est techniquement une exigence de communication ou d'environnement ("le système doit fournir une sortie XML conforme au schéma défini dans le fichier de schéma"). La séparation des deux est probablement plus appropriée lorsque vous décrivez un système de composants associés plutôt qu'à un seul composant, où je dirais que disposer d'une seule ressource complète pour ce que je suis attendu à produire est préférable.
Je recommande de m'approcher cela comme définissant uniquement ce dont vous avez besoin de ce système, laissant autant que possible au développeur. Si vous passez trop de temps à faire la spécification de manière à ce qu'il n'y ait qu'une ou deux solutions, vous avez terminé la majeure partie du travail intensif du temps (dans mon expérience). En tant que développeur vous-même, vous savez probablement quelles questions vous pourriez poser si vous avez été présentées avec la portée générale du système que vous souhaitez - répondez à ceux comme clair et spécifiquement que possible et espérons que le développeur posera toute autre question que vous n'avez peut-être pas pensée à .