03 - SDD - Document de Conception de Solution

Conception de solutions
Document (SDD)
Nom du projet: [Nom et prénom]

Code de projet: [Code à 8 caractères]
Version: XX
Auteur: [Votre nom]
Position: [Ta position]
Téléphone: [Votre numéro de téléphone]
1. E-mail: [Votre adresse e-mail]
[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

Historique du document
Version Responsable Date Remarques

1.0
*** Fin de la
liste de
révision ***
Tableau 1 Historique du document
1. Contact pour les demandes de renseignements et les

modifications proposées
Si vous avez des questions concernant ce document, contactez :
Nom: Marc Dimmick
Désignation: Analyse commerciale du système
Téléphone: (08) 6216 6335
E-mail: Marc.dimmick@dcp.wa.gov.au
Si vous avez une suggestion pour améliorer ce document, complétez et envoyez une copie de
Suggestions pour Améliorations à Documentation .
2. Registre des problèmes

Le relevé des questions reflète les révisions apportées à ce modèle. Ces informations doivent être
supprimées de votre document.
Ver Date Nature de la modification
1.0 12 avril 2006 Document initial
1.1 8 juin Mettre à jour la mise en page et la feuille de style
1.2 23 novembre 06 Mettre à jour la mise en page et le style
1.3 19 juillet 2007 Mettre à jour le logo de l'entreprise

2. Lignes directrices pour remplir ce document :
Les consultants sont tenus de rassembler et de documenter les exigences en consultation avec les
parties prenantes du projet. La responsabilité globale en incombe au chef de projet.
Ce modèle garantit que les détails essentiels relatifs à ces exigences documentent un énoncé clair et
sans ambiguïté des exigences fonctionnelles et non fonctionnelles.
Ce document est utilisé dans le développement, les tests, l'assurance qualité, la gestion de projet et les
fonctions de projet associées.
Les éléments entre crochets doivent être remplacés par le contenu approprié. Par exemple, [Project
Manager] doit être remplacé par le nom du Project Manager.
Ce modèle fournit une structure et un format recommandés ainsi que des exemples de contenu, des
notes explicatives et des questions pour guider et inciter l'auteur.
Veuillez supprimer ces notes et autres directives du document actuel. Ils sont destinés uniquement à
votre information. Ceux-ci sont donnés dans cette couleur et cette police.
Si une section/sous-section n’est pas applicable, ne la supprimez pas. Mentionnez-le plutôt comme tel et
expliquez pourquoi cela ne s’applique pas. N'oubliez pas de faire une vérification orthographique.
Il est préférable d'utiliser la date avec le nom du mois plutôt que le numéro du mois pour éviter toute
confusion (utilisez 2 janvier 2006 ou 2 janvier 2006, au lieu de 1/2/2006 ou 2/1/2006).
Ce document contient des styles préformatés pour les titres. Pour convertir une ligne en titre, sélectionnez
la ligne et choisissez Titre BS 1, Titre BS 2, etc., selon le cas, dans la liste déroulante des styles
adjacente à la liste déroulante des polices.
Table des matières

1 Historique du document 2
1.1 Contact pour les demandes de renseignements et les modifications proposées 2
1.2 Registre des problèmes 2
2 Lignes directrices pour remplir ce document : 3

3 [Client / Projet] 6
3.1 But 6
3.2 Aperçu et statut du projet 6
3.3 Objectifs du projet / Énoncé du problème 6
4 Portée du projet 7
4.1.1 Inclusions 7
4.1.2 Exclusions 7
4.1.3 Phaser si nécessaire 7
4.2 Parties prenantes clés 7
4.3 Documents liés au projet et autres documents de référence 7
5 Aperçu architectural 8
5.1 Interfaces cibles 8
6 Décisions architecturales 9
6.1 Problèmes architecturaux clés 9
6.2 Risques et hypothèses architecturaux 9
7 Description de la solution 10
7.1 Modèle de composant 10

7.2 Réutilisation des composants 10
7.3 Modèle d'information 10
7.3.1 Caractéristiques des informations et des données 11
7.4 Modèle d'infrastructure 11
7.5 Intégration et conception de réseau 11
7.6 Architecture de sécurité 11
7.6.1 Sécurité des applications 11
7.6.2 Sécurité opérationnelle 12
8 Configuration requise 13
8.1 [nom du système/composant] 13
8.1.1 Organigramme pertinent 13
8.1.2 Exigences en matière d'architecture de solution 13
8.1.3 Description de la conception 13
9 Implémentation et migration 14
9.1 Plan de migration de l'architecture 14
9.1.1 Plan de migration 14
9.1.2 Liste des dépendances 14
9.2 GLOSSAIRE 14
10 Exigences fonctionnelles 15
10.1 Exigence – [Titre de la fonction 1] 15
10.2 Les sorties 15
10.3 Écrans 15
10.4 Rapports 15
10.5 Exigence – [Titre de la fonction 2] 15
10.6 Les sorties 16
10.7 Écrans 16
10.8 Rapports 16
11 Contributions 17
11.1 Données 17
11.2 Applications 17
11.3 Tierce personne 17
12 Conception 18
12.1 Couleurs 18
12.2 Regarde et ressent 18
12.3 Problèmes d'utilisabilité 18
12.4 Public 18
13 Performance 19
14 Migration et conversion de données 20
15 ANNEXES 21
15.1 Définitions 21
15.2 Pièces jointes 21
16 Liste de signature 22
les tables
Tableau 1 Historique du document 2

Tableau 2 – Objectifs du projet/énoncés du problème 6
Tableau 3 – Principales parties prenantes 7
Tableau 4 – Documents de référence liés au projet et autres 7
Tableau 5 – Décisions architecturales 9
Tableau 6 – Problèmes architecturaux clés 9
Tableau 7 – Risques et hypothèses architecturaux 9
Tableau 8 – Organigrammes pertinents 13
Tableau 9 - Glossaire 14
Tableau 10 – Exigences fonctionnelles 15
Tableau 11 – Exigences fonctionnelles 16
Tableau 12 - Définitions 21
Tableau 13 - Pièces jointes 21

3. [Client / Projet]
1. But
L'objectif principal de ce document est de communiquer les éléments essentiels de la solution globale afin
que les implications commerciales puissent être évaluées et comprises, et que les activités de conception
dans Build/Acquire puissent se poursuivre si l'initiative est approuvée.
Insérer une description du développement technique et de ce qui sera réalisé lors de la mise en œuvre
réussie de la solution décrite dans ce document.
2. Aperçu et statut du projet

Fournissez l’historique et le contexte de l’initiative, ainsi que son état actuel du point de vue du projet.
L'état actuel doit également inclure tous les risques ou problèmes importants pouvant être pertinents pour
la conception.
3. Objectifs du projet / Énoncé du problème

Fournir un bref aperçu des objectifs du projet, par exemple un aperçu d'un nouveau produit ou d'une
nouvelle fonctionnalité, ou d'un nouveau système de support, etc. Incluez un bref résumé du besoin
commercial et des moteurs de l'initiative, ainsi que des contraintes d'entreprise, de conception et de
normes. EG, incluent les prévisions de croissance, les volumes de trafic/transactions de pointe et les
projections de marché de référence, etc. Reportez-vous au BRD pour plus de détails.
Alternativement, l’objectif peut être mieux décrit comme une initiative visant à résoudre un problème. Le
tableau ci-dessous propose un format suggéré pour l’énoncé du problème.
Le problème de
Affecte
dont l'impact est
Une solution réussie serait
4. Tableau 2 – Objectifs du projet/énoncés du problème

Portée du projet
Insérez une déclaration qui décrit la portée du projet.
1. Inclusions
2. Exclusions
3. Phaser si nécessaire
2. Parties prenantes clés
Zone / Poste Nom/Rôle Numéro de contact

Acteurs économiques
Acteurs
technologiques
Acteurs opérationnels
Tableau 3 – Principales parties prenantes
3. Documents liés au projet et autres documents de référence

Énumérez toutes les références qui ont été utilisées pour élaborer ce document.
ID du document Titre / Description / Localisation
Documents relatifs au
projet
Autres documents de
référence
5. Tableau 4 – Documents de référence liés au projet et autres

Aperçu architectural
Insérer un schéma architectural des systèmes, des interfaces et des flux d'informations de la solution
prévue.
Numérotez chaque interface pour référence ci-dessous.
1. Interfaces cibles
Clé Interface Objectif/Description

Par Par exemple. Salomon, Startrack Par exemple, l'interface existante fournit des informations sur le
exemple. manifeste de fin de journée à des fins d'expédition.
1

6. Décisions architecturales
Incluez ici un résumé des décisions importantes prises pour élaborer la solution.
Identificateur de décision
Description
architecturale
Par exemple.
Comment s'effectuera la facturation des commandes retournées ?
AD-01
La facturation s'effectuera selon un processus quotidien par lots entre…
AD-02
…
Tableau 5 – Décisions architecturales
1. Problèmes architecturaux clés
Identificateur du Système(s) Description Propriétaire Statut

problème concerné(s)
ISS-01 Identifier le(s) Problème à documenter dans Propriétaire du Fermé/Ouvert
système(s) cette section, par exemple problème qui le
impacté(s) par le nom gérera jusqu'à sa
du système comme 01/01/2003 : Il n'est pas clair si résolution
décrit dans ce XXX générera un message
document d'erreur axe.
SSI – 02
….
Tableau 6 – Problèmes architecturaux clés
2. Risques et hypothèses architecturaux

Les principaux risques et hypothèses architecturaux sont les suivants :
NB, les risques doivent être gérés par la gestion des risques du projet
Hypothèse de
Système(s) concerné(s) Description
risque
Identifier le(s) système(s)

impacté(s) par le nom du
système comme décrit Par exemple. Il est supposé que la migration vers Microsoft .Net
AR-01
dans ce document Framework pour ce portail n'aura pas d'impact sur la fonctionnalité
Par exemple. des systèmes actuellement interfacés avec ce portail.
Portail de prévisions
7. Tableau 7 – Risques et hypothèses architecturaux

Description de la solution
Cette section décrit la solution de haut niveau en termes de systèmes/composants et comment chaque
composant interagit avec d'autres systèmes/composants.
1. Modèle de composant
Incluez et décrivez le modèle de composant de la conception.
Un composant est tout élément d’architecture déployable. Il se caractérise par son comportement ou sa
fonction tel qu'exposé ou exprimé via une interface externe. Les composants peuvent être décomposés
ou agrégés en d'autres composants. Les exemples incluent un programme, un module logiciel, un
système, un référentiel de données, un élément de réseau, etc. Chaque composant peut utiliser les
services fournis par d'autres composants, ainsi que fournir ses propres services.
Le modèle de composants décrit comment les ensembles de composants participent à la définition de la
conception. Il inclut les relations et interactions statiques et dynamiques entre les composants. La
documentation du modèle comprend généralement un certain nombre de diagrammes exprimant les
différents types de relations — par exemple, les relations de dépendance, les relations d'utilisation, les
relations d'interaction et de timing, etc. Lorsque la solution a été divisée, les sous-ensembles individuels
du modèle de composants doivent être clairement définis et l'affectation aux fournisseurs respectifs
identifiée. Chaque sous-ensemble fera ensuite l'objet d'une spécification de composant de conception et
est généralement défini par le(s) client(s) sur la base duquel il fournit une estimation de coût et de délai
avec un niveau de confiance spécifié par le chef de projet.
Il est utile de reconnaître les catégories d'interface suivantes :
● Interfaces utilisateur – les interactions qui existent pour permettre l'interaction humaine avec le
système ;
● Interfaces de services d'application : interactions qui permettent aux services d'application
fournis par un système d'être utilisés par un autre de manière automatisée ;
● Interfaces opérationnelles : interactions utilisées pour gérer et exploiter l'environnement des
systèmes, y compris la surveillance, la récupération et la gestion des exceptions ;
● Interfaces des services de synchronisation du système : interactions utilisées pour maintenir
l'intégrité persistante des informations de référence et d'état sur plusieurs systèmes de manière
synchronisée.
Lors de la spécification des interfaces et des services, il est important de comprendre qu'il existe
deux cas importants :
● Services fonctionnels : ce cas implique des services qui sont principalement apatrides et il
existe une correspondance biunivoque entre l'interface et le service. Chacun de ces services peut
être décrit indépendamment.
● Services de processus : cela implique des services qui mettent en œuvre un processus et le
comportement dépend de l'activité précédente. Généralement, un seul processus peut impliquer
de nombreux appels d'interface — les appels sont parfois appelés « déclencheurs » et dans ce
cas, il est nécessaire non seulement de décrire chacune des interfaces mais également le
comportement d'état du processus lui-même.
2. Réutilisation des composants
Il est important d'identifier les services, composants, codes, documentations, etc. susceptibles d'être
réutilisés par l'entreprise, ainsi que de concevoir et de maintenir la documentation de base de manière à
permettre cette réutilisation à un coût minimisé. Dans cette section, décrivez ce qui a été réalisé en
matière de réutilisation et tous les problèmes qui en découlent.
3. Modèle d'information

Incluez (ou faites référence) et décrivez le modèle d’information pertinent à la solution.
Le modèle d'information couvre une vue structurée des informations commerciales, système et d'état qui
font l'objet de la conception. Le modèle d'information n'a pas besoin de traiter des objets ou des données
qui ne sont pas exposés (ou susceptibles d'être exposés) en externe.
Pour les solutions intensives en matière de gestion de données telles que les bases de données
d'enregistrement, cette partie de la solution constituera une proportion importante du total et pourra en fait
être contenue dans une documentation distincte explicitement référencée par son titre, sa date et sa
version.
Bien que les informations transmises et renvoyées par chaque interface soient décrites dans le modèle de
composants, dans la plupart des cas, il convient également de décrire le modèle d'informations consolidé.
Lorsque la solution a été divisée, les différents sous-ensembles du modèle d'information doivent être
clairement définis et l'affectation aux fournisseurs respectifs doit être identifiée.
1. Caractéristiques des informations et des données

Quelle que soit la complexité ou la taille du modèle d'information, définissez les caractéristiques non
fonctionnelles requises des éléments (ou groupes d'éléments) du modèle. Les caractéristiques à prendre
en compte peuvent inclure, sans toutefois s'y limiter :
● Persistance — indiquez quels éléments du modèle doivent persister au-delà d'une transaction ou
d'une session, y compris les conditions dans lesquelles la persistance ne peut plus être requise et
la période de persistance ;
● Taille : indiquez le nombre prévu d'instances de chaque élément ;
● Sécurité et confidentialité — indiquer quels éléments sont de nature particulièrement sensible
nécessitant des mesures spécifiques d'accès ou de divulgation, ou des contraintes de
confidentialité ;
● Légal et réglementaire : indiquez les éléments qui nécessitent une conservation de données
spécifique, un archivage, une journalisation de la piste d'audit ou d'autres mesures pour répondre
aux obligations légales ou réglementaires. Toutes les exigences légales et réglementaires
concernant les informations ou les données doivent être identifiées comme telles, même si elles
sont répertoriées sous d'autres rubriques (par exemple, les exigences en matière de
confidentialité imposées par un régulateur gouvernemental doivent être identifiées comme étant
des exigences légales et réglementaires même si elles sont répertoriées sous la rubrique sécurité
et confidentialité). );
● Intégrité – indique toute exigence spécifique d’intégrité ou de validité associée aux éléments
d’information.
4. Modèle d'infrastructure
Pour les systèmes informatiques, un modèle d'infrastructure peut être nécessaire dans lequel les serveurs
sous-jacents, les supports de stockage, etc. sont définis. (En termes IBM - le modèle opérationnel)
5. Intégration et conception de réseau

S'applique à une conception de systèmes informatiques où le réseau de communication sous-jacent doit
être défini. Définir les aspects conceptuels du réseau ou des mécanismes d'intégration requis pour
interconnecter les composants. Le modèle de composant aborde les mécanismes d'interface,
principalement du point de vue de l'application ou du niveau de service. Ici sont incluses des informations
supplémentaires relatives aux mécanismes de communication, aux protocoles ou aux modèles de réseau.
En règle générale, les détails de cette sous-section sont développés plus en détail dans le cadre de la
spécification d'intégration.
Les caractéristiques fonctionnelles et non fonctionnelles de l'intégration et du comportement du réseau
doivent être incluses.
6. Architecture de sécurité

L'objectif de cette section est de décrire les contrôles de sécurité qui seront intégrés à la solution.
1. Sécurité des applications

Décrivez les éléments suivants :
● Authentification. Comment les utilisateurs s'authentifieront-ils auprès du système et décriveront
les règles détaillées en matière de mot de passe. Décrivez où l'infrastructure d'authentification
externe est utilisée, par exemple compte-01.
● Autorisation. Décrivez les catégories d'utilisateurs et les fonctionnalités dont ils disposeront.
Inclure tous les utilisateurs, clients, personnel et personnel opérationnel prenant en charge la
plateforme
● Audit/Journalisation. Décrivez ce qui sera enregistré et décrivez toute plate-forme d'audit ou de
journalisation externe utilisée.
2. Sécurité opérationnelle
Décrivez de manière générale tout processus lié à la sécurité et comment le système prendra en charge
ces processus :
● Comment les utilisateurs s'inscrivent-ils ou s'inscrivent-ils au service ? Comment les informations
d’authentification sont-elles émises et réinitialisées ?
● Comment les droits d’accès des utilisateurs sont-ils déterminés et mis en œuvre ? Les
processus d’approbation de l’accès des utilisateurs seront-ils développés, si oui, par qui ?
● Comment les droits d’accès des utilisateurs sont-ils révoqués ?
● Processus de gestion des clés cryptographiques
● Processus de réponse aux incidents de sécurité
● Gestion des vulnérabilités – y compris l'application de correctifs et les évaluations de vulnérabilité
8. Processus spéciaux de classification et de traitement des informations

Configuration requise
1. [nom du système/composant]
Complétez-en un par système/composant
1. Organigramme pertinent
ID de Nom de l'organigramme
l'organigramme
FCXX
Tableau 8 – Organigrammes pertinents
2. Exigences en matière d'architecture de solution

L'objectif de cette section est de définir les exigences spécifiques et bien formulées pour les systèmes
concernés, et de les diviser de manière à faciliter la définition de la conception.
Lors de la création d'exigences architecturales, chaque exigence vérifiable définie dans cette section doit
être contenue dans un paragraphe distinct.
La source de toutes les exigences brutes doit être capturée dans la matrice de traçabilité des exigences,
ainsi que le renvoi aux exigences étiquetées dans cette section.
Cette section contient les exigences spécifiques en matière d'architecture de solution pour [Nom du
système/composant].
3. Description de la conception
9. Cette section détaille la réponse de conception du client concernant le système/composant spécifique qui
doit être livré. Si un document de spécification a été référencé dans cette section, assurez-vous que le
document pertinent a été joint dans la section annexe de ce document.

