AULA_03 (1)

Prévia do material em texto

TIPOS DE REQUISITOS
 Requisitos de usuário.
 Requisitos de sistema.
 Requisitos funcionais.
 Requisitos não funcionais.
 Requisitos de domínio.
Requisitos de usuário
 São descrições feitas em linguagem natural através de
tabelas, diagramas e formulários simples dos serviços
que são esperados do sistema e suas restrições.
 NÃO DEVEM SER UTILIZADOS JARGÕES DE
SOFTWARE.
Requisitos de usuário
 PROBLEMAS
◦ FALTA DE CLAREZA.
◦ CONFUSÃO DE REQUISITOS.
◦ FUSÃO DE REQUISITOS.
TIPOS DE REQUISITOS
 Requisitos de usuário.
 Requisitos de sistema.
 Requisitos funcionais.
 Requisitos não funcionais.
 Requisitos de domínio.
Requisitos de sistema
 Descrevem como os requisitos de usuário devem ser
fornecidos pelo sistema. Portanto, definem,
detalhadamente, as funções, os serviços e as restrições
operacionais do sistema.
Requisitos 
de usuário
Requisitos 
de sistema
Gerentes de clientes.
Usuários finais de sistemas.
Eng. de clientes.
Gerentes de fornecedores.
Arquitetos de sistemas
Usuários finais de sistemas.
Eng. de clientes.
Arquitetos de sistemas
Desenvolvedores de SW.
TIPOS DE REQUISITOS
 Requisitos de usuário.
 Requisitos de sistema.
◦ Requisitos funcionais.
◦ Requisitos não funcionais.
◦ Requisitos de domínio.
Requisitos funcionais
 Descrevem o que o sistema deve fazer, suas entradas,
saídas, exceções, etc.
◦ Cadastros – Especificar entradas, saídas, modelos de
tela.
◦ Relatórios – Especificar entradas, saídas, tipos de
saída.
Requisitos não funcionais
 NÃO estão diretamente relacionados às funções
específicas fornecidas pelo sistemas. Podem definir
restrições, como a capacidade dos dispositivos de E/S.
Requisitos não funcionais
EXERCÍCIO
 Quantas pessoas vão utilizar o software? Desse número, quantas 
utilizarão simultaneamente? (não precisa ser um valor fechado… 
pode ser um range: entre 100 e 200 pessoas utilizarão e é 
esperado que no máximo 50 utilizem simultaneamente);
 Dos relatórios previstos, quais podem ser gerados por 
processamento batch (de madrugada) e quais devem ser online 
(com dados do momento)? Qual o tempo aceitável para processar 
e gerar um relatório online?
 Qual o tempo de resposta esperado para as principais 
funcionalidades do sistema? E para as outras?
 Qual tipo de acesso a aplicação vai ter? Somente via intranet? 
Internet?
 Qual o perfil dos usuários que vão acessar a aplicação? Possuem 
conhecimento de internet? São usuários avançados?
É desejável que a maior parte das funcionalidades da aplicação 
possam se acessadas via teclado (sem auxilio do mouse)? 
A aplicação deve ser compatível com quais versões do browser e/ou 
sistema operacional?
Quais os padrões de implementação esperados? Os desenvolvedores 
podem escrever o código em qualquer idioma? Podem utilizar 
qualquer banco de dados e qualquer tecnologia?
Qual a segurança esperada para o trafego de dados? Toda 
comunicação entre o servidor e o browser tem que ser 
criptografada usando SSL? Será adquirido o certificado SSL? Ou a 
aplicação não tem dados criticos e confidenciais / vai ser executada 
em uma rede segura?
EXERCÍCIO
 Quantas pessoas vão utilizar o software? Desse número, quantas utilizarão simultaneamente? (não 
precisa ser um valor fechado… pode ser um range: entre 100 e 200 pessoas utilizarão e é esperado que 
no máximo 50 utilizem simultaneamente); Produto / desempenho
 Dos relatórios previstos, quais podem ser gerados por processamento batch (de madrugada) e quais 
devem ser online (com dados do momento)? Qual o tempo aceitável para processar e gerar um 
relatório online? - Produto / desempenho
 Qual o tempo de resposta esperado para as principais funcionalidades do sistema? E para as outras? 
Produto / desempenho
 Qual tipo de acesso a aplicação vai ter? Somente via intranet? Internet? Produto 
 Qual o perfil dos usuários que vão acessar a aplicação? Possuem conhecimento de internet? São 
usuários avançados? Produto / facilidade de uso
 É desejável que a maior parte das funcionalidades da aplicação possam se acessadas via teclado (sem 
auxilio do mouse)? Produto / facilidade de uso
 A aplicação deve ser compatível com quais versões do browser e/ou sistema operacional? Produto / 
portabilidade
 Quais os padrões de implementação esperados? Os desenvolvedores podem escrever o código em 
qualquer idioma? Podem utilizar qualquer banco de dados e qualquer tecnologia? Organizacional
 Qual a segurança esperada para o trafego de dados? Toda comunicação entre o servidor e o browser 
