Lors de l'examen des spécifications des besoins, quels "péchés capitaux" & # 8221; doit être adressé? [fermé]

Question

Lors de l'examen des spécifications d'exigences (qui incluent des exigences fonctionnelles, des exigences non fonctionnelles, des contraintes, etc.), quelle que soit leur importance, ce sont les "péchés capitaux". commis par les auteurs à surveiller?

Veuillez ne pas énumérer plus de 7 choses essentielles (par ordre de gravité décroissante) indiquant que le fait de spécifier (ou non) la spécification des exigences a un effet négatif sur la qualité du logiciel. Moins de 7, c'est parfaitement correct.

Answer 1

OK, il s’agit de plus de 7 personnes, mais les bonnes exigences ont les attributs suivants:

• Unique . Y a-t-il d'autres des exigences similaires?
• Identifiable , est-ce que le exigence doit-elle être identifiée de manière unique? Peut-il être suivi tout au long de votre processus de développement?
• Terminer . Est-ce qu'il manque quelque chose ou oublié? Est-ce minutieux? Le fait-il inclure tout le nécessaire pour faire il est seul?
• Précis . Est-ce correct? Est-ce qu'il définit correctement le objectif? Y a-t-il des erreurs?
• Sans ambiguïté . Est la description exacte et pas vague? Y a-t-il une interprétation unique? Est est-il facile à lire et à comprendre?
• Cohérent . La description de le long métrage écrit pour qu'il n'entre pas en conflit avec d'autres éléments de la spécification?
• Pertinent . La déclaration est-elle nécessaire? à la fonctionnalité? Est-ce extra information qui devrait être laissée de côté? Est-il traçable à un besoin initial du client?
• Faisable . Peut-il être mis en œuvre avec le disponible personnel, outils et ressources dans les limites du budget spécifié et calendrier?
• Sans code . Est-ce que la spécification s'en tenir à définir le produit et pas la conception logicielle sous-jacente, architecture et code?
• Testable . Peut-il être testé? Est assez informations à condition qu'un testeur pourrait créer des tests pour vérifier que l'exigence est satisfaite?
• Priorité . Est-ce plus ou moins important que d'autres exigences?
• Utilise la voix active . Est-ce que le spécification utiliser la voix active? La voix passive ne spécifie pas toujours qui ou quoi effectue l'action.
• Classés par catégorie . Est l'exigence logiquement groupé avec similaire exigences? Catégories possibles sont: comportemental, performance, Interface, structures de données / éléments, Mise en œuvre, conformité / qualité, Opérationnel (fiabilité, sécurité, Sécurité), dérivé / d'ingénierie.

Un bon outil de suivi des exigences peut automatiser / appliquer certains des éléments ci-dessus, tels que Identifiable, Priorisé, Catégorisé, mais seul un examen par l'équipe peut vérifier le reste. L'essentiel est de former votre équipe à ces attributs, de la mettre en pratique en lisant à la fois des exemples positifs et négatifs d'exigences et de mettre en place un processus de révision efficace qui vérifie les exigences suffisamment tôt dans votre cycle de vie pour avoir un impact sur les activités en aval.

Answer 2

Exigences manquantes - Beaucoup plus difficiles à détecter. Séparer les exigences en sections claires (sécurité, performances, mise en forme, etc.) peut en faciliter la compréhension.

Answer 3

Caractéristiques, Temps, Qualité - Choisissez-en deux. assurez-vous que les exigences n'imposent pas les trois à votre équipe.

Répondez aux exigences qui tentent de contrôler votre processus.

Demandez une hiérarchisation claire dès le début.

Insistez sur des critères d'acceptation clairs pour chaque exigence.

Answer 4

Les exigences doivent être spécifiques et non ambiguës en ce qui concerne les besoins, mais elles devraient l'être moins quant à la manière de les satisfaire.

Answer 5

Faire des hypothèses - vérifiez que tout ce qui ressemble à une hypothèse a bien été vérifié.