Implémentation et migration
Aborder l’approche globale de la mise en œuvre. Cela inclurait une stratégie de migration à partir des
processus et systèmes existants, ainsi que des considérations sur la migration des données. En règle
générale, cette section définira les phases de mise en œuvre qui minimiseraient l'impact sur les
opérations commerciales tout en apportant une valeur commerciale supplémentaire à chaque phase.
1. Plan de migration de l'architecture

1. Plan de migration
Insérez un plan de migration d'architecture. Ce plan doit aborder l'approche globale de mise en œuvre de
la nouvelle architecture et compléter les détails écrits dans la section 6 Mise en œuvre et migration. Voici
des exemples des types d'informations que l'on peut trouver ici :
● le séquencement de la migration
● nouvelles exigences en matière d'infrastructure
● liste de tout retrait potentiel de technologie ou d’infrastructure causé par ce plan
● impacts commerciaux
● planifier la migration des données
2. Liste des dépendances
Cette section doit contenir toutes les dépendances du plan de la section ci-dessus. Tous les problèmes et
risques identifiés doivent être gérés via les processus de gestion des problèmes et des risques de
[Entreprise].
Toutes les hypothèses de ce plan et les dépendances doivent être répertoriées dans la section Risques et
hypothèses architecturaux.
2. GLOSSAIRE
Terme/Acronyme Définition / Extension / Description

