Projeto de solução

Documento (SDD)

Nome do Projeto: [Nome completo]

Código do projeto: [Código de 8 caracteres]
Versão: XX
Autor: [Seu nome]
Posição: [Sua posição]
Telefone: [Seu número de telefone]

1. E-mail: [Seu endereço de email]

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

Documento histórico

Versão Responsável Data Notas

1.0

*** Fim da
lista de
revisão ***
Tabela 1Histórico do Documento

1. Contato para dúvidas e alterações propostas

Se você tiver alguma dúvida sobre este documento entre em contato:
Nome: Marc Dimmick
Designação: Análise de negócios do sistema
Telefone: (08) 6216 6335
E-mail: Marc.dimmick@dcp.wa.gov.au

Se você tiver alguma sugestão para melhorar este documento, preencha e encaminhe uma cópia
do Sugestões para Melhorias para Documentação .

2. Registro de problemas
O Registro de Problemas reflete as revisões deste modelo. Esta informação deve ser excluída do
seu documento.
Ver Data Natureza da Emenda
1.0 12 de abril de Documento Inicial
2006
1.1 8 de junho Atualizar layout e folha de estilo
1.2 23 de novembro Atualizar layout e estilo
de 06
1.3 19 de julho de Atualizar logotipo corporativo
2007

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

2. Diretrizes para preenchimento deste
Documento:
Os consultores são obrigados a reunir e documentar os requisitos em consulta com as partes
interessadas do projeto. A responsabilidade geral por isso é do líder do projeto.
Este modelo garante que os detalhes essenciais relativos a estes Requisitos documentem uma
declaração clara e inequívoca de Requisitos Funcionais e Não Funcionais.
Este documento é usado em desenvolvimento, testes, garantia de qualidade, gerenciamento de projetos
e funções de projeto relacionadas.
Os itens entre colchetes devem ser substituídos por conteúdos apropriados. Por exemplo, [Gerente de
Projeto] deve ser substituído pelo nome do Gerente de Projeto.
Este modelo fornece uma estrutura e formato recomendados, juntamente com exemplos de conteúdo,
notas explicativas e perguntas para orientar e alertar o autor.
Exclua essas notas e outras diretrizes do documento real. Eles são destinados apenas para sua
informação. Eles são fornecidos nesta cor e fonte.
Se uma seção/subseção não for aplicável, não a exclua. Em vez disso, mencione como tal e explique por
que não é aplicável. Lembre-se de executar uma verificação ortográfica.
É preferível usar a data com o nome do mês em vez do número do mês para evitar confusão (use 2 de
janeiro de 2006 ou 2 de janeiro de 2006, em vez de 02/01/2006 ou 01/02/2006)
Este documento contém estilos pré-formatados para títulos. Para converter uma linha em título, selecione
a linha e escolha BS Heading 1, BS Heading 2, etc., conforme apropriado no menu suspenso de estilos
adjacente à caixa suspensa de fontes

Índice
1 Documento histórico 2
1.1 Contato para dúvidas e alterações propostas 2
1.2 Registro de problemas 2

2 Diretrizes para preenchimento deste Documento: 3

3 [Cliente/Projeto] 6
3.1 Propósito 6
3.2 Visão geral e status do projeto 6
3.3 Objetivos do Projeto/Declaração do Problema 6

4 Escopo do Projeto 7
4.1.1 Inclusões 7
4.1.2 Exclusões 7
4.1.3 Faseamento se necessário 7
4.2 Os principais interessados 7
4.3 Documentos relacionados ao projeto e outros documentos de referência 7

5 Visão Geral da Arquitetura 8

5.1 Interfaces de destino 8

6 Decisões Arquitetônicas 9
6.1 Principais questões arquitetônicas 9
6.2 Riscos e suposições arquitetônicas 9

7 Descrição da solução 10

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

 7.1 Modelo de Componente 10
7.2 Reutilização de componentes 10
7.3 Modelo de informação 10
7.3.1 Características de informações e dados 11
7.4 Modelo de infraestrutura 11
7.5 Integração e Design de Rede 11
7.6 Arquitetura de Segurança 11
7.6.1 Segurança de aplicativos 11
7.6.2 Segurança Operacional 12

