Proiectarea soluției

Document (SDD)

Denumirea proiectului: [Numele complet]

Cod proiect: [Cod cu 8 caractere]
Versiune: XX
Autor: [Numele dumneavoastră]
Poziţie: [Pozitia ta]
Telefon: [Numarul tau de telefon]

1. E-mail: [Adresa dvs. de e-mail]

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

Istoricul documentelor

Versiune Responsabil Data Note

1.0

*** Sfârșitul
listei de
revizuiri ***
Tabelul 1 Istoricul documentului

1. Contact pentru întrebări și modificări propuse

Dacă aveți întrebări cu privire la acest document, contactați:
Nume: Marc Dimmick
Desemnare: Analiza de afaceri a sistemului
Telefon: (08) 6216 6335
E-mail: Marc.dimmick@dcp.wa.gov.au

Dacă aveți o sugestie pentru îmbunătățirea acestui document, completați și trimiteți o copie a
acestuia Sugestii pentru Îmbunătățiri la Documentatie .

2. Înregistrarea problemelor
Înregistrarea problemelor reflectă revizuirile acestui șablon. Aceste informații ar trebui să fie șterse
din documentul dvs.
Ver Data Natura amendamentului
1.0 12 aprilie 2006 Document inițial
1.1 8 iunie Actualizați aspectul și foaia de stil
1.2 23 noiembrie 06 Actualizați aspectul și stilul
1.3 19 iulie 2007 Actualizați sigla corporativă

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

2. Instrucțiuni pentru completarea acestui
document:
Consultanții sunt obligați să adune și să documenteze cerințele în consultare cu părțile interesate ale
proiectului. Responsabilitatea generală pentru aceasta revine conducătorului de proiect.
Acest șablon asigură că detaliile esențiale referitoare la aceste cerințe documentează o declarație clară și
neechivocă a cerințelor funcționale și nefuncționale.
Acest document este utilizat în dezvoltarea, testarea, asigurarea calității, managementul proiectelor și
funcțiile conexe ale proiectului.
Elementele din paranteze drepte trebuie înlocuite cu conținut adecvat. De exemplu, [Project Manager] ar
trebui înlocuit cu numele Managerului de proiect.
Acest șablon oferă o structură și un format recomandat, împreună cu conținutul eșantionului, note
explicative și întrebări pentru a ghida și a solicita autorului.
Vă rugăm să ștergeți aceste note și alte instrucțiuni din documentul propriu-zis. Ele sunt destinate doar
informației dumneavoastră. Acestea sunt date în această culoare și font.
Dacă o secțiune/subsecțiune nu se aplică, nu o ștergeți. În schimb, menționați ca atare și explicați de ce
nu este aplicabil. Nu uitați să efectuați o verificare ortografică.
Este de preferat să folosiți data cu numele lunii, mai degrabă decât numărul lunii, pentru a evita confuzia
(utilizați 2 ianuarie 2006 sau 2 ianuarie 2006, în loc de 1/2/2006 sau 2/1/2006)
Acest document conține stiluri preformatate pentru titluri. Pentru a converti o linie în antet, selectați linia și
alegeți BS Heading 1, BS Heading 2 etc., după caz, din meniul drop-down de stil adiacent casetei drop-
down font

Cuprins
1 Istoricul documentelor 2
1.1 Contact pentru întrebări și modificări propuse 2
1.2 Înregistrarea problemelor 2

2 Instrucțiuni pentru completarea acestui document: 3

3 [Client / Proiect] 6
3.1 Scop 6
3.2 Prezentare generală și stare a proiectului 6
3.3 Obiectivele proiectului / Declarația problemei 6

4 Domeniul proiectului 7
4.1.1 Incluziuni 7
4.1.2 Excluderile 7
4.1.3 Etape dacă este necesar 7
4.2 Principalele părți interesate 7
4.3 Documente legate de proiect și alte documente de referință 7

