Comment puis-je écrire un document de spécification technique pour mon projet de logiciel ?

Question

J'ai vu à quelques questions autour d'ici disent qu'il n'y a pas besoin d'écrire un costaud Spécification Technique si la Spécification Fonctionnelle dispose de toutes les fonctionnalités. Ce que les situations où le client a fourni une Spécification Fonctionnelle et vous avez besoin de tourner autour d'une Spécification Technique de ce document?

Je comprends que, dans une société de l'écriture de petits Spécifications Techniques concentrer sur des parties de la solution est utile, mais si la production de la Spécification Technique est un jalon/livrable avec la visibilité de nos clients qu'est-ce que la meilleure façon d'aborder l'écriture?

Que faire si je ne sais pas exactement comment je vais le mettre en œuvre un certain morceau de fonctionnalité, car je n'ai pas créé avant? Comment pouvez-vous écrire à la Spécification Technique d'une manière qui a joué vers le bas comme une catastrophe?

Je suis à la recherche de modèles de/conseils/les meilleures pratiques de suggestions et toute expérience du monde réel qui peut m'aider à créer le genre de document qui peut être utilisé pour de futurs projets de cette nature.

Answer 1

1. Définir les objectifs du projet
2. Définir l'architecture du système et de l'infrastructure
3. Définir l'utilisateur dialogues et le flux de contrôle
4. Définir les tâches en arrière-plan
5. Définir le modèle de base de données
6. Définir les interfaces à d'autres les systèmes de
7. Définir les exigences fonctionnelles (temps de réponse, sécurité, ...)
8. Définir un dictionnaire pour tous les concepts pertinents/entités (dangereux, vous pouvez omettre celui-ci)

Ne soyez pas trop précis sur le système de fonctionnement interne.

Answer 2

Joel a écrit à ce sujet sur son blog:

• Les Spécifications Fonctionnelles Sans - Partie 1: Pourquoi S'Embêter?
• Les Spécifications Fonctionnelles sans - Partie 2: qu'est Ce qu'un Spec?
• Les Spécifications Fonctionnelles Sans - Partie 3: Mais... Comment?
• Les Spécifications Fonctionnelles Sans - Partie 4: Conseils

Answer 3

Vous devriez commencer avec un croquis de conception d'ensemble de la solution. Vous en savez probablement plus que ce que vous pensez à propos de l'architecture retenue. Par exemple: avez-vous besoin d'une base de données? un serveur d'application? les services web? client de bureau? les clusters?

Puis vous commencez à développer les composants et commencez à vous poser quelques questions de base selon les technologies que vous pensez sont les plus appropriées selon le domaine de la problématique et de vos connaissances. Par exemple: Java ou .NET? Django ou Ruby-on-Rails? JBoss ou Tomcat? Metis ou Apache? Oracle ou MySQL?

Ensuite, vous allez dans les détails. Vous n'êtes toujours pas la mise en œuvre de rien, c'est juste un document préliminaire, et il est très probable que vous allez changer votre esprit à mi-chemin à travers le développement de toute façon. Demandez-vous si vous allez avoir besoin d'un ORM, un cadre, une bibliothèque, d'un appareil dédié. Par exemple: (N)Hibernate ou Toplink? Le printemps? JSF? Struts? Appareil de poche? Lecteurs de codes-barres? Ne mettez pas l'un de ces dans la spécification technique, sauf si il vous oblige à changer quelque chose (c'est à dire des problèmes d'incompatibilité).

Maintenant, il est temps de tout revoir de nouveau.

Rechercher sur le web pour des solutions de rechange, les nouveautés de l'un des composants, des projets similaires, open source concurrents.

Ajouter des détails, corriger les erreurs, la recherche d'informations pour les composants que vous avez été vague sur.

Demandez à vos collègues de relire votre document.

Ne posez pas de détails inutiles, d'essayer d'aborder les grands problèmes d'échelle, pas le petit optimisations. Se concentrer sur ce que vous connaissez le mieux. Créer un pic de la solution chaque fois que vous en avez envie.

Chaque fois que vous faites un commentaire, vous feriez mieux de comparer l'architecture de l'esquisse à l'encontre des exigences (n'oubliez pas les exigences non fonctionnelles).