Answer 6

Answer 7

Exigences qui ne sont pas faciles à vérifier comme étant remplies - Changez pour un formulaire qui peut être plus facilement marqué comme étant rempli ou non lors de l'examen.

Answer 8

L'exigence ne spécifie pas qui / quoi fait la chose.

"The invoice is reconciled to the purchase order."

Cela signifie-t-il que le système fait quelque chose ou que l'utilisateur?

Answer 9

Le pire que j'ai vu sur un projet pour lequel j'ai codé: -

The system shall interface to SAP as required.

Tout d'abord, une exigence avec " à la demande " dans c'est stupide. Cette ligne doit avoir coûté 400 k $. Le client ne cessait de le pointer et de dire qu'il disait que vous feriez bla, bla, bla.

Answer 10

Trop strict - Si possible, spécifiez les tolérances appropriées.

Answer 11

Les exigences ambiguës sont mauvaises.

Les exigences invérifiables et non quantifiables sont doublées.

Answer 12

Naturellement, tout dépend du type d’exigence que vous obtenez. Je suis habitué aux applications graphiques ou Web typiques, aux traitements par lots et aux

• Commencez par définir les normes qui ne doivent pas être définies dans chaque spécification, reportez-vous à elles
• Faites-le aussi petit que possible - il est rare de pouvoir lire un document de 200 pages tout en gardant à l'esprit
• Soyez spécifique, mesurable, concret
• Faites des exemples (dessins, écritures comptables)
• Expliquez le but avant de décrire la fonction
• Inclus les standards de performance, les standards de résilience, les instructions de déploiement, la documentation des opérations nécessaires

J'ai également un seul conseil pour le relecteur: connaissez votre sujet

Vous devez avoir une connaissance très détaillée du contexte de l'exigence, des besoins spécifiques du client, de l'environnement technique et peut-être du plus important à qui cette exigence sera adressée et de son niveau de compréhension globale.

J'ai fait une très mauvaise expérience de projets avec de nombreuses personnes qui ont révisé les spécifications, leurs connaissances individuelles étant très superficielles. Vous obtenez le retour au même niveau, principalement des corrections formelles, mais les profondes lacunes de la spécification ne seront découvertes que très récemment dans le projet.

Answer 13

Évitez les mots malicieux: toute langue pouvant être arrachée de son contexte et mal interprétée est mauvaise.

Assurez-vous que tout est parfaitement clair: vague == Bad Thing (tm)

Answer 14

Ma recommandation et ce que je fais toujours avant un nouveau projet est de vérifier la liste de contrôle sur Page 42,43 de Code terminé de Steve McConnell

Answer 15

Le wikpedia Tout savoir a un bon résumé pour les exigences - http: //en.wikipedia. org / wiki / Requirement # Good_requirements . Je dirais que de ces points, le plus commun est le manque de vérifiabilité. Comprendre la situation dans son ensemble est important dans la vie, cependant, vous devez énoncer explicitement les choses dans vos exigences, ex. Le système doit réagir rapidement. Au lieu de cela, le système doit répondre à toutes les demandes en moins de 2 secondes.

Answer 16

• Séparation des exigences fonctionnelles, architecturales, d’interface et non fonctionnelles.
• Utilisation d'une notation non ambiguë et cohérente pour décrire les entités
• Effacement des critères d'entrée et de sortie pour les cas d'utilisation
• Avoir des diagrammes de flux (les cartes de correspondance remplissent le même objectif que UML et sont plus faciles à dessiner)
• Définissez clairement le périmètre, ce qui est couvert et ce qui ne l'est pas et où trouver ceux qui restent inexplorés
• disposer d'une matrice de traçabilité

Answer 17

Vous pourriez envisager de lire certaines des Gestion des exigences et Documents CMMI .

Visitez également la liste de contrôle des exigences et google pour " Critères de bonne exigence ".

Ils sont spécialement conçus pour créer des processus facilitant le développement de logiciels.