Document de spécification fonctionnelle / Document de exigences (FSD / FRD)

Le Document de Spécification Fonctionnelle (DSF) dans le développement de logiciels est un document formel qui décrit les fonctions de la

logiciel / système ou ses composant(s). Une fonction peut être décrite comme un ensemble d'entrées, le comportement et prévu / exceptionnel

sorties.

Les exigences fonctionnelles peuvent être des calculs comme la logique métier, le modèle de revenus ou des formules, des détails techniques, la manipulation de données

& traitement et d'autres fonctionnalités spécifiques qui définissent ce qu'un système est censé accomplir. C'est un document intermédiaire

entre le document de exigences commerciales (BRD) et le document technique / de conception.

Les exigences fonctionnelles peuvent également couvrir les exigences comportementales.

Les exigences fonctionnelles sont soutenues par des exigences non fonctionnelles (également appelées exigences de qualité), qui imposent des contraintes sur le

conception ou mise en œuvre (tels que les exigences de performance, de sécurité, d'accessibilité, d'évolutivité, de fiabilité, etc.).

En général, les exigences fonctionnelles s'expriment sous la forme "le système doit faire <<exigence>>", tandis que les exigences non fonctionnelles sont

« le système doit être <<exigence>> ».

Le plan de mise en œuvre des exigences fonctionnelles est détaillé dans la conception du système. Le plan de mise en œuvre pour les exigences non fonctionnelles

les exigences sont détaillées dans l'architecture du système.

Cela vous permettra également de gérer les attentes de vos clients ou de votre direction, car ils sauront exactement à quoi s'attendre.

Remarque : Il est préférable d'obtenir l'approbation du FSD par les parties prenantes (Client, Architecte, Équipe Technique et QA) afin de garder tout le monde sur la même longueur d'onde.

synchronisé et pour éviter de retravailler dans les étapes ultérieures.

Qu'est-ce qu'un système ?

La terminologie de la boîte noire "Système" comporte des "Interfaces" et des "États". Les Interfaces sont celles par lesquelles des entités externes (humaines et

d'autres sous-systèmes, généralement appelés utilisateurs) peuvent interagir avec le système par le biais d'entrées et de sorties. Les états sont le résultat des interactions

avec les utilisateurs en fonction des fonctions choisies et des données fournies.

Consider the eCommerce site as a system and its login feature as an example of a feature/component of the system. The following
Il y a quelques scénarios d'utilisation qui doivent être pris en compte lors de la description du flux fonctionnel et du comportement/UI pour chaque scénario.

le FSD :

1. L'utilisateur s'inscrit lors du passage à la caisse et est donc connecté.

2. L'utilisateur s'enregistre d'abord, se connecte et ensuite fait des achats.

3. L'utilisateur déjà enregistré se connecte d'abord avant d'acheter.

4. L'utilisateur déjà inscrit se connecte lors du paiement.

5. Already registered user cannot login due to incorrect login credentials.

 6. Utilisateur déjà enregistré, réinitialiser le mot de passe via le lien de mot de passe oublié et se connecter.

7. Utilisateur déjà enregistré rencontrant un compte verrouillé lors de la tentative de connexion.

8. Compte verrouillé utilisateur, réinitialisation du compte et connexion.

9. Un utilisateur déconnecté se reconnecte pour faire des achats.

10. Un utilisateur affilié se connecte et fait des achats.

Remarque : Les exemples ci-dessus, diverses fonctions comme la validation du nom d'utilisateur et du mot de passe ne sont pas mises en évidence ici. Bien que

dans les scénarios ci-dessus, « Checkout » est un composant distinct lié à un autre composant appelé « Panier ».
les scénarios d'intégration ne sont pas expliqués dans ce post.

Pourquoi écrire un FSD ?

FSD simplifie le processus de développement en incorporant toutes les fonctions et les données utilisées respectivement.

2. Chaque ingénieur travaillant à partir du FSD a toutes ses questions sur le système répondues pour commencer à le construire.

3. L'utilisation du FSD approuvé par les parties prenantes garantit le développement d'un système qui répond exactement aux attentes du client.

Produire un FSD complet (clair, sans ambiguïté et compréhensible) est une tâche ardue. Cela peut contenir plusieurs sections.
détaillant chacune des exigences nécessaires à la réalisation du projet. Ainsi, la rédaction de cela nécessite une certaine expertise dans le domaine et est

généralement écrit par des BA ou des PME.

Pour atteindre la compréhension :

Soyez cohérent dans le style et la mise en page – Utilisez des titres et une mise en forme

Numérotation des articles et points de manière appropriée – Utilisez des abréviations et définissez-les dans le glossaire

Utilisez des diagrammes pour les lecteurs visuels en plus des descriptions textuelles.
Diviser le texte avec des captures d'écran, des tableaux et d'autres éléments graphiques

Développez des scénarios détaillés et légers - utilisez des termes clairs et gardez des phrases simples.

Définir le Système - Quel est le système censé être, censé faire, utilisateurs, métriques et tout précédent pour ce système.
Développer des modèles – Modèle conceptuel de l'utilisateur (cas d'utilisation) et modèle du designer (diagrammes Visio).