5 Privire de ansamblu arhitecturală 8

5.1 Interfețe țintă 8

6 Decizii arhitecturale 9
6.1 Probleme de arhitectură cheie 9
6.2 Riscuri și ipoteze arhitecturale 9

7 Descrierea soluției 10

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

 7.1 Modelul componentelor 10
7.2 Reutilizarea componentelor 10
7.3 Model informativ 10
7.3.1 Informații și caracteristici ale datelor 11
7.4 Model de infrastructură 11
7.5 Integrare și proiectare de rețea 11
7.6 Arhitectura de securitate 11
7.6.1 Securitatea aplicației 11
7.6.2 Securitate operațională 12

8 Cerințe de sistem 13
8.1 [nume sistem/componentă] 13
8.1.1 Diagramă de flux relevantă 13
8.1.2 Cerințe de arhitectură a soluției 13
8.1.3 Descrierea designului 13

9 Implementare și migrare 14
9.1 Planul de migrare a arhitecturii 14
9.1.1 Planul de migrație 14
9.1.2 Listează dependențe 14
9.2 GLOSAR 14

10 Cerințe funcționale 15
10.1 Cerință – [Titlul funcției 1] 15
10.2 Ieșiri 15
10.3 Ecrane 15
10.4 Rapoarte 15
10.5 Cerință – [Titlul funcției 2] 15
10.6 Ieșiri 16
10.7 Ecrane 16
10.8 Rapoarte 16

11 Intrări 17
11.1 Date 17
11.2 Aplicații 17
11.3 Terț 17

12 Proiecta 18
12.1 Culori 18
12.2 Priviți și simțiți 18
12.3 Probleme de utilizare 18
12.4 Public 18

13 Performanţă 19
14 Migrarea și conversia datelor 20
15 ANEXE 21
15.1 Definiții 21
15.2 Atasamente 21

16 Lista de închidere 22
Mese

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

Tabelul 1 Istoricul documentului 2
Tabelul 2 - Obiectivele proiectului / Declarațiile problemei 6
Tabelul 3 - Părțile interesate cheie 7
Tabelul 4 - Documente legate de proiect și alte documente de referință 7
Tabelul 5 - Decizii arhitecturale 9
Tabelul 6 - Probleme de arhitectură cheie 9
Tabelul 7 - Riscuri și ipoteze arhitecturale 9
Tabelul 8 - Diagrame de flux relevante 13
Tabelul 9 - Glosar 14
Tabelul 10 - Cerințe funcționale 15
Tabelul 11 - Cerințe funcționale 16
Tabelul 12 - Definiții 21
Tabelul 13 - Atasamente 21

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

3. [Client / Proiect]
1. Scop
Scopul principal al acestui document este de a comunica elementele esențiale ale soluției globale, astfel
încât implicațiile de afaceri să poată fi evaluate și înțelese și astfel încât activitățile de proiectare din
Build/Acquire să poată continua dacă inițiativa este aprobată.
Introduceți descrierea dezvoltării tehnice și a ceea ce se va realiza la implementarea cu succes a soluției
descrise în acest document.

2. Prezentare generală și stare a proiectului

Furnizați fundalul și contextul inițiativei și starea ei actuală din perspectiva proiectului.
Starea actuală ar trebui să includă, de asemenea, orice riscuri sau probleme semnificative care pot fi
relevante pentru proiectare.

3. Obiectivele proiectului / Declarația problemei

Oferiți o scurtă prezentare generală a obiectivelor proiectului, de exemplu, o prezentare generală a unui
nou produs sau a unei noi caracteristici, sau a unui nou sistem de asistență etc. Includeți un scurt rezumat
al nevoilor de afaceri și al factorilor care stau la baza inițiativei, precum și al constrângerilor de
întreprindere, design și standarde. De exemplu, includ creșterea prognozată, volumul maxim de
trafic/tranzacție și proiecțiile pieței de referință etc. Consultați BRD pentru detalii.
Ca alternativă, obiectivul poate fi cel mai bine descris ca o inițiativă de a rezolva o problemă. Tabelul de
mai jos oferă un format sugerat pentru declarația problemei.
Problema de
Afectează
Al cărui impact este
O soluție de succes ar