Données du Données du tableau
tableau
10. Tableau 9 - Glossaire

Exigences fonctionnelles
1. Exigence – [Titre de la fonction 1]
Titre
BR-FID 99 V Priorité 1 Phase 9

E
N
D
U
Flux Étap
d'événe es de
ments l'exig
ence.
Décri
vez-
les
sous
form
e de
liste
à
puce
s/nu
méro
tée
But le
résult
at de
cet
ense
mble
d'acti
ons,
par
exem
ple,
l'utilis
ateur
est
conn
ecté
à la
soluti
on
Sous- FID
fonction
s,
Titre
Hypothè Tout
ses es
les
hypot
hèse
s
opér

ant
dans
l'exé
cutio
n de
la
foncti
on,
par
exem
ple :
L'utili
sateu
r est
déjà
enre
gistré
ou
conn
ecté.
La
soluti
on
reco
nnaît
ra les
droits
de
chaq
ue
indivi
du.
Si
l'utilis
ateur
ne
peut
pas
être
identi
fié, la
soluti
on
en
infor
mera
l'adm
inistr
ateur
. La
soluti
on
enre
gistre
auto
matiq
uem
ent
les
para
mètr
es de
sessi

on.
Conditio Quell
ns es
préalable sont
s les
exige
nces
pour
que
cet
orga
nigra
mme
s'exé
cute,
liste
des
condi
tions
qui
doive
nt
exist
er
avant
que
le
proc
essu
s
puiss
e
être
exéc
uté,
par
exem
ple :
L'utili
sateu
ra
une
sessi
on
de
dériv
e en
cours
et a
accé
dé à
la
soluti
on.
L'utili
sateu
r
dispo
se de
droits
d'acc
ès.

