Tipos de Requisitos de Software

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

AULA 4- GESTÃO DE REQUISITOS
Tipos de requisito
Requisitos do usuário
Requisitos do sistema
funcionais
não-funcionais
produto
domínio
organizacionais
externos
Requisitos de Software
Sommerville(2007): 
Requisitos de um sistema são descrições dos serviços fornecidos pelo sistema e as suas restrições operacionais
Refletem as necessidades dos clientes
Engenharia de SW: é o processo de descobrir, analisar, documentar e verificar estes serviços e restrições. 
Requisito não é utilizado de forma consistente. Ora ele pode ser uma declaração de alto nível, abstrata; ora pode ser uma definição formal e detalhada. 
“ Se uma empresa deseja estabelecer um contrato para o desenvolvimento de um projeto de SW, ela precisa definir suas necessidades de maneira suficientemente abstrata. [...] Os requisitos devem ser redigidos de forma que os diversos fornecedores apresentem suas propostas, oferecendo, talvez, diversas maneiras de atender às necessidades do cliente. Após a aprovação do contrato, o fornecedor deve redigir uma definição mais detalhada do sistema para o cliente, de modo que o cliente possa compreender e validar o que o software fará. Estes dois documentos podem ser chamados de documentos de requisitos do sistema.”
 
Requisitos de Software
Requisitos de usuário
Declaração abstrata de alto nível
Escritos para usuários do sistema com pouco ou nenhum conhecimento técnico
Devem especificar somente o comportamento externo do sistema
Não deve conter jargões de SW
Escritos em linguagem simples, com tabelas, formulários e diagramas intuitivos
Não se preocupam em saber como o sistema funcionará (uso de banco de dados, linguagem de programação etc). 
 
Requisitos de Software
Problemas dos requisitos de usuário
Falta de clareza no uso da linguagem natural, o que pode tornar o documento prolixo, difícil de ser lido.
Confusão na definição das características funcionais do SW, nas metas do sistema (pedidos não-realistas, seja por motivo técnico ou por motivo de orçamento, por exemplo)
Fusão de requisitos (usuários distintos podem expressar os mesmos desejos por meio de diferentes descrições)
“Coloque em uma sala três interessados e pergunte a eles que tipo de sistema desejam. Você provavelmente obterá muitas opiniões diferentes.”
(PRESSMAN, 2005)
 
 
Requisitos de Software
Problemas dos requisitos de usuário
Exemplo: imagine o seguinte discurso entre um desenvolvedor e um cliente. 
Desenvolvedor: 
O que o senhor deseja do sistema?
Usuário: 
Eu tenho uma locadora de DVD. Gostaria que qualquer um pudesse ver na internet a opção de filmes que tenho. Quando meu cliente estiver cadastrado, ele poderá alugar filmes no sistema. Além disso, eu queria também que houvesse um cadastro de promoções, previamente autorizado, a ser oferecido de vez em quando. Preciso que o sistema tenha também um controle do saldo financeiro dos clientes para autorizar ou não novas locações de filmes. 
Algumas perguntas básicas: 
Quem vai cadastrar um novo cliente na locadora? O próprio cliente ou o funcionário da locadora?
A partir de qual momento um novo cliente poderá alugar os filmes? 
Quem vai autorizar o cadastro de promoções? 
Ainda em relação ao fator promoção, o que significa “de vez em quando”?
Como o sistema deverá controlar o saldo financeiro dos clientes? A partir de qual momento o cliente pode ser impedido de continuar a alugar os filmes na locadora?
 
