De nature complexe, le contenu inclut souvent une information agrégée et de multiples objets.
L'architecture de solution s'attaque à cette complexité par des mécanismes conceptuels considérant le cycle de vie du contenu influençant les aspects variés de son traitement en relation avec son intégration aux applications et processus d'affaires.
SRS
Le SRS (Solution Requirement Specification) est un document qui décrit les besoins fonctionnels du client basé sur la compréhension de son contexte et de ses objectifs d'affaires. Ces besoins sont documentés et figés à la date d'approbation et habituellement requis avant le début de la réalisation du développement de la solution. Ce livrable permet de s'assurer d'une compréhension commune entre le client et InterDoc, des travaux à réaliser et fait office de contrat entre les deux parties.
Le contenu du SRS précise de façon explicite et en langage fonctionnel les intrants et extrants attendus de la solution ainsi que son comportement d'un point de vue utilisateur. Il décrit également les éléments qui ne seront pas inclus ou supportés par la solution. Le SRS permet de préciser la portée du projet et d'éviter les dépassements de coûts en cours de réalisation. Le SRS est souvent considéré comme le document "maître" puisque tous les autres documents inhérents au projet tels que le SDD, le fractionnement des tâches, l'architecture logicielle, le plan de test et de validation ainsi que le guide de l'utilisateur sont dérivés de ce dernier.
Il est important de mentionner que le SRS contient habituellement des requis fonctionnels ou non fonctionnels, mais ne doit pas en général offrir des pistes de conception de la solution, des orientations technologiques, des approches de développements ou toute autre facette qui relève davantage des compétences de l'équipe de conception et de développement de la solution.
Les critères de qualité de la conception d'un SRS doivent rencontrés les 4 principaux objectifs suivants :
- Permet d'obtenir l'aval du client
- Procure un intrant aux spécifications logicielles
- Sert de document de référence lors du développement de la solution
- Sert de document de référence lors de la validation et des tests
SDD
Le SDD (Solution Design Document) décrit les spécifications du système et logicielles de façon précise, concise et non ambigüe. Ce document permet de spécifier non seulement la structure, mais également le comportement organique de l'application. Le SDD est orienté sur le développement du modèle de la solution la plus optimale afin d'implanter les spécifications fonctionnelles définies dans le SRS.
Le SDD doit permettre aux développeurs de simuler le comportement de l'application afin de vérifier et de valider les attentes auprès des utilisateurs et propriétaires de la solution dès le début de la réalisation. Cette étape permet de confirmer que la conception logicielle est conforme aux spécifications fonctionnelles. Le SDD permet de contrôler la portée de la solution en documentant toute demande de changement du client aux spécifications de la solution et des impacts sur la conception logicielle.
Le SDD procure un document de référence afin d'évaluer les efforts de développement requis, la conception des plans de test et la documentation du système. Il fournit les balises, guides et approches de développement à respecter lors de la réalisation de la solution. Il permet également de suivre méthodiquement l'état d'avancement des travaux pour chacune des composantes logicielles de la solution.
Les critères de qualité de la conception d'un SDD doivent rencontrer les 4 principaux objectifs suivants :
- Permet de valider la compréhension des spécifications fonctionnelles
- Permet de valider la portée et d'estimer les efforts de réalisation
- Procure une approche et un encadrement lors du développement
N'hésitez pas à nous contacter pour de plus amples informations.