L'utili
sateu
ra
été
ajout
é à la
liste
des
utilis
ateur
s….e
tc.
Conditio Dans
ns de quel
publicati état
on se
trouv
e la
soluti
on
aprè
s
l'exé
cutio
n du
proc
essu
s,
par
exem
ple :
l'utilis
ateur
a
accè
sà
l'appl
icatio
n en
foncti
on
de
ses
privil
èges
Interface Référ
utilisateu ence
r au
proto
type
de
l'inter
face
utilis
ateur
ou à
un
écra
n
spéci
fique
et

notes
relati
ves à
l'inter
face
utilis
ateur
Règles Quell
commer es
ciales condi
tions
s'app
lique
nt à
la
foncti
on ?
Tout
e
conn
aissa
nce,
algori
thme
ou
règle
de
valid
ation
spéci
fique
à un
dom
aine
(perti
nent
pour
ce
cas
d'utili
satio
n),
par
exem
ple.
Aprè
s
trois
tenta
tives
infruc
tueus
es de
conn
exion
, la
soluti
on
verro
uiller
a
l'utilis

ateur
et en
infor
mera
l'adm
inistr
ateur
systè
me.
Organigr Ceci
amme ou est
process facult
us atif.
associés Répe
rtorie
z
tous
les
orga
nigra
mme
s,
inclu
ez,
éten
dez
ou
spéci
alise
z cet
orga
nigra
mme
ou
les
orga
nigra
mme
s
asso
ciés.
Problèm Clarif
es icatio
ns
requi
ses
de la
part
de
l'utilis
ateur
.
Tout
e
quest
ion
relati
ve à
l'orga
nigra
mme
Les Num