4. Tabelul 2 - Obiectivele proiectului / Declarațiile problemei

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

 Domeniul proiectului
Introduceți o declarație care descrie domeniul de aplicare al proiectului.

1. Incluziuni

2. Excluderile

3. Etape dacă este necesar

2. Principalele părți interesate

Zona / Poziția Nume / Rol Numar de contact

Părți interesate de
afaceri

Părțile interesate din

tehnologie

Părți interesate în
operațiuni

Tabelul 3 - Părțile interesate cheie

3. Documente legate de proiect și alte documente de referință

Enumerați toate referințele care au fost folosite în elaborarea acestui document.
ID document Titlu / Descriere / Locație
Documente legate de
proiect

Alte documente de
referință

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

5. Tabelul 4 - Documente legate de proiect și alte documente de referință

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

Privire de ansamblu arhitecturală
Introduceți diagrama arhitecturală a sistemelor, interfețelor și fluxurilor de informații ale soluției planificate.
Numerotați fiecare interfață pentru referință mai jos.

1. Interfețe țintă

Cheie Interfață Scop/Descriere

De De exemplu. Solomon, Startrack De exemplu, interfața existentă, furnizează informații despre
exemplu. manifestul de sfârșit de zi pentru transport.
1

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

6. Decizii arhitecturale
Includeți aici un rezumat al deciziilor semnificative luate pentru a obține soluția.
Identificator de decizie
Descriere
arhitecturală
De exemplu.
Cum va avea loc facturarea pentru comenzile returnate?
AD-01
Facturarea va avea loc printr-un proces zilnic de lot între...

AD-02
…
Tabelul 5 - Decizii arhitecturale

1. Probleme de arhitectură cheie

Identificatorul Sistem(e) afectat(e). Descriere Proprietar stare

problemei
ISS – 01 Identificați sistemul Problemă care trebuie Proprietarul Închis/Deschis
(sistemele) afectat(e) documentată în această problemei care o va
de numele sistemului secțiune, de ex gestiona până la
așa cum este descris rezolvare
în acest document 01/01/2003: Nu este clar dacă
XXX va genera mesaj de
eroare axe.
ISS – 02
….
Tabelul 6 - Probleme de arhitectură cheie

2. Riscuri și ipoteze arhitecturale

Riscurile și ipotezele arhitecturale cheie sunt următoarele:
NB, riscurile care trebuie gestionate de managementul riscului de proiect
Asumarea riscului Sistem(e) afectat(e). Descriere

Identificați sistemul
(sistemele) afectat(e) de
numele sistemului așa
De exemplu. Se presupune că migrarea la Microsoft .Net Framework
AR – 01 cum este descris în acest
pentru acest portal nu va afecta funcționalitatea sistemelor care se
document
interfață cu acest portal în prezent.
De exemplu.
Portal de prognoză

7. Tabelul 7 - Riscuri și ipoteze arhitecturale

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

Descrierea soluției
Această secțiune descrie soluția de nivel înalt în ceea ce privește sistemele/componentele și modul în
care fiecare componentă interacționează cu alte sisteme/componente.