Define Information Flow–Navigational Elements, Organization of Information, Prototype, Wireframes and Mockups
Écrivez la fonctionnalité - Couvrir tout, utiliser des captures d'écran, écrire de manière concise, correcte et cohérente.

Couverture de la fonctionnalité - Pour chaque écran, couvrez tous les éléments et leurs fonctions et données du coin supérieur gauche au coin inférieur droit.

coin.
Passez en revue le document - Vérifiez la table des matières, corrigez le document et enfin examinez-le à partir de la version papier de celui-ci.

What is in the FSD?

Le format conventionnel du FSD contient des informations sur le Contrôle d'Identification, les Exigences Métier Pertinentes, Fonctionnel

Comportement et contrôle de navigation de l'interface utilisateur, données et logique commerciale, et critères de qualité.
Spécification des exigences logicielles (SRES)

« Le nôtre est un monde où les gens ne savent pas ce qu'ils veulent et sont prêts à passer par l'enfer pour l'obtenir. » – Don Marquis

Une spécification des exigences logicielles (SRS) est une description complète de l'objectif et de l'environnement prévus.

pour un logiciel en cours de développement. Le SRS décrit en détail ce que le logiciel fera et comment il est censé fonctionner.

An SRS minimizes the time and effort required by developers to achieve desired goals and also minimizes the development cost. A
good SRS defines how an application will interact with
matériel système, autres programmes et utilisateurs humains dans une grande variété de situations réelles.

Des paramètres tels que la vitesse de fonctionnement, le temps de réponse, la disponibilité, la portabilité, la maintenabilité, l'empreinte, la sécurité et la vitesse de récupération

les événements indésirables sont évalués.

Les méthodes de définition d'un SRS sont décrites par la spécification IEEE (Institute of Electrical and Electronics Engineers) 830-1998.
Un SRS décrit le comportement essentiel d'un produit logiciel du point de vue d'un utilisateur. Le but du SRS est de :
1. Établir les bases de l'accord entre les clients et les fournisseurs sur ce que le produit logiciel doit accomplir.

La description complète des fonctions devant être exécutées par le logiciel spécifié dans le SRS aidera l'utilisateur potentiel à
déterminer si le logiciel spécifié répond à leurs besoins ou comment le logiciel doit être modifié pour répondre à leurs besoins

[Link] une base pour développer la conception du logiciel.

Le SRS est le document de référence le plus important dans le développement d'un design.

3.Réduire l'effort de développement.

La préparation du SRS force les différents groupes concernés au sein de l'organisation du client à examiner de manière approfondie tous les aspects.

les exigences avant le début des travaux de conception. Un SRS complet et correct réduit les efforts gaspillés en re-conception, re-codage et

le retest. Un examen attentif des exigences dans le SRS peut révéler des omissions, des malentendus et des incohérences tôt.
dans le cycle de développement lorsque ces problèmes sont plus faciles à corriger

[Link] une base pour estimer les coûts et les délais.

La description du produit à développer, telle que donnée dans le SRS, constitue une base réaliste pour estimer les coûts du projet et peut être

utilisé pour obtenir l'approbation des offres ou des estimations de prix

[Link] une base pour la validation et la vérification.

Les organisations peuvent développer leur documentation de test de manière beaucoup plus productive à partir d'un bon SRS. Dans le cadre du développement

le contrat, le SRS fournit une base de référence contre laquelle la conformité peut être mesurée

[Link] le transfert.
Le SRS facilite le transfert du produit logiciel à de nouveaux utilisateurs ou de nouvelles machines. Les clients trouvent ainsi plus facile de

transférer le logiciel à d'autres secteurs de leur organisation et les fournisseurs le trouvent plus facile de le transférer à de nouveaux clients

7. Servir de base à l'amélioration.

Parce que le SRS parle du produit mais pas du projet qui l'a développé, le SRS sert de base pour la suite.
enhancement of the finished product. The SRS may need to be altered, but it does provide a foundation for continued product
évaluation.
Conclusion

Analyste d'affaires contre Analyste système

Les termes Analyste d'affaires (BA) et Analyste système (SA) sont souvent utilisés de manière interchangeable pour décrire le même poste. En fait, le

les deux sont des rôles complètement différents avec des descriptions et des devoirs distincts. Laissez-moi essayer d'expliquer les différences entre les BA et les SA.

et énumérez également quelques points communs partagés par ces postes.

Rôles d'un analyste système ?