référenc éro
es d'exi
genc
e,
docu
ment
s,
pers
onne
s
Remarqu Tout
es e
note
pouv
ant
aider
à
clarifi
er le
proc
essu
s et
les
infor
matio
ns ou
optio
ns
dispo
nible
s
pour
acco
mplir
la
tâche
. Ex :
le
nom
d'utili
sateu
r et
le
mot
de
pass
e
sero
nt les
mêm
es
que
pour
leur
comp
te
pers
onnel
.
Tableau 10 – Exigences fonctionnelles
La grille ci-dessus doit être utilisée pour chaque fonction identifiée.

Si nécessaire, copiez l’organigramme du BRD dans cette section du document.
2. Les sorties
3. Écrans
4. Rapports
5. Exigence – [Titre de la fonction 2]
Titre
BR-FID 99 V Priorité 1 Phase 9

E
N
D
U
Flux Étap
d'événe es de
ments l'exig
ence.
Décri
vez-
les
sous
form
e de
liste
à
puce
s/nu
méro
tée
But le
résult
at de
cet
ense
mble
d'acti
ons,
par
exem
ple,
l'utilis
ateur
est
conn
ecté
à la
soluti
on
Sous- FID
fonction
s,
Titre
Hypothè Tout
ses es

les
hypot
hèse
s
opér
ant
dans
l'exé
cutio
n de
la
foncti
on,
par
exem
ple :
L'utili
sateu
r est
déjà
enre
gistré
ou
conn
ecté.
La
soluti
on
reco
nnaît
ra les
droits
de
chaq
ue
indivi
du.
Si
l'utilis
ateur
ne
peut
pas
être
identi
fié, la
soluti
on
en
infor
mera
l'adm
inistr
ateur
. La
soluti
on
enre
gistre
auto
matiq
uem
ent