8 Requisitos de sistema 13
8.1 [nome do sistema/componente] 13
8.1.1 Fluxograma Relevante 13
8.1.2 Requisitos de arquitetura de solução 13
8.1.3 Descrição do projeto 13

9 Implementação e Migração 14
9.1 Plano de migração de arquitetura 14
9.1.1 Plano de Migração 14
9.1.2 Listar dependências 14
9.2 GLOSSÁRIO 14

10 requisitos funcionais 15
10.1 Requisito – [Título da Função 1] 15
10.2 Resultados 15
10.3 Telas 15
10.4 Relatórios 15
10.5 Requisito – [Título da Função 2] 15
10.6 Resultados 16
10.7 Telas 16
10.8 Relatórios 16

11 Entradas 17
11.1 Dados 17
11.2 Formulários 17
11.3 Terceiro 17

12 Projeto 18
12.1 Cores 18
12.2 Olhe e sinta 18
12.3 Problemas de usabilidade 18
12.4 Público 18

13 Desempenho 19
14 Migração e conversão de dados 20
15 ANEXOS 21
15.1 Definições 21
15.2 Anexos 21

16 Lista de aprovação 22
Tabelas

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

Tabela 1Histórico do Documento 2
Tabela 2 - Objetivos do Projeto/Declarações de Problemas 6
Tabela 3 – Principais partes interessadas 7
Tabela 4 - Documentos Relacionados ao Projeto e Outros Documentos de Referência 7
Tabela 5 – Decisões Arquitetônicas 9
Tabela 6 – Principais questões arquitetônicas 9
Tabela 7 – Riscos e Premissas Arquitetônicas 9
Tabela 8 - Fluxogramas Relevantes 13
Tabela 9 - Glossário 14
Tabela 10 – Requisitos Funcionais 15
Tabela 11 – Requisitos Funcionais 16
Tabela 12 - Definições 21
Tabela 13 - Anexos 21

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

3. [Cliente/Projeto]
1. Propósito
O objetivo principal deste documento é comunicar os elementos essenciais da solução geral para que as
implicações de negócios possam ser avaliadas e compreendidas e para que as atividades de design em
Construção/Aquisição possam prosseguir se a iniciativa for aprovada.
Insira a descrição do desenvolvimento técnico e o que será alcançado após a implementação bem-
sucedida da solução descrita neste documento.

2. Visão geral e status do projeto

Forneça o histórico e o contexto da iniciativa e seu status atual do ponto de vista do projeto.
O estado atual também deve incluir quaisquer riscos ou questões significativas que possam ser
relevantes para o projeto.

3. Objetivos do Projeto/Declaração do Problema

Forneça uma breve visão geral dos objetivos do projeto, por exemplo, uma visão geral de um novo
produto ou novo recurso, ou um novo sistema de suporte, etc. Inclua um breve resumo das necessidades
comerciais e dos motivadores por trás da iniciativa, bem como das restrições empresariais, de design e
de padrões. Por exemplo, incluem previsão de crescimento, pico de volumes de tráfego/transações e
projeções de mercado de referência, etc. Consulte o BRD para obter detalhes.
Alternativamente, o objetivo pode ser melhor descrito como uma iniciativa para resolver um problema. A
tabela abaixo fornece um formato sugerido para a declaração do problema.
O problema de
Afeta
O impacto disso é
Uma solução bem sucedida
seria

4. Tabela 2 - Objetivos do Projeto/Declarações de Problemas

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

 Escopo do Projeto
Insira uma declaração que descreva o escopo do projeto.

1. Inclusões

2. Exclusões

3. Faseamento se necessário
2. Os principais interessados

Área/Posição Nome/Função Número de contato

Partes interessadas
nos negócios

Partes interessadas em
tecnologia

Partes interessadas de
operações

Tabela 3 – Principais partes interessadas

3. Documentos relacionados ao projeto e outros documentos

de referência
Liste todas as referências que foram usadas na elaboração deste documento.
ID do documento Título/Descrição/Localização
Documentos
Relacionados ao Projeto

Outros documentos de
referência

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

5. Tabela 4 - Documentos Relacionados ao Projeto e Outros Documentos de Referência

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