tem que ser criptografada usando SSL? Será adquirido o certificado SSL? Ou a aplicação não tem dados 
criticos e confidenciais / vai ser executada em uma rede segura? Produto / Organizacional
TIPOS DE REQUISITOS
 Requisitos de usuário.
 Requisitos de sistema.
◦ Requisitos funcionais.
◦ Requisitos não funcionais.
◦ Requisitos de domínio.
Requisitos de domínio
 Estão relacionados com o domínio da aplicação do
sistema.
 Os especialista do domínio podem deixar determinadas
informações fora de um requisito, simplesmente por
serem muito óbvias para eles. Contudo, pode não ser
óbvia para os desenvolvedores do sistema e eles podem,
portanto, implementar o requisito de forma equivocada.
Requisitos
 Em uma especificação de requisitos é INDISPENSÁVEL
que haja tanta preocupação com os requisitos 
funcionais quanto com os requisitos não funcionais.
 Todos os requisitos não funcionais, existem para 
atender, por completo, um requisito funcional.
EXERCÍCIO
 SISTEMA DE GESTÃO DE 
COMPROMISSOS + AGENDA.
◦ Defina cinco requisitos sem contato com o 
cliente.
◦ Elabore cinco perguntas para o cliente.
◦ Elabore cinco novos requisitos.
◦ Classificar funcionais e não funcionais.
EXERCÍCIO 
Em grupo de 4 alunos (2 desenvolvedores e 2 usuários),
simular uma reunião para especificação de requisitos de um
Sistema de Controle de Biblioteca (use seus conhecimentos
sobre o processo da Biblioteca para fazer o papel de
usuário).
 Ao término da “reunião”, crie um documento com:
◦ Nome do sistema
◦ Áreas envolvidas
◦ Objetivos do sistema
◦ Restrições
◦ Descrição funcional (Lista de requisitos funcionais e não funcionais.)
Técnicas para levantamentos de requisitos
Entrevistas e Questionários
 Esta é a técnica mais simples e eficaz, é muito utilizada na fase
inicial do levantamento de requisitos, o sucesso desta técnica é
atrelada à alguns fatores.
 Influência do entrevistador nas respostas do cliente: convém que o
entrevistador dê margem ao entrevistado para expor as suas idéias
sem as contestar logo no inicio.
 Relação pessoal entre os intervenientes na entrevista.
 Predisposição do entrevistado: caso, por exemplo, o papel do
entrevistado venha a ser afetado pela introdução de um sistema na
organização, este pode propositadamente dificultar o acesso à
informação.
Técnicas para levantamentos de requisitos
Workshops de requisitos
 O Workshop de Requisitos consiste numa técnica usada através de
uma reunião estruturada, da qual devem fazer parte um grupo de
analistas e um grupo representando o cliente, para então obter um
conjunto de requisitos bem definidos.
 Ao contrário das reuniões, promove-se a interação entre todos os
elementos presentes no workshop fomentando momentos de
descontração como forma de dinamizar o trabalho em equipe,
existindo um facilitador neutro cujo papel é conduzir a workshop e
promover a discussão entre os vários intervenientes (ainda que não
tenha realmente poder de decisão).
 As tomadas de decisão devem seguir processos bem definidos e
devem resultar de um processo de negociação, mediado pelo
facilitador.
Técnicas para levantamentos de requisitos
Cenários
 Uma forma de levar as pessoas a imaginarem o
comportamentode um sistema é o uso de cenários.
 Através de exemplos práticos descritivos do
comportamento de um sistema, os seus utilizadores
podem comentar acerca do seu comportamento e da
interação que esperam ter com ele.
Técnicas para levantamentos de requisitos
Cenários
 Trata-se de uma abordagem informal, prática e aplicável a
qualquer tipo de sistema. De um modo geral, os cenários
devem incluir os seguintes elementos:
Estado do sistema no início do cenário.
Sequência de eventos esperada.
Listagem de erros que podem ocorrer no decorrer dos
eventos do cenário e de como estes erros serão tratados.
Outras atividades que podem ser executadas ao mesmo
tempo que as deste cenário.
Estado do sistema depois de o cenário terminar.
Técnicas para levantamentos de requisitos
Prototipagem
 Neste tipo de abordagem apenas são desenvolvidas algumas
funcionalidades sendo normalmente desenvolvidas primeiro
aquelas que são mais fáceis de compreender por parte do
utilizador e que lhe podem trazer maior valor acrescentado.
 O uso de protótipos deve ser considerado apenas mediante
uma análise custo-benefício, já que os custos de
desenvolvimento de um protótipo podem facilmente crescer,
sendo particularmente úteis em situações em que a interface
com os utilizadores é, para eles, um aspecto crítico.
Técnicas para levantamentos de requisitos
Prototipagem
 O uso de prototipagem é feito em diversas fases do
processo de engenharia de requisitos (por exemplo na
identificação, análise e validação).
 Trata-se de uma versão inicial do sistema, baseada em
requisitos ainda pouco definidos, mas que pode ajudar a
encontrar desde cedo falhas que através da
comunicação verbal não são tão facilmente
identificáveis.