les
para
mètr
es de
sessi
on.
Conditio Quell
ns es
préalable sont
s les
exige
nces
pour
que
cet
orga
nigra
mme
s'exé
cute,
liste
des
condi
tions
qui
doive
nt
exist
er
avant
que
le
proc
essu
s
puiss
e
être
exéc
uté,
par
exem
ple :
L'utili
sateu
ra
une
sessi
on
de
dériv
e en
cours
et a
accé
dé à
la
soluti
on.
L'utili
sateu
r

dispo
se de
droits
d'acc
ès.
L'utili
sateu
ra
été
ajout
é à la
liste
des
utilis
ateur
s….e
tc.
Conditio Dans
ns de quel
publicati état
on se
trouv
e la
soluti
on
aprè
s
l'exé
cutio
n du
proc
essu
s,
par
exem
ple :
l'utilis
ateur
a
accè
sà
l'appl
icatio
n en
foncti
on
de
ses
privil
èges
Interface Référ
utilisateu ence
r au
proto
type
de
l'inter
face
utilis
ateur
ou à
un

écra
n
spéci
fique
et
notes
relati
ves à
l'inter
face
utilis
ateur
Règles Quell
commer es
ciales condi
tions
s'app
lique
nt à
la
foncti
on ?
Tout
e
conn
aissa
nce,
algori
thme
ou
règle
de
valid
ation
spéci
fique
à un
dom
aine
(perti
nent
pour
ce
cas
d'utili
satio
n),
par
exem
ple.
Aprè
s
trois
tenta
tives
infruc
tueus
es de
conn
exion
, la
soluti