1. Modelul componentelor
Includeți și descrieți modelul component al designului.
O componentă este orice element implementabil al arhitecturii. Se caracterizează prin comportamentul
sau funcția sa așa cum sunt expuse sau exprimate printr-o interfață externă. Componentele pot fi
descompuse sau agregate în alte componente. Exemplele includ un program, un modul software, un
sistem, un depozit de date, un element de rețea etc. Fiecare componentă poate utiliza serviciile oferite de
alte componente, precum și poate oferi servicii proprii.
Modelul componentelor descrie modul în care seturile de componente participă la definirea designului.
Include relații statice și dinamice și interacțiuni între componente. Documentația modelului include de
obicei un număr de diagrame care exprimă diferitele tipuri de relații - de exemplu, relații de dependență,
relații de utilizare, interacțiune și relații de sincronizare etc. În cazul în care soluția a fost împărțită,
subseturile individuale ale modelului componente trebuie să fie clar definite, iar atribuirea către furnizorii
respectivi trebuie identificată. Fiecare subset va fi ulterior subiectul unei Specificații pentru Componenta
de Proiectare și este de obicei definit de către Client(i) pe baza căruia acesta oferă o estimare a costurilor
și a timpului la un nivel de încredere specificat de Managerul de Proiect.
Este util să recunoașteți următoarele categorii de interfețe:
● Interfețe cu utilizatorul - acele interacțiuni care există pentru a permite interacțiunea umană cu
sistemul;
● Interfețe pentru servicii de aplicație — acele interacțiuni care permit ca serviciile aplicației
furnizate de un sistem să fie utilizate de către altul într-o manieră automată;
● Interfețe operaționale — acele interacțiuni care sunt utilizate pentru a gestiona și opera mediul
sistemelor, inclusiv monitorizarea, recuperarea și gestionarea excepțiilor;
● Interfețe de servicii de sincronizare a sistemului — acele interacțiuni care sunt utilizate pentru
a menține referința persistentă și integritatea informațiilor de stare pe mai multe sisteme într-o
manieră sincronizată.

În specificarea interfețelor și serviciilor, este important să înțelegeți că există două cazuri

importante:
● Servicii funcționale — acest caz implică servicii care sunt în primul rând apatride și există o
corespondență unu-la-unu între interfață și serviciu. Fiecare astfel de serviciu poate fi descris
independent.
● Servicii de proces - aceasta implică servicii care implementează un proces, iar comportamentul
depinde de activitatea anterioară. De obicei, un singur proces poate implica mai multe apeluri de
interfață - apelurile sunt uneori denumite „declanșatoare” și în acest caz este necesar, nu numai
să se descrie fiecare dintre interfețe, ci și comportamentul de stare al procesului în sine.
2. Reutilizarea componentelor
Este important să identificați serviciile, componentele, codul, documentația etc. care sunt candidate
pentru reutilizare corporativă și să proiectați și să mențineți documentația de bază într-un mod care să
permită reutilizarea la un cost minim. În această secțiune descrieți ceea ce a fost realizat în reutilizare și
orice probleme apărute.

3. Model informativ
Includeți (sau referiți) și descrieți modelul de informații relevant pentru soluție.

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

 Modelul de informații acoperă o vedere structurată a informațiilor de afaceri, de sistem și de stat care fac
obiectul proiectului. Modelul informațional nu trebuie să abordeze obiecte sau date care nu sunt expuse
(sau susceptibile să fie expuse) extern.
Pentru soluțiile intensive de gestionare a datelor, cum ar fi acele baze de date de înregistrare, această
parte a soluției va forma o proporție semnificativă din total și poate fi de fapt conținută în documentație
separată care este menționată în mod explicit prin titlu, dată și versiune.
În timp ce informațiile transmise și returnate de fiecare interfață sunt descrise în Modelul componentelor,
în cele mai multe cazuri este, de asemenea, adecvat să se descrie modelul de informații consolidate.
În cazul în care soluția a fost împărțită, subseturile individuale ale modelului de informații trebuie să fie
clar definite, iar atribuirea către furnizorii respectivi trebuie identificată.

1. Informații și caracteristici ale datelor