Requisitos de Software
Problemas dos requisitos de usuário
A contribuição de Pfleeger (2003), suportada por Sommerville (2007)
Separação dos requisitos em três categorias:
1 – Requisitos obrigatórios
2 – Requisitos altamente desejáveis, mas não necessários
3 – Requisitos que são possíveis, mas poderiam ser eliminados
IMPORTANTE:
FILHO (2009) destaca que devem ser deixados de fora os chamados requisitos implícitos, que são expectativas cobradas por clientes e usuários, mas não documentadas.
Requisitos de Software
Exemplo:
A loja TEM TUDO deseja lançar um cartão de crédito para seus clientes. Quais seriam os requisitos do sistema de desenvolvimento de SW para cobrança do cartão de crédito da loja? 
1-Requisitos obrigatórios
O sistema deve ser capaz de relacionar as despesas atuais, somá-las, verificar se há resquícios de débitos não pagos do mês anterior, calcular estes débitos atrasados com juros e sumarizar os dados para pagamento no vencimento
2-Requisitos altamente desejáveis
O sistema poderia agrupar as despesas para ajudar o consumidor a entender onde ele está tendo os maiores gastos. 
3-Requisitos possíveis, mas que podem ser eliminados
O sistema poderia exibir os créditos em preto e os débitos em vermelho. 
Tipos de requisito
Requisitos do usuário
Requisitos do sistema
funcionais
não-funcionais
produto
domínio
organizacionais
externos
Requisitos de Software
Requisitos de Sistema
São versões expandidas dos requisitos de usuário
Definem, detalhadamente, os serviços e as restrições operacionais do sistema
Servem como ponto de partida do sistema
Exigem dos leitores um conhecimento mais preciso do objetivo do sistema
Não estão relacionados a como o sistema poderá ser projetado ou implementado
De forma ideal, os requisitos de sistema devem descrever simplesmente o comportamento externo do sistema e suas restrições de operação. 
Tipos de requisito
Requisitos do usuário
Requisitos do sistema
funcionais
não-funcionais
produto
domínio
organizacionais
externos
Requisitos de Software
Requisitos de Sistema
Funcionais
Descrevem o que o sistema deve fazer ou as declarações de serviços que o sistema deve fornecer, como o sistema deve se comportar em determinadas situações, podendo inclusive estabelecer O QUE o sistema não deve fazer. 
Exemplos de requisitos funcionais
-O sistema de biblioteca online deve ser capaz de realizar uma busca em todo o conjunto inicial de banco de dados, ou selecionar um subconjunto com base no mesmo 
-O sistema deve fornecer telas adequadas para o usuário
Para cada pedido, deve ser alocado um identificador único (ORDER_ID)
Requisitos de Software
Requisitos de Sistema
Funcionais
Devem ser completos, de forma a atender a todos os serviços exigidos pelo usuário (completeza)
Não devem ser contraditórios ou ambíguos (consistência)
Desafio para projetos grandes, pois: 
-Probabilidades de erros ou omissões em especificações de grande magnitude
-Diferentes stakeholders possuem diferentes ou inconsistentes necessidades
Tipos de requisito
Requisitos do usuário
Requisitos do sistema
funcionais
não-funcionais
produto
domínio
organizacionais
externos
Requisitos de Software
Requisitos de Sistema
Não-Funcionais
São requisitos não ligados às funções especificadas pelo sistema (desempenho, robustez, segurança, disponibilidade etc)
Geralmente são mais importantes do que os requisitos funcionais (se um sistema de controle de aeronaves não for seguro, todo o sistema será inútil). 
São subdivididos em: 
1 - Requisitos de produto: são requisitos ligados ao próprio produto (confiabilidade, robustez, rapidez, consumo de memória etc). Algumas sugestões trazidas por Sommerville (2007) como métricas para estes requisitos: 
Requisitos de Software
Propriedade
Medida
Velocidade
Transações processadas/seg
Tempo de resposta ao usuário/evento
Tempo derefreshna tela
Tamanho
K bytes
Memória RAM
Facilidade de uso
Tempo de treinamento
O sistema é amigável?
Confiabilidade
Tempo médio de falhas
Probabilidade de indisponibilidade
Taxa de ocorrência de falhas
Disponibilidade
Robustez
Probabilidade de que dados sejam corrompidos por falhas
Porcentagem de erros que causam falhas
Tempo de reinício depois de uma falha
Requisitos de Software
2 - Requisitos organizacionais: são aqueles oriundos de políticas e procedimentos que devem ser seguidos como processos padronizados (linguagem de programação, metodologia utilizada no projeto, documentação do projeto etc)
3 - Requisitos externos: definem se o sistema poderá interagir com fatores externos (outros sistemas em outras organizações). Podem entrar aqui
também requisitos para atendimento de leis específicas ou conformidade com aspectos éticos, por exemplo. 
Tipos de requisito
Requisitos do usuário
Requisitos do sistema
funcionais
não-funcionais
produto
domínio
organizacionais
externos
Requisitos de Software
Requisitos do sistema
Domínio – são derivados do domínio da aplicação do sistema. 
Geralmente incluem terminologias específicas
Necessitam de conhecimento especializado (área de negócios)
Normalmente são redigidos na linguagem do domínio da aplicação (jargões específicos, equações matemáticas), o que pode dificultar o entendimento dos engenheiros de SW
Apresentam grande probabilidade de esquecimento de informações importantes por serem claras demais para os usuários 
Dicas: 
Obter pontos de vista diferentes para identificar requisitos que possam ser conflitantes ou ambíguos 
Faça perguntas ao usuário, ainda que as mesmas sejam óbvias para ele!
Requisitos de Software
Uso de linguagem natural na engenharia de requisitos
Frequentemente usada para redigir especificações de requisitos de sistema e requisitos de usuários
Porém, requisitos de sistema são mais detalhados do que os requisitos de usuário
Questões críticas: 
Compreensão está diretamente ligada a um entendimento único das mesmas palavras e conceitos utilizados no projeto
A linguagem natural é flexível demais, possibilitando afirmar uma mesma realidade de distintas formas
Padronização de todos os requisitos de forma concisa e evitando-se inconsistências
Requisitos de Software
Proposta: uso de notações especializadas
Linguagem natural estruturada
Linguagens de descrição de projeto
Notações gráficas
Especificações matemáticas
Requisitos de Software
Linguagem natural estruturada (ex. pg. 89, tabela 6.3)
Escrita padronizada de todos os requisitos
Não há liberdade textual
Mantém a facilidade de expressão
Limitam terminologias utilizadas
Usam templates para especificar os requisitos do sistema
Eliminam imprecisões da linguagem natural, mas em computações mais complexas pode ser difícil ter de especificar os requisitos de forma integralmente consistente
Complemento: uso de notações gráficas
Requisitos de Software
Notações Gráficas
Proposta de Sommerville (2007): 
Modelagem de Casos de uso
Descrevem uma sequência de ações que representam um cenário principal (perfeito) e cenários alternativos com o objetivo de demonstrar o comportamento de um sistema (ou parte dele) através de interações com atores. 
Possuem 3 componentes: 
Ator - é um papel que estimula,solicita ações ou eventos do sistema e recebe reações. 
Casos de uso - documento narrativo que descreve uma sequência de eventos feitos por um ator no uso do sistema.
Sistema - o sistema a ser modelado
Requisitos de Software
Modelagem de Casos de uso
Algumas perguntas são frequentes em modelagens de caso de uso: 
Como identificar os casos de uso?
Casos de uso são interações entre atores e o sistema (AÇÕES INICIADAS PELO ATOR E AÇÕES/REAÇÕES DO SISTEMA)
-Quem usa o sistema?
-Quem inicia o sistema?
-Quem fornece os dados?
-Quem usa as informações?
ATORES
Modelagem de Casos de uso
Exemplo: vamos modelar utilizando um caso de uso para a compra de um produto em uma máquina automática.
Comprar produto
Cliente
Dono
Fornecedor
Repor produto
Retirar dinheiro
Atores: cliente (compra o produto), fornecedor (repõe o produto) e dono (retira o dinheiro do produto)
Caso de uso comprar produto:
Nome do caso de uso – comprar produto
Atores - cliente
Descrição – o caso de uso é realizado quando um cliente se dirige ao caixa para comprar o produto que deseja 
Caso de uso repor produto:
Nome do caso de uso – repor produto
Atores – fornecedor, dono
Descrição – o caso de uso é realizado em conjunto pelo fornecedor e pelo dono da máquina, sendo este o responsável por supervisionar o processo de reposição de produtos 
Caso de uso retirar dinheiro:
Nome do caso de uso – retirar dinheiro
Atores - dono
Descrição – o caso de uso é realizado quando o dono se dirige ao caixa para retirar o dinheiro das vendas da máquina
Modelo para descrição de Casos de Uso
Númerodo caso de uso
[Numeração de controle do caso de uso.]
Nome do Caso de Uso
[Nome do caso de uso.]
Ator(es)
[Atores que participam do caso de uso.]
Descrição
[Neste item é apresentado o propósito do caso de uso de forma detalhada.]
Pré-condições
[Condições que devem estar satisfeitas para que o caso de uso possa ser iniciado.]
Pós-condições
[Condições que devem ser satisfeitas após o término do caso de uso. Podem ou não ocorrer]
Cenário Principal
[Descrição, passo a passo, de “o que” o sistema deve fazer. Também deverão ser escritas as regras de negócio específicas para este caso de uso, quando houver.
1 - passo1
2 - passo2 (CA 002 – este passo pode, em determinada condição, remeter ao cenário alternativo número 002)
Cenário Alternativo
[CA NNN – Fluxos Alternativos]
[Descrição de cada cenário alternativo possível para este caso de uso, detalhando os passos a serem seguidos].
Exceções
[EXC NNN – Exceção]
[Descrição dos passos a serem seguidos para exceção identificada para o caso de uso.]
Inclusão (include)
Apresentar os casos de uso incluídos neste - <<include>>.]
Extensão (extend)
Apresentar os casos de uso que o estendem - <<extends>>.]
Regras de Negócio
[Lista das Regras de negócio associadas a este Caso de Uso, se houver.]
Exemplo de Diagrama de caso de uso
Caso de uso Cadastrar Cliente
1 - Descrição Sumária
Permite que um cliente se cadastre no sistema.
2 - Atores
Cliente.
3 - Prioridade
Essencial (X) 	Importante ( )	Desejável ( )
4 - Entradas
Nome
Data de nascimento
CPF
RG
Endereço (rua, número, complemento, bairro, cidade, CEP)
Login
Senha
Dependentes
Telefone
Celular
E-mail
5 - Pré-condições
 1.O login e a senha só contêm letras e números
 2.Não há cliente cadastrado com o mesmo login
 3.Nome, CPF, endereço, login, senha, e-mail são campos obrigatórios
