A
TIVIDADES TÍPICAS DE UM
PDS
Levantamento de requisitos
Análise de requisitos
Projeto
Implementação
Testes
Implantação
Engenharia de requisitos
E
NGENHARIA DE REQUISITOS
Estabelece os serviços
que o cliente requer
de um sistema e as restrições sob as quais tal
sistema operará e será desenvolvido.
O
QUE É UM REQUISITO
?
Pode ser uma
descrição abstrata de alto
nível
de um serviço, uma restrição de sistema ou
até uma especificação matemática, entre outras
coisas
O
problema
cujo desenvolvimento do sistema
deve resolver
O sistema tem que ser construído de modo a satisfazer
E
NTENDIMENTO DOS
R
EQUISITOS
!
“Uma compreensão completa dos requisitos de
software
é
fundamental para um projeto bem-sucedido. Um problema mal
analisado e especificado desapontará o usuário e trará
aborrecimentos ao desenvolvedor
O
SISTEMA
LIBSYS
Um sistema de biblioteca que fornece uma
interface única para uma série de banco de dados
de artigos em bibliotecas diferentes.
Os usuários podem pesquisar, baixar e imprimir
T
IPOS DE REQUISITOS
Requisitos de usuário
Declarações de alto nível escritas em linguagem natural
Escritos para os clientes.
Requisitos de sistema
Um documento estruturado estabelecendo descrições detalhadas das
funções, serviços e restrições operacionais do sistema.
Define o que deve ser implementado e pode até ser parte de um
R
EQUISITOS FUNCIONAIS E NÃO
-
FUNCIONAIS
Requisitos funcionais
Serviços que o sistema deve fornecer
Como o sistema deve reagir a entradas específicas
Como o sistema deve se comportar em determinadas
situações.
Requisitos não-funcionais ou de qualidade
Restrições sobre serviços ou funções oferecidos pelo
sistema tais como restrições de desempenho, restrições
sobre o processo de desenvolvimento, padrões,
E
XEMPLOS DE REQUISITOS FUNCIONAIS
O usuário deve ser capaz de pesquisar em todo o
conjunto inicial de banco de dados ou selecionar um
subconjunto a partir dele.
Para todo pedido deve ser alocado um identificador
único (ORDER_ID) que o usuário possa copiar para a
área de armazenamento permanente da sua conta.
E
XEMPLOS DE REQUISITOS NÃO
-
FUNCIONAIS
O sistema deve fornecer
telas apropriadas
para o
usuário ler os documentos no repositório de
documentos.
O sistema deve atender ao padrão adotado pela
empresa com relação ao
tempo de resposta
.
O sistema deve adotar padrões de projeto e o maximo
de refatoração para manter um codigo limpo e de
facil
entendimento
I
MPRECISÃO DE REQUISITOS
Problemas surgem quando os requisitos não são
precisamente definidos.
Requisitos
ambíguos
podem ser interpretados de
maneiras diferentes pelos desenvolvedores e usuários.
Considere o termo ‘
telas apropriadas
’
Intenção do usuário – tela de propósito especial para cada tipo
diferente de documento;
Interpretação do desenvolvedor – fornece uma tela de texto que
R
EQUISITOS COMPLETOS E CONSISTENTES
Em princípio, requisitos devem ser completos e
consistentes.
Completude
Eles devem incluir descrições de
todos
os recursos requeridos.
Consistência
Não deve haver
conflitos
ou
contradições
nas descrições dos
recursos de sistema.
Na prática, é impossível produzir um documento de
R
EVISANDO
...
Engenharia de requisitos
Requisitos de usuário
Requisitos de sistema
Requisitos funcionais
Requisitos não-funcionais ou de qualidade
Imprecisão de requisitos
P
ROBLEMAS COM LINGUAGEM NATURAL
Falta de clareza
É difícil atingir uma precisão sem tornar o documento difícil de
ler e ambíguo
Confusão de requisitos
Requisitos funcionais e não-funcionais tendem a estar
misturados.
Fusão de requisitos
Vários requisitos diferentes podem ser expressos juntos
A
LTERNATIVAS À ESPECIFICAÇÃO EM
LINGUAGEM NATURAL
Linguagem natural estruturada - templates
Notações gráficas - UML
Especificações matemáticas – máquina de estado,
conjuntos
E
SPECIFICAÇÕES EM LINGUAGEM
ESTRUTURADA
A liberdade do elaborador de requisitos é limitada
por um template pré-definido para requisitos.
Todos os requisitos são escritos de maneira
padronizada.
A terminologia usada na descrição pode ser limitada.
A vantagem é que a maior parte da expressividade
da linguagem natural é mantida
U
SUÁRIOS DE UM DOCUMENTO DE
REQUISITOS
C
ASOS DE USO
O modelo de casos de uso é uma
representação das
funcionalidades
externamente observáveis do sistema e dos
elementos externos
ao sistema que interagem
com o mesmo.
Esse modelo representa os requisitos
funcionais do sistema*.
P
rinc
ípi
os de
Aná
li
se
e
P
roje
to de
S
ist
emas c
om
UML
-2ª
e
diçã
o
C
OMPOSIÇÃO DO
MCU
O modelo de casos de uso de um sistema é
composto de duas partes, uma
textual
, e
outra
gráfica
.
O diagrama da UML utilizado na modelagem
de gráfica é o
diagrama de casos de uso
.
Componentes:
casos
de
uso,
atores,
relacionamentos
entre
os
elementos
anteriores.
P
rinc
ípi
os de
Aná
li
se
e
P
roje
to de
S
ist
emas c
om
UML
-2ª
e
diçã
o
C
ENÁRIOS
Analogia para entender a relação entre caso de uso e cenário é a de
um labirinto.
D
IAGRAMA DE CASOS DE USO
(DCU)
Representa
graficamente
os atores, casos de
uso e relacionamentos entre os elementos.
Tem o objetivo de ilustrar em um nível alto de
abstração quais elementos
externos interagem
com que funcionalidades do sistema
.
A
TOR
,
CASO DE USO
,
COMUNICAÇÃO
I
NCLUSÃO
(
INCLUDE
)
27
Exemplo:
Referência no texto do caso de uso inclusor:
E
XTENSÃO
(
EXTEND
)
28
G
ENERALIZAÇÃO
29
P
rinc
ípi
os de
Aná
li
se
e
P
roje
to de
S
ist
emas c
om
UML
-2ª
e
diçã
o
D
OCUMENTAÇÃO DOS CASOS DE USO
Nome
Descrição
Identificador
Importância
Sumário
Ator Primário
Atores Secundários
Pré-condições
30
Fluxo Principal
Fluxos Alternativos
extend X alternativo
Fluxos de Exceção
Pós-condições
Regras do Negócio
Histórico
E
XEM
PLO
–
UC
001
-FAZE
R
P
E
DI
DO
[UC-001]Nome: Fazer Pedido
Atores: Usuário/cliente
Sistema de cartão de credito.
Prioridade: Essencial
Requisitos associados: [RF-10]
[RNF/SEG-01]
Entradas e pré-condições: O usuário/cliente deve estar logado no sistema.
Saídas e pós-condições: A confirmação do pedido.
Fluxos de eventos
Fluxo principal: 1. O cliente acessa o menu de fazer pedido.
2. O cliente fornece seu nome e endereço. [RN01] [FE01]. 3. O cliente fornece os códigos do produto [FE02].
4. O sistema devolve as descrições e o preço de cada produto. [RN02].
5. O cliente fornece as informações sobre o cartão de crédito (bandeira, número, código de segurança). [FA01] [FA02] [FE03].
6. Em seguida, ele submete os dados ao sistema. [RN03] [RN04]. 7. O sistema retorna para o cliente a confirmação do pedido.
8. O caso de uso é encerrado
Fluxo alternativo: [FA01]: A qualquer momento antes de submeter, o cliente pode selecionar cancelar.
[FA02]: É acionado o sistema de cartão de credito.
Fluxo de exceção: [FE01]: Caso o cliente não informe nenhum campo a seguinte mensagem é exibida: Dados obrigatórios.
[FE02]: Caso o código não seja valido a seguinte mensagem é exibida: Código de produto invalido.
[FE03]: Caso não seja informando os dados do cartão de credito exigido pela bandeira selecionada a mensagem é apresentada: Informe os dados do cartão de credito.
Regras de negocio: [RN01]: Se o cliente fornece apenas o CEP, o sistema coloca automaticamente a cidade e o estado. [RN02]: O sistema calculará os valores totais para cada produto fornecido.
[RN03]: O sistema verifica as informações fornecidas, marca o pedido como "pendente" e envia as informações de pagamento para o sistema de contabilidade e pagamento.
[RN04]: Quando o pagamento é confirmado, o pedido é marcado como "confirmado" e o número de pedido (NP) é dado ao cliente.