Indiferent de complexitatea sau dimensiunea modelului de informații, definiți caracteristicile nefuncționale
necesare ale elementelor modelului (sau grupurilor de elemente). Caracteristicile care trebuie abordate
pot include, dar nu se limitează la:
● Persistență — indicați elementele modelului care trebuie să persiste dincolo de o tranzacție sau
sesiune, inclusiv condițiile în care persistența nu mai este necesară și perioada de persistență;
● Mărime — indică numărul anticipat de instanțe ale fiecărui element;
● Securitate și confidențialitate — indicați ce elemente sunt de natură deosebit de sensibilă care
necesită măsuri specifice de acces sau dezvăluire sau constrângeri de confidențialitate;
● Legal și de reglementare — indicați ce elemente necesită păstrarea datelor, arhivarea,
înregistrarea urmăririi de audit sau alte măsuri pentru a îndeplini obligațiile legale sau de
reglementare. Toate cerințele legale și de reglementare referitoare la informații sau date ar trebui
identificate ca atare, chiar dacă sunt enumerate la alte titluri de subiecte (de exemplu, cerințele de
confidențialitate impuse de un organism de reglementare guvernamental ar trebui identificate ca
fiind cerințe legale și de reglementare, chiar dacă sunt enumerate la securitate și
confidențialitate). );
● Integritate — indică orice cerințe specifice de integritate sau validitate asociate elementelor de
informații.
4. Model de infrastructură
Pentru sistemele IT poate fi necesar un model de infrastructură în care sunt definite serverele subiacente,
mediile de stocare etc. (În termeni IBM - modelul operațiunilor)

5. Integrare și proiectare de rețea

Se aplică unui proiect de sisteme IT în care trebuie definită rețeaua de comunicații subiacentă. Definiți
aspectele conceptuale ale rețelei sau mecanismelor de integrare necesare pentru interconectarea
componentelor. Modelul de componente se adresează mecanismelor de interfață, în principal dintr-o
perspectivă la nivel de aplicație sau serviciu. Aici sunt incluse informații suplimentare referitoare la
mecanismele de comunicare, protocoalele sau modelele de rețea. De obicei, detaliile acestei subsecțiuni
sunt dezvoltate în continuare ca parte a specificației de integrare.
Ar trebui incluse atât caracteristicile funcționale, cât și nefuncționale ale integrării și comportamentul
rețelei.

6. Arhitectura de securitate
Scopul acestei secțiuni este de a descrie controalele de securitate care vor fi încorporate în soluție.

1. Securitatea aplicației
Descrieți următoarele:

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

 ● Autentificare. Cum se vor autentifica utilizatorii la sistem, descrie regulile detaliate pentru parole.
Descrieți unde este utilizată infrastructura de autentificare externă, de exemplu contul-01.
● Autorizare. Descrieți categoriile de utilizatori și funcționalitățile pe care le vor avea. Includeți toți
utilizatorii, clienții, personalul, personalul operațional care sprijină platforma
● Audit/Logging. Descrieți ceea ce va fi înregistrat și descrieți orice platforme externe de auditare
sau de înregistrare utilizate
2. Securitate operațională
Descrieți la un nivel înalt orice proces legat de securitate și modul în care sistemul va sprijini aceste
procese:
● Cum se înregistrează sau se înscriu utilizatorii la serviciu? Cum sunt emise și resetate
acreditările de autentificare?
● Cum sunt determinate și implementate drepturile de acces ale utilizatorilor? Vor fi dezvoltate
procesele de aprobare pentru accesul utilizatorilor, dacă da de către cine?
● Cum sunt revocate drepturile de acces utilizatorilor?
● Procese de gestionare a cheilor criptografice
● Procesul de răspuns la incident de securitate
● Managementul vulnerabilităților – inclusiv aplicarea de corecții și evaluări ale vulnerabilităților
8. Procese speciale de clasificare și manipulare a informațiilor

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

 Cerințe de sistem
1. [nume sistem/componentă]
Completați unul pentru fiecare sistem/componentă