on
verro
uiller
a
l'utilis
ateur
et en
infor
mera
l'adm
inistr
ateur
systè
me.
Organigr Ceci
amme ou est
process facult
us atif.
associés Répe
rtorie
z
tous
les
orga
nigra
mme
s,
inclu
ez,
éten
dez
ou
spéci
alise
z cet
orga
nigra
mme
ou
les
orga
nigra
mme
s
asso
ciés.
Problèm Clarif
es icatio
ns
requi
ses
de la
part
de
l'utilis
ateur
.
Tout
e
quest
ion
relati

ve à
l'orga
nigra
mme
Les Num
référenc éro
es d'exi
genc
e,
docu
ment
s,
pers
onne
s
Remarqu Tout
es e
note
pouv
ant
aider
à
clarifi
er le
proc
essu
s et
les
infor
matio
ns ou
optio
ns
dispo
nible
s
pour
acco
mplir
la
tâche
. Ex :
le
nom
d'utili
sateu
r et
le
mot
de
pass
e
sero
nt les
mêm
es
que
pour
leur
comp
te
pers

onnel
.
Tableau 11 – Exigences fonctionnelles
La grille ci-dessus doit être utilisée pour chaque fonction identifiée.

Si nécessaire, copiez l’organigramme du BRD dans cette section du document.
6. Les sorties
7. Écrans
11. Rapports