Visão Geral da Arquitetura
Inserir diagrama arquitetônico dos sistemas, interfaces e fluxos de informações da solução planejada.
Numere cada interface para referência abaixo.

1. Interfaces de destino

Chave Interface Finalidade/Descrição

Por Por exemplo. Salomão, Startrack Por exemplo, interface existente, fornece informações de
exemplo. manifesto de final de dia para fins de envio.
1

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

6. Decisões Arquitetônicas
Inclua aqui um resumo das decisões significativas tomadas na obtenção da solução.
Identificador de decisão
Descrição
arquitetônica
Por exemplo.
Como ocorrerá o faturamento dos pedidos devolvidos?
AD-01
O faturamento ocorrerá por meio de um processo em lote diário entre…

AD-02
…
Tabela 5 – Decisões Arquitetônicas

1. Principais questões arquitetônicas

Identificador do Sistema(s) Descrição Proprietário Status

problema impactado(s)
ISS – 01 Identifique os Problema a ser documentado Proprietário do Fechado/Aberto
sistemas impactados nesta seção, por exemplo problema que irá
pelo nome do sistema gerenciá-lo até a
conforme descrito 01/01/2003: Não está claro se resolução
neste documento XXX gerará mensagem de
erro axe.
ISS – 02
….
Tabela 6 – Principais questões arquitetônicas

2. Riscos e suposições arquitetônicas

Os principais riscos e suposições arquiteturais são os seguintes:
NB, riscos a serem gerenciados pelo gerenciamento de riscos do projeto
Assunção de Risco Sistema(s) impactado(s) Descrição

Identifique os sistemas
impactados pelo nome do
sistema conforme descrito Por exemplo. Presume-se que a migração para o Microsoft .Net
AR – 01
neste documento Framework deste portal não afetará a funcionalidade dos sistemas
Por exemplo. que fazem interface com este portal atualmente.
Portal de previsão

7. Tabela 7 – Riscos e Premissas Arquitetônicas

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

Descrição da solução
Esta seção descreve a solução de alto nível em termos de sistemas/componentes e como cada
componente interage com outros sistemas/componentes.

1. Modelo de Componente
Incluir e descrever o modelo de componentes do projeto.
Um componente é qualquer elemento implantável da arquitetura. É caracterizado por seu comportamento
ou função exposto ou expresso por meio de uma interface externa. Os componentes podem ser
decompostos ou agregados em outros componentes. Os exemplos incluem um programa, um módulo de
software, um sistema, um repositório de dados, um elemento de rede, etc. Cada componente pode
utilizar os serviços fornecidos por outros componentes, bem como fornecer serviços próprios.
O modelo de componentes descreve como conjuntos de componentes participam na definição do projeto.
Inclui relacionamentos e interações estáticas e dinâmicas entre componentes. A documentação do
modelo normalmente inclui vários diagramas que expressam os diferentes tipos de relacionamentos —
por exemplo, relacionamentos de dependência, relacionamentos de uso, relacionamentos de interação e
tempo, etc. Quando a solução tiver sido particionada, os subconjuntos individuais do modelo de
componentes deverão ser claramente definidos e a atribuição aos respectivos fornecedores identificada.
Cada subconjunto será posteriormente objeto de uma Especificação de Componente de Projeto e
geralmente é definido pelo(s) Cliente(s) com base na qual ele fornece uma estimativa de custo e tempo
com um nível de confiança especificado pelo Gerente de Projeto.
É útil reconhecer as seguintes categorias de interface:
● Interfaces de usuário — aquelas interações que existem para permitir a interação humana com
o sistema;
● Interfaces de serviços de aplicativos – aquelas interações que permitem que os serviços de
aplicativos fornecidos por um sistema sejam utilizados por outro de maneira automatizada;
● Interfaces Operacionais — aquelas interações que são usadas para gerenciar e operar o
ambiente de sistemas, incluindo monitoramento, recuperação e gerenciamento de exceções;
● Interfaces de serviços de sincronização de sistemas — aquelas interações usadas para
manter referência persistente e integridade de informações de estado em vários sistemas de
maneira sincronizada.