1. Diagramă de flux relevantă

ID diagramă flux Nume diagramă de flux

FCXX

Tabelul 8 - Diagrame de flux relevante

2. Cerințe de arhitectură a soluției

Scopul acestei secțiuni este de a defini cerințele specifice, bine formate pentru sistemele afectate și de a
le împărți într-o manieră care va facilita definirea proiectării.
La crearea cerințelor arhitecturale, fiecare cerință verificabilă definită în această secțiune ar trebui să fie
cuprinsă într-un paragraf separat.
Sursa tuturor cerințelor brute ar trebui să fie capturată în Matricea de trasabilitate a cerințelor, împreună
cu referințele încrucișate la cerințele etichetate în această secțiune.
Această secțiune conține cerințele specifice arhitecturii soluției pentru [System/Component Name].

3. Descrierea designului
9. Această secțiune detaliază răspunsul la proiectare al clientului referitor la sistemul/componenta specifică
care urmează să fie livrată. Dacă în această secțiune a fost menționat un document cu specificații,
asigurați-vă că documentul relevant a fost atașat în secțiunea de anexă a acestui document.

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

 Implementare și migrare
Abordați abordarea generală a implementării. Aceasta ar include strategia de migrare de la procesele și
sistemele existente, precum și considerațiile privind migrarea datelor. În mod obișnuit, această secțiune
va defini fazele de implementare care ar minimiza impactul asupra operațiunii afacerii, oferind în același
timp valoare suplimentară pentru fiecare fază.

1. Planul de migrare a arhitecturii

1. Planul de migrație
Introduceți un plan de migrare a arhitecturii. Acest plan ar trebui să abordeze abordarea generală a
implementării noii arhitecturi și să completeze detaliile scrise în secțiunea 6 Implementare și migrare.
Exemple de tipuri de informații care pot fi găsite aici sunt:
● secvențierea migrației
● noi cerințe de infrastructură
● lista cu orice posibile retrageri de tehnologie sau infrastructură cauzate de acest plan
● impactul afacerii
● plan pentru migrarea datelor
2. Listează dependențe
Această secțiune ar trebui să conțină orice dependențe ale planului din secțiunea de mai sus. Toate
problemele și riscurile identificate ar trebui gestionate prin intermediul problemelor [Companiei] și al
proceselor de gestionare a riscurilor.
Toate ipotezele acestui plan și dependențele ar trebui listate în secțiunea Riscuri și ipoteze arhitecturale.

2. GLOSAR

Termen / Definiție / Extindere / Descriere

Acronim
Date de tabel Date de tabel

10. Tabelul 9 - Glosar

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

 Cerințe funcționale
1. Cerință – [Titlul funcției 1]

Titlu

BR-FID 99 F Prioritate 1 Fază 9

R
I
D

Fluxul Etap
evenime ele
ntelor cerinț
ei.
Desc
rieți-
le ca
pe o
listă
cu
marc
atori/
num
erota
te
Poartă rezult
atul
acest
ui set
de
acțiu
ni, de
exem
plu,
utiliz
atoru
l este
cone
ctat
la
soluți
e
Subfuncț FID
ii,
Titlu
Ipoteze Orice
ipote
ze
care
oper
ează
în
exec
uția
funcți
ei, de
exem

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

 plu:
Utiliz
atoru
l este
deja
înreg
istrat
sau
aute
ntific
at.
Soluț
ia va
recu
noașt
e
drept
urile
fiecăr
ui
indivi
d.
Dacă
utiliz
atoru
l nu
poat
e fi
identi
ficat,
soluți
a va
anun
ța
admi
n.
Soluț
ia
salve
ază
auto
mat
setări
le
sesiu
nii.
Condiții Care
prealabil sunt
e cerinț
ele
pentr
u ca
acea
stă
diagr
amă
de
flux
să
rulez
e,
lista

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

 de