Contributions
1. Données
2. Applications
12. Tierce personne

Conception
1. Couleurs
2. Regarde et ressent
3. Problèmes d'utilisabilité
13. Public

Performance
14. Décrivez les capacités de performance et les contraintes de la solution.

Migration et conversion de données
15. Si une application doit être modifiée, indiquez ici si des conversions de données sont requises sur les
enregistrements de données existants. Si une nouvelle application remplace une application existante,
indiquez ici quelle migration/conversion de données est requise

ANNEXES
Énumérez les documents qui seraient utiles au lecteur du document de conception architecturale
1. Définitions
Les mots, acronymes et abréviations suivants sont mentionnés dans ce document.
Terme Définition
Tableau 12 - Définitions
2. Pièces jointes
numéro de document Titre
16. Tableau 13 - Pièces jointes

Liste de signature
Chef de projet _____________________ ____/____/______

[Titre du poste]
Consultant _____________________ ____/____/______

[Titre du poste]
xxxxx _____________________ ____/____/______

[Titre du poste]
XXXXX _____________________ ____/____/______

(Responsable du développement)

03 - SDD - Document de Conception de Solution

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

03 - SDD - Document de Conception de Solution

Transféré par

Droits d'auteur :

Formats disponibles

Conception de solutions

Nom du projet: [Nom et prénom]

1. E-mail: [Votre adresse e-mail]

[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

Version Responsable Date Remarques

1. Contact pour les demandes de renseignements et les

2. Registre des problèmes

[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

Table des matières

2 Lignes directrices pour remplir ce document : 3

[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

2. Aperçu et statut du projet

3. Objectifs du projet / Énoncé du problème

4. Tableau 2 – Objectifs du projet/énoncés du problème

[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

Zone / Poste Nom/Rôle Numéro de contact

Tableau 3 – Principales parties prenantes

3. Documents liés au projet et autres documents de référence

5. Tableau 4 – Documents de référence liés au projet et autres

[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

Clé Interface Objectif/Description

[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

1. Problèmes architecturaux clés

Identificateur du Système(s) Description Propriétaire Statut

2. Risques et hypothèses architecturaux

Identifier le(s) système(s)

7. Tableau 7 – Risques et hypothèses architecturaux

[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

1. Caractéristiques des informations et des données

5. Intégration et conception de réseau

[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

1. Sécurité des applications

[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

Tableau 8 – Organigrammes pertinents

2. Exigences en matière d'architecture de solution

[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

1. Plan de migration de l'architecture

Terme/Acronyme Définition / Extension / Description

10. Tableau 9 - Glossaire

[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

BR-FID 99 V Priorité 1 Phase 9

[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

La grille ci-dessus doit être utilisée pour chaque fonction identifiée.

[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

BR-FID 99 V Priorité 1 Phase 9

[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

La grille ci-dessus doit être utilisée pour chaque fonction identifiée.

[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

[Entreprise] Page 22 sur 22 SDD – [Client/Projet]

Chef de projet _______________ //

Consultant _______________ //

xxxxx _______________ //

XXXXX _______________ //