Ao especificar interfaces e serviços, é importante compreender que existem dois casos

importantes:
● Serviços Funcionais – este caso envolve serviços que são principalmente sem estado e há uma
correspondência um-para-um entre interface e serviço. Cada um desses serviços pode ser
descrito de forma independente.
● Serviços de Processo — envolve serviços que implementam um processo, e o comportamento
depende da atividade anterior. Normalmente, um único processo pode envolver muitas
chamadas de interface - as chamadas às vezes são chamadas de “gatilhos” e, neste caso, é
necessário não apenas descrever cada uma das interfaces, mas também o comportamento do
estado do próprio processo.
2. Reutilização de componentes
É importante identificar serviços, componentes, código, documentação, etc., que sejam candidatos à
reutilização corporativa e projetar e manter a documentação básica de uma forma que permita essa
reutilização a um custo minimizado. Nesta seção, descreva o que foi alcançado na reutilização e
quaisquer problemas que surjam.

3. Modelo de informação

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

 Incluir (ou referenciar) e descrever o modelo de informação pertinente à solução.
O Modelo de Informação cobre uma visão estruturada das informações de negócio, sistema e estado que
são objeto do design. O modelo de informação não precisa abordar objetos ou dados que não estão
expostos (ou que provavelmente serão expostos) externamente.
Para soluções intensivas de gerenciamento de dados, como os bancos de dados de registro, esta parte
da solução constituirá uma proporção significativa do total e poderá, na verdade, estar contida em
documentação separada que é explicitamente referenciada por título, data e versão.
Embora as informações passadas e retornadas por cada interface sejam descritas no Modelo de
Componentes, na maioria dos casos também é apropriado descrever o modelo de informações
consolidadas.
Quando a solução tiver sido particionada, os subconjuntos individuais do modelo de informação devem
ser claramente definidos e a atribuição aos respetivos fornecedores identificada.

1. Características de informações e dados

Independentemente da complexidade ou tamanho do modelo de informação, defina as características
não funcionais exigidas dos elementos do modelo (ou grupos de elementos). As características a serem
abordadas podem incluir, mas não estão limitadas a:
● Persistência — indique quais elementos do modelo devem persistir além de uma transação ou
sessão, incluindo as condições sob as quais a persistência pode não ser mais necessária e o
período de persistência;
● Tamanho — indique o número previsto de instâncias de cada elemento;
● Segurança e Privacidade — indique quais elementos são de natureza particularmente sensível
que exigem medidas específicas de acesso ou divulgação, ou restrições de privacidade;
● Legal e Regulatório — indique quais elementos exigem retenção de dados específicos,
arquivamento, registro de trilha de auditoria ou outras medidas para cumprir obrigações legais ou
regulatórias. Todos os requisitos legais e regulamentares relativos a informações ou dados
devem ser identificados como tal, mesmo que listados em outros títulos de tópicos (por exemplo,
os requisitos de privacidade impostos por um regulador governamental devem ser identificados
como sendo requisitos legais e regulamentares, mesmo que estejam listados em segurança e
privacidade );
● Integridade — indica quaisquer requisitos específicos de integridade ou validade associados aos
elementos de informação.
4. Modelo de infraestrutura
Para sistemas de TI, pode ser necessário um modelo de infraestrutura onde os servidores subjacentes,
meios de armazenamento, etc., sejam definidos. (Em termos da IBM - o modelo de operações)

5. Integração e Design de Rede

Aplica-se a um projeto de sistemas de TI onde a rede de comunicações subjacente deve ser definida.
Definir os aspectos conceituais dos mecanismos de rede ou integração necessários para interconectar
componentes. O Modelo de Componentes aborda mecanismos de interface, principalmente de uma
perspectiva de aplicação ou nível de serviço. Aqui está incluída informação adicional relativa aos
mecanismos de comunicação, protocolos ou modelos de rede. Normalmente, os detalhes desta
subseção são desenvolvidos como parte da Especificação de Integração.
Devem ser incluídas características funcionais e não funcionais de integração e comportamento da rede.

6. Arquitetura de Segurança
O objetivo desta seção é descrever os controles de segurança que serão incorporados à solução.

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