condi
ții
care
ar
trebu
i să
exist
e
înaint
e ca
proc
esul
să
poat
ă fi
exec
utat,
de
exem
plu:
Utiliz
atoru
l are
o
sesiu
ne
de
drift
care
rulea
ză și
a
acce
sat
soluți
a.
Utiliz
atoru
l are
drept
uri
de
acce
s.
Utiliz
atoru
la
fost
adău
gat la
lista
de
utiliz
atori
….et
c.
Condiții În ce
post stare
se
află
soluți

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

 a
după
rular
ea
proc
esulu
i, de
exem
plu:
Utiliz
atoru
l are
acce
s la
aplic
ație
confo
rm
privil
egiilo
r sale
Interfața Refer
cu ință
utilizator la
ul proto
tipul
UI
sau
un
anu
mit
ecra
n și
note
legat
e de
UI
Reguli Ce
de condi
afaceri ții se
aplic
ă
funcți
ei?
Orice
cuno
ștințe
speci
fice
dom
eniul
ui
sau
algori
tmi
sau
reguli
de
valid
are
(rele
vante

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

 pentr
u
acest
caz
de
utiliz
are),
de
ex.
După
trei
încer
cări
nere
ușite
de
cone
ctare
,
soluți
a va
bloca
utiliz
atoru
l și
va
notifi
ca
admi
nistra
torul
de
siste
m.
Diagram Aces
ă sau t
procese lucru
înrudite este
opțio
nal.
Listaț
i
toate
diagr
amel
e de
flux,
inclu
deți,
extin
deți
sau
speci
alizaț
i
acea
stă
diagr
amă
de
flux
sau

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

 diagr
ame
de
flux
afere
nte
Problem Sunt
e nece
sare
clarifi
cări
de la
utiliz
ator.
Orice
între
bări
legat
e de
diagr
ama
de
flux
Referințe Cerin
ță #,
docu
ment
e,
pers
oane
Note Orice
notă
care
poat
e
ajuta
la
clarifi
care
a
proc
esulu
i și a
infor
mațiil
or
sau
opțiu
nilor
dispo
nibile
pentr
u
finali
zare
a
sarci
nii.
De
exem
plu:
num

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

 ele
de
utiliz
ator
și
parol
a vor
fi
acele
ași
ca
pentr
u
contu
l
pers
onalu
lui
lor.
Tabelul 10 - Cerințe funcționale

Grila de mai sus trebuie utilizată pentru fiecare funcție identificată.

Dacă este necesar, copiați diagrama de flux din BRD în această secțiune a documentului.

2. Ieșiri
3. Ecrane
4. Rapoarte
5. Cerință – [Titlul funcției 2]

Titlu

BR-FID 99 F Prioritate 1 Fază 9

R
I
D

Fluxul Etap
evenime ele
ntelor cerinț
ei.
Desc
rieți-
le ca
pe o
listă
cu
marc
atori/
num
erota
te
Poartă rezult
atul
acest
ui set
de

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

 acțiu
ni, de
exem
plu,
utiliz
atoru
l este
cone
ctat
la
soluți
e
Subfuncț FID
ii,
Titlu
Ipoteze Orice
ipote
ze
care
oper
ează
în
exec
uția
funcți
ei, de
exem
plu:
Utiliz
atoru
l este
deja
înreg
istrat
sau
aute
ntific
at.
Soluț
ia va
recu
noașt
e
drept
urile
fiecăr
ui
indivi
d.
Dacă
utiliz
atoru
l nu
poat
e fi
identi
ficat,
soluți
a va
anun
ța
admi

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

 n.
Soluț
ia
salve
ază
auto
mat
setări
le
sesiu
nii.
Condiții Care
prealabil sunt
e cerinț
ele
pentr
u ca
acea
stă
diagr
amă
de
flux
să
rulez
e,
lista
de
condi
ții
care
ar
trebu
i să
exist
e
înaint
e ca
proc
esul
să
poat
ă fi
exec
utat,
de
exem
plu:
Utiliz
atoru
l are
o
sesiu
ne
de
drift
care
rulea
ză și
a
acce
sat

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

 soluți