En faire un processus itératif, de sorte que vous pouvez améliorer et toujours avoir un livrable prêt en tout temps pour les examens par des pairs et la collaboration. Aussi, si le client est satisfait avec le niveau de détail que vous avez réalisé, vous feriez mieux d'arrêter de sorte que vous pourriez vous concentrer sur la phase de développement.

Answer 4

Vous pourriez peut-être utiliser la structure de ce document

http://reat.space.qinetiq.com/ssat/docs/ssat_ssd.pdf

1 INTRODUCTION 8
1.1 Contractuelles 8
1.2 But du Document 8
1.3 Champ d'application du Logiciel 8
1.4 Définitions, acronymes et abréviations 8
1.5 Références 9
1.6 Présentation du document 9

2 MODÈLE LOGIQUE DE DESCRIPTION 11

3 EXIGENCES SPÉCIFIQUES 13
3.1 exigences Fonctionnelles 13
3.1.1 de l'Utilisateur de l'interface d'entrée (SR 1) 13
3.1.2 de l'Utilisateur de l'interface de sortie (SR 2) 13
3.1.3 Geantino définition de la source – échantillonnage des particules (SR 3) 13
3.1.4 le suivi de Particules (SR 4) 15
3.1.5 Histogramming de données (SR 5) 15
3.1.6 la Géométrie description (SR 6) 16
3.1.7 Exécuter la répétition (SR 7) 16
3.2 exigences de Performance (SR 8) 16
3.3 exigences d'Interface (RS 9) 16
3.4 exigences Opérationnelles (RS 10) 16
3.5 exigences en matière de Vérification (SR 11) 16
3.6 tests d'Acceptation des exigences (SR 12) 16
3.7 la Portabilité des exigences de 16
3.7.1 Plate-forme, le système d'exploitation et le compilateur (SR 13) 16
3.7.2 la Transférabilité à d'autres plates-formes (SR 14) 17
3.8 exigences de Qualité (SR 15) 17
3.9 exigences de Maintenabilité (SR 16) 17
3.10 Autres exigences

4 CONCEPTION DU SYSTÈME 18
5 DESCRIPTION DES COMPOSANTS DE 20
5.1 principales 20
5.1.1 Type 20
5.1.3 les Interfaces de 20
5.1.4 les Dépendances de 20
5.1.5 Données 20
5.1.6 Ressources 20
5.1.7 exigences de Logiciels rencontré 20
5.2 MyGeometryConstruction 20
5.2.1 Type 20
5.2.2 Fonctions 21
5.2.3 Interfaces 21
5.2.4 Dépendances 21
5.2.5 Données 21
5.2.6 Ressources 21
5.2.7 les exigences du Logiciel s'est réuni le 21

...
...

6 EXIGENCES DE L'UTILISATEUR CONTRE LES LOGICIELS DE TRAÇABILITÉ DES EXIGENCES
MATRICE 38
7 EXIGENCES DE LOGICIELS VERSUS COMPOSANTS DE LA MATRICE DE TRAÇABILITÉ
41

Answer 5

Intéressant - de mon côté, je commence toujours à partir d'un très haut niveau technique spec (.NET, HTML5, CSS3, AJAX, SQL Server DB, MS Windows Server split DB et de du Serveur Web de Couches, 2x pare-feu Matériels, 2x Logiciel de pare-feu, etc) que je sais déjà que je vais utiliser.

Ensuite, je prends mon Fonctionnalités de la Spécification et je regarde la base DB structure et la modélisation des données.

À partir de là, je regarde les intégrations 3ème partie des systèmes, particulièrement les méthodes de communication et les formats de fichier (par exemple, XML via HTTPS post à un Service Web vs CSV via sFTP sur une tâche planifiée). Puis je regarde les fréquences, de l'ordre de transferts de données (liées à des dépendances dans les fichiers), et la gestion des erreurs de pannes de communication entre les systèmes.

La spécification technique j'écris est alors placé sur la version de la fonctionnalité cahier des charges avec les spécifications techniques décrites pour chaque fonctionnalité de l'élément.

À la fin de la journée à la spécification technique est un produit livrable dans son propre droit, et si suffisamment détaillée peut être utilisée comme base pour le plan de projet et de plan de tests.

J'ai toujours ouvrir avec une table des matières et un niveau élevé diagramme Visio de l'ensemble du flux de la solution. Cela permet au lecteur de sauter à la partie qui est directement applicable.

J'espère que ça aide.