1. Segurança de aplicativos
Descreva o seguinte:
● Autenticação. Como os usuários serão autenticados no sistema, descreva regras detalhadas de
senha. Descreva onde a infraestrutura de autenticação externa está sendo usada, por exemplo,
conta-01.
● Autorização. Descreva as categorias de usuários e as funcionalidades que eles terão. Incluir
todos os usuários, clientes, funcionários e pessoal de operações que dão suporte à plataforma
● Auditoria/Registro. Descreva o que será registrado e descreva quaisquer plataformas externas
de auditoria ou registro em uso
2. Segurança Operacional
Descreva em alto nível qualquer processo relacionado à segurança e como o sistema apoiará esses
processos:
● Como os usuários se registram ou se inscrevem no serviço? Como as credenciais de
autenticação são emitidas e redefinidas?
● Como são determinados e implementados os direitos de acesso dos usuários? Serão
desenvolvidos processos de aprovação para acesso de usuários, em caso afirmativo, por quem?
● Como são revogados os direitos de acesso dos usuários?
● Processos de gerenciamento de chaves criptográficas
● Processo de resposta a incidentes de segurança
● Gerenciamento de vulnerabilidades – incluindo aplicação de patches e avaliações de
vulnerabilidades
8. Processos especiais de classificação e tratamento de informações

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

 Requisitos de sistema
1. [nome do sistema/componente]
Complete um por sistema/componente

1. Fluxograma Relevante

ID do fluxograma Nome do Fluxograma

FCXX

Tabela 8 - Fluxogramas Relevantes

2. Requisitos de arquitetura de solução

O objetivo desta seção é definir os requisitos específicos e bem formados para os sistemas impactados e
particioná-los de uma maneira que facilite a definição do projeto.
Ao criar Requisitos de Arquitetura, cada requisito verificável definido nesta seção deve estar contido em
um parágrafo separado.
A fonte de todos os requisitos brutos deve ser capturada na Matriz de Rastreabilidade de Requisitos,
juntamente com a referência cruzada aos requisitos rotulados nesta seção.
Esta seção contém os requisitos específicos de arquitetura da solução para [Nome do
sistema/componente].

3. Descrição do projeto
9. Esta seção detalha a resposta do projeto do cliente referente ao sistema/componente específico que
será entregue. Se um documento de especificação tiver sido referenciado nesta seção, certifique-se de
que o documento relevante tenha sido anexado na seção de apêndice deste documento.

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

 Implementação e Migração
Abordar a abordagem geral para implementação. Isto incluiria uma estratégia de migração de processos
e sistemas existentes, bem como considerações sobre migração de dados. Normalmente, esta seção
definirá fases de implementação que minimizariam o impacto na operação comercial, proporcionando ao
mesmo tempo valor comercial adicional em cada fase.

1. Plano de migração de arquitetura

1. Plano de Migração
Insira um plano de migração de arquitetura. Este plano deverá abordar a abordagem global para a
implementação da nova arquitectura e complementar os detalhes escritos na secção 6 Implementação e
Migração. Exemplos dos tipos de informações que podem ser encontrados aqui são:
● a sequência da migração
● novos requisitos de infraestrutura
● lista de quaisquer possíveis desativações de tecnologia ou infraestrutura causadas por este plano
● impactos nos negócios
● planejar a migração de dados
2. Listar dependências
Esta seção deve conter quaisquer dependências do plano da seção acima. Todas as questões e riscos
identificados devem ser gerenciados por meio dos processos de gestão de riscos e questões da
[Empresa].
Todas as premissas deste plano e dependências devem ser listadas na seção Riscos e premissas
arquitetônicas.

2. GLOSSÁRIO

Termo / Sigla Definição/Expansão/Descrição

Dados da tabela Dados da tabela

10. Tabela 9 - Glossário

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

 requisitos funcionais
1. Requisito – [Título da Função 1]

Título

BR-FID 99 F Prioridad 1 Estágio 9

R e
I
D
O