6 - Saídas
Nenhuma
Caso de uso Cadastrar Cliente
7 - Pós-condições
1.O cliente está cadastrado no sistema
Fluxo de Eventos
Fluxo Básico
1.O usuário escolhe a opção de cadastrar cliente;
2.O usuário informa as entradas necessárias para seu cadastro;
3.O sistema valida as entradas e cadastra o cliente.
Fluxos Alternativos
Dados inválidos
Se no passo 3, alguns dos dados obrigatórios não estiverem preenchidos ou o login ou senha estiverem com formato inválido (não contiverem apenas letras e números):
1.Uma mensagem de erro é exibida relatando os campos inválidos ou não preenchidos;
2.Volta ao passo 2 do fluxo básico.
 
Cliente já cadastrado
Se no passo 3, o sistema verificar que existe outro cliente cadastrado com o mesmo login ou o mesmo CPF:
1.Uma mensagem de erro é exibida relatando a duplicidade de cliente;
2.Fim do caso de uso.
Requisitos de Software
PONTO FINAL DA ANÁLISE DE REQUISITOS:
Documento de Requisitos de SW:
Inclui os requisitos de usuário do sistema e uma especificação detalhada dos requisitos do sistema
Documento extremamente relevante no processo de desenvolvimento de SW
 
PADRÃO SUGERIDO PELO IEEE: IEEE/ANSI 830-1998
Contém boas recomendações de como redigir requisitos
Serve como um modelo a se adaptado às necessidades de uma organização
Sofre críticas pelos defensores dos métodos ágeis de desenvolvimento