a.
Utiliz
atoru
l are
drept
uri
de
acce
s.
Utiliz
atoru
la
fost
adău
gat la
lista
de
utiliz
atori
….et
c.
Condiții În ce
post stare
se
află
soluți
a
după
rular
ea
proc
esulu
i, de
exem
plu:
Utiliz
atoru
l are
acce
s la
aplic
ație
confo
rm
privil
egiilo
r sale
Interfața Refer
cu ință
utilizator la
ul proto
tipul
UI
sau
un
anu
mit
ecra
n și
note
legat

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

 e de
UI
Reguli Ce
de condi
afaceri ții se
aplic
ă
funcți
ei?
Orice
cuno
ștințe
speci
fice
dom
eniul
ui
sau
algori
tmi
sau
reguli
de
valid
are
(rele
vante
pentr
u
acest
caz
de
utiliz
are),
de
ex.
După
trei
încer
cări
nere
ușite
de
cone
ctare
,
soluți
a va
bloca
utiliz
atoru
l și
va
notifi
ca
admi
nistra
torul
de
siste
m.
Diagram Aces

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

ă sau t
procese lucru
înrudite este
opțio
nal.
Listaț
i
toate
diagr
amel
e de
flux,
inclu
deți,
extin
deți
sau
speci
alizaț
i
acea
stă
diagr
amă
de
flux
sau
diagr
ame
de
flux
afere
nte
Problem Sunt
e nece
sare
clarifi
cări
de la
utiliz
ator.
Orice
între
bări
legat
e de
diagr
ama
de
flux
Referințe Cerin
ță #,
docu
ment
e,
pers
oane
Note Orice
notă
care
poat
e

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

 ajuta
la
clarifi
care
a
proc
esulu
i și a
infor
mațiil
or
sau
opțiu
nilor
dispo
nibile
pentr
u
finali
zare
a
sarci
nii.
De
exem
plu:
num
ele
de
utiliz
ator
și
parol
a vor
fi
acele
ași
ca
pentr
u
contu
l
pers
onalu
lui
lor.
Tabelul 11 - Cerințe funcționale

Grila de mai sus trebuie utilizată pentru fiecare funcție identificată.

Dacă este necesar, copiați diagrama de flux din BRD în această secțiune a documentului.

6. Ieșiri
7. Ecrane
11. Rapoarte

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

 Intrări
1. Date
2. Aplicații
12. Terț

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

 Proiecta
1. Culori
2. Priviți și simțiți
3. Probleme de utilizare
13. Public

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

 Performanţă
14. Subliniați capacitățile de performanță și constrângerile soluției.

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

Migrarea și conversia datelor
15. Dacă o aplicație urmează să fie modificată, indicați aici dacă sunt necesare conversii de date în
înregistrările de date existente. Dacă o aplicație nouă înlocuiește o aplicație existentă, indicați aici ce
migrare/conversie a datelor este necesară

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

ANEXE
Enumerați acele documente care ar fi utile pentru cititorul Documentului de proiectare arhitecturală

1. Definiții
În acest document se face referire la următoarele cuvinte, acronime și abrevieri.
Termen Definiție

Tabelul 12 - Definiții

2. Atasamente

numarul documentului Titlu

16. Tabelul 13 - Atasamente

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]

Lista de închidere

Liderul proiectului _____________________ ____/____/______

[Titlul funcției]

Consultant _____________________ ____/____/______

[Titlul funcției]

xxxxx _____________________ ____/____/______

[Titlul funcției]

XXXXX _____________________ ____/____/______

(Mgr Dezvoltare)

[Companie] Pagina 22 din 22 SDD – [Client / Proiect]