Fluxo de Etap
Eventos as do
requi
sito.
Desc
reva-
os
como
uma
lista
com
marc
ador
es/nu
mera
da
Meta o
result
ado
deste
conju
nto
de
açõe
s,
por
exem
plo, o
usuá
rio
está
cone
ctado
à
soluç
ão
Subfunç FID
ões,
Títul
o
Premiss Quai
as sque
r
supo
siçõe
s

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

 oper
ando
na
exec
ução
da
funçã
o,
por
exem
plo:
O
usuá
rio já
está
cada
strad
o ou
logad
o. A
soluç
ão
reco
nhec
erá
os
direit
os de
cada
indiví
duo.
Se o
usuá
rio
não
pude
r ser
identi
ficad
o, a
soluç
ão
notifi
cará
o
admi
nistra
dor.
A
soluç
ão
salva
auto
matic
ame
nte
as
confi
gura
ções
da
sess
ão.

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

Pré- Quai
condiçõe s são
s os
requi
sitos
para
a
exec
ução
deste
fluxo
gram
a,
lista
de
condi
ções
que
deve
m
existi
r
antes
que
o
proc
esso
poss
a ser
exec
utad
o,
por
exem
plo:
O
usuá
rio
tem
uma
sess
ão
de
desvi
o em
exec
ução
e
aces
sou a
soluç
ão. O
usuá
rio
tem
direit
os de
aces
so. O
usuá
rio foi
adici
onad

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

 oà
lista
de
usuá
rios
….et
c.
Pós- Em
condiçõe que
s estad
oa
soluç
ão se
enco
ntra
após
a
exec
ução
do
proc
esso,
por
exem
plo:
O
usuá
rio
tem
aces
so ao
aplic
ativo
de
acor
do
com
seus
privil
égios
Interface Refer
de ência
usuário ao
protó
tipo
da UI
ou
tela
espe
cífica
e
notas
relaci
onad
as à
UI
Regras Que
do condi
negócio ções
se
aplic
am à

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

 funçã
o?
Qual
quer
conh
ecim
ento
ou
algori
tmos
espe
cífico
s de
domí
nio
ou
regra
s de
valid
ação
(rele
vante
s
para
este
caso
de
uso),
por
exem
plo.
Após
três
tenta
tivas
mals
ucedi
das
de
login,
a
soluç
ão
bloqu
eará
o
usuá
rio e
notifi
cará
o
admi
nistra
dor
do
siste
ma.
Fluxogra Isso
ma ou é
process opcio
os nal.
relaciona Liste

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

dos todos
os
fluxo
gram
as,
inclu
a,
esten
da
ou
espe
cializ
e
este
fluxo
gram
a ou
fluxo
gram
as
relaci
onad
os
Problem Escla
as recim
entos
nece
ssári
os ao
usuá
rio.
Qual
quer
dúvid
a
relaci
onad
a ao
Fluxo
gram
a
Referênc Requ
ias isito
#,
Docu
ment
os,
Pess
oas
Notas Quai
sque
r
notas
que
poss
am
ajuda
ra
escla
recer
o
proc

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

 esso
e as
infor
maçõ
es ou
opçõ
es
dispo
nívei
s
para
a
concl
usão
da
taref
a.
Ex:
nom
e de
usuá
rio e
senh
a
serã
o os
mes
mos
da
conta
de
equip
e.
Tabela 10 – Requisitos Funcionais

A grade acima deve ser usada para todas as funções identificadas.

Se necessário, copie o fluxograma do BRD para esta seção do documento.

2. Resultados
3. Telas
4. Relatórios
5. Requisito – [Título da Função 2]

Título

BR-FID 99 F Prioridad 1 Estágio 9

R e
I
D
O

Fluxo de Etap
Eventos as do
requi
sito.
Desc

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

 reva-
os
como
uma
lista
com
marc
ador
es/nu
mera
da
Meta o
result
ado
deste
conju
nto
de
açõe
s,
por
exem
plo, o
usuá
rio
está
cone
ctado
à
soluç
ão
Subfunç FID
ões,
Títul
o
Premiss Quai
as sque
r
supo
siçõe
s
oper
ando
na
exec
ução
da
funçã
o,
por
exem
plo:
O
usuá
rio já
está
cada
strad
o ou
logad
o. A
soluç

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

 ão