Les SAs utilisent les systèmes informatiques d'une organisation pour aider à atteindre des objectifs commerciaux stratégiques. Ils peuvent concevoir et développer de nouveaux systèmes par

configurer du nouveau matériel et des nouveaux logiciels, ou utiliser des systèmes existants de nouvelles manières pour accomplir des résultats supplémentaires ou différents.

Les tâches typiques effectuées par les SA comprennent :

Consulter la direction et les utilisateurs pour déterminer les besoins du système.

Concevoir un système pour répondre aux objectifs commerciaux.

Spécification des entrées et formatage des sorties pour répondre aux besoins des utilisateurs.

Utiliser des techniques telles que l'échantillonnage, la construction de modèles et l'analyse structurée, avec des principes comptables, pour assurer le

la solution est efficace, rentable et financièrement réalisable.

Développer des spécifications, des diagrammes et des flux pour que les programmeurs puissent les suivre.

Superviser la mise en œuvre, coordonner les tests et observer le démarrage du système pour valider les performances.
Compétences pour un analyste de systèmes

En général, un diplôme de licence est requis lors de l'embauche des SA, généralement dans un domaine technique tel que l'informatique ou les technologies de l'information.

ingénierie ou systèmes d'information. Cependant, ceux qui possèdent un diplôme en commerce combiné avec l'informatique sont préférés.
des compétences. D'autres recherchent une expérience liée à l'industrie, telle que la finance, les télécommunications ou la santé, ainsi que des compétences techniques.
En général, le poste de SA exige une connaissance technique plus approfondie, tandis que le poste de BA nécessite une meilleure compréhension de la

les complexités des problèmes d'affaires et l'utilisation de la technologie pour les résoudre.

Rôles d'un analyste commercial ?

Les BA possèdent généralement également des connaissances techniques. Leur principal objectif est d'identifier des opportunités d'amélioration pour une entreprise.

des processus et l'utilisation de la technologie pour éliminer les problèmes qui affectent la productivité, la production, la distribution et, en fin de compte, le résultat net. Donc,

Savoir comment la technologie peut résoudre les problèmes commerciaux est essentiel pour le succès d'un analyste métier. Les analystes métier nécessitent un degré élevé de compétences spécialisées dans

ordre de résoudre les problèmes commerciaux à travers une variété de devoirs qui incluent :

Analyser les processus commerciaux d'une organisation pour en identifier les inefficacités.

Faire des recommandations pour des solutions ou des améliorations qui peuvent être réalisées grâce à de nouvelles technologies ou à des utilisations alternatives de

technologie existante.
Agissant en tant que liaison entre les parties prenantes de l'entreprise, telles que la direction, les clients ou les utilisateurs finaux, et le développement logiciel

équipe des technologies de l'information.

Analyser et communiquer les besoins des parties prenantes en traduisant les exigences commerciales en exigences fonctionnelles logicielles.

Documenter et évaluer les données et informations requises.

Utiliser la modélisation, les tests et les modèles de données pour améliorer le flux d'informations au sein d'une organisation afin d'augmenter le succès des projets.

Compétences pour un analyste commercial

Devenir un BA réussi nécessite un mélange de compétences techniques et de sens des affaires, ainsi qu'un degré élevé de confiance – généralement

acquise grâce à une éducation adéquate, une formation en analyse commerciale et de l'expérience. De nombreux BAs professionnels font leur entrée dans le domaine en

obtenir un diplôme en technologie de l'information, en administration des affaires, en finance ou dans un domaine connexe, ou par expérience professionnelle, puis

poursuivre une formation spécialisée. Les certifications professionnelles deviennent de plus en plus précieuses, car les employeurs demandent de plus en plus cela.

crédits respectés.

Attributs des analystes commerciaux et des analystes systèmes

Solides compétences en résolution de problèmes et en analyse, compétences en communication et interpersonnelles, et capacité à se concentrer avec une attention particulière sur

des détails sont nécessaires pour le BA et le SA. Un BA a besoin d'une large base de connaissances sur les affaires et de compétences essentielles bien aiguisées.

tandis que l'ensemble de compétences de l'AS est plus technique.

Analyste système ≠ Analyste commercial

Bien qu'il existe certaines compétences et exigences de connaissances communes entre les SAs et les BAs, la profession de BA nécessite un ensemble totalement différent.

ensemble différent de compétences spécialisées essentielles impliquant l'interrogation, l'analyse, la communication, les tests et la vérification des exigences, ainsi que la capacité

Identifier des opportunités pour résoudre des problèmes d'entreprise et améliorer les processus. Les analystes d'affaires sont des experts fonctionnels qui travaillent pour le changement et

amélioration, aidant les organisations à atteindre leurs objectifs stratégiques grâce à des améliorations technologiques continues et réussies.