reco
nhec
erá
os
direit
os de
cada
indiví
duo.
Se o
usuá
rio
não
pude
r ser
identi
ficad
o, a
soluç
ão
notifi
cará
o
admi
nistra
dor.
A
soluç
ão
salva
auto
matic
ame
nte
as
confi
gura
ções
da
sess
ão.
Pré- Quai
condiçõe s são
s os
requi
sitos
para
a
exec
ução
deste
fluxo
gram
a,
lista
de
condi
ções
que
deve
m

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

 existi
r
antes
que
o
proc
esso
poss
a ser
exec
utad
o,
por
exem
plo:
O
usuá
rio
tem
uma
sess
ão
de
desvi
o em
exec
ução
e
aces
sou a
soluç
ão. O
usuá
rio
tem
direit
os de
aces
so. O
usuá
rio foi
adici
onad
oà
lista
de
usuá
rios
….et
c.
Pós- Em
condiçõe que
s estad
oa
soluç
ão se
enco
ntra
após
a
exec
ução

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

 do
proc
esso,
por
exem
plo:
O
usuá
rio
tem
aces
so ao
aplic
ativo
de
acor
do
com
seus
privil
égios
Interface Refer
de ência
usuário ao
protó
tipo
da UI
ou
tela
espe
cífica
e
notas
relaci
onad
as à
UI
Regras Que
do condi
negócio ções
se
aplic
am à
funçã
o?
Qual
quer
conh
ecim
ento
ou
algori
tmos
espe
cífico
s de
domí
nio
ou
regra
s de
valid

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

 ação
(rele
vante
s
para
este
caso
de
uso),
por
exem
plo.
Após
três
tenta
tivas
mals
ucedi
das
de
login,
a
soluç
ão
bloqu
eará
o
usuá
rio e
notifi
cará
o
admi
nistra
dor
do
siste
ma.
Fluxogra Isso
ma ou é
process opcio
os nal.
relaciona Liste
dos todos
os
fluxo
gram
as,
inclu
a,
esten
da
ou
espe
cializ
e
este
fluxo
gram
a ou
fluxo
gram

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

 as
relaci
onad
os
Problem Escla
as recim
entos
nece
ssári
os ao
usuá
rio.
Qual
quer
dúvid
a
relaci
onad
a ao
Fluxo
gram
a
Referênc Requ
ias isito
#,
Docu
ment
os,
Pess
oas
Notas Quai
sque
r
notas
que
poss
am
ajuda
ra
escla
recer
o
proc
esso
e as
infor
maçõ
es ou
opçõ
es
dispo
nívei
s
para
a
concl
usão
da
taref
a.
Ex:
nom

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

 e de
usuá
rio e
senh
a
serã
o os
mes
mos
da
conta
de
equip
e.
Tabela 11 – Requisitos Funcionais

A grade acima deve ser usada para todas as funções identificadas.

Se necessário, copie o fluxograma do BRD para esta seção do documento.

6. Resultados
7. Telas
11. Relatórios

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

 Entradas
1. Dados
2. Formulários
12. Terceiro

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

 Projeto
1. Cores
2. Olhe e sinta
3. Problemas de usabilidade
13. Público

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

 Desempenho
14. Descreva os recursos de desempenho e as restrições da solução.

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

Migração e conversão de dados
15. Se um aplicativo for modificado, indique aqui se alguma conversão de dados é necessária em registros
de dados existentes. Se uma nova aplicação estiver substituindo uma aplicação existente, indique aqui
qual migração/conversão de dados é necessária

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

ANEXOS
Liste os documentos que seriam úteis para o leitor do Documento de Projeto Arquitetônico

1. Definições
As seguintes palavras, siglas e abreviaturas são referidas neste documento.
Prazo Definição

Tabela 12 - Definições

2. Anexos

número do documento Título

16. Tabela 13 - Anexos

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]

Lista de aprovação

Líder de projeto _____________________ ____/____/______

[Título de posição]

Consultor _____________________ ____/____/______

[Título de posição]

xxxxx _____________________ ____/____/______

[Título de posição]

XXXXX _____________________ ____/____/______

(Gerente de Desenvolvimento)

[Empresa] Página 22 de 22 SDD – [Cliente/Projeto]