Análise de Sistemas I
Aula 04 – Tipos de Requisitos Unidade Joinville
Dentro da Análise de Requisitos, ainda distinguimos um requisito de outro:
Requisitos Funcionais
3
Funcionais:
Determinam “WHAT” é requerido (sem a preocupação do “HOW” será feito.
Derivados a partir dos Requisitos de Usuário.
Traduzem o que o sistema/produto precisa fazer para atender as necessidades dos usuários relacionados a um problema de negócio. Descrevem um comportamento que deve ser percebido pelo usuário. Definem as funcionalidades esperadas sob o ponto de vista de funções. Base para os Requisitos Não Funcionais e Detalhados.
Exemplos:
“O sistema deve emitir um comprovante para cada operação.”
“O usuário deve ser capaz de calcular gastos diários, semanais e mensais com pessoal.”
“O sistema deve emitir um relatório de operações diário.”
“O sistema de correio eletrônico deve validar a entrada de “User-ID” pelo funcionário observando os padrões de segurança.”
Requisitos Funcionais, existem independentemente de existir ou não software, pois são as atividades que um determinado negócio faz. Exemplo: Registrar o ponto dos funcionários.
Esta função existe, pois alguém irá usá-la para gerir seu negócio. Em si, o requisito funcional é "o que?"
O papel responsável, por esta atividade, normalmente é chamado de analista de negócio(cada empresa põe um nome: arquiteto de soluções, analista de processo, consultor de negócios, mas isto é puramente
5
Não Funcionais:
São atributos de qualidade que devem ser atingidos pelos requisitos funcionais, assim como, para todo o sistema/produto.
• Norteiam as atividades para o desenvolvimento do projeto/sistema. • Definem quão bem o sistema/produto deve ser operado, ao invés do que ele deve fazer.
• Impõem RESTRIÇÕES sobre “COMO” os requisitos funcionais serão implementados.
Derivados a partir dos Requisitos Funcionais. • Base para os Requisitos Detalhados.
6
Não Funcionais:
Tipos de Requisitos Não Funcionais:
Operacionais (Usabilidade e Sensoriais): aparência, “look-and-feel”, facilidade de uso
Performance: tempo de resposta
Interface: elementos (HW/SW) com os quais o sistema deve interagir ou comunicar-se
Recursos: limites como capacidade de memória, disco e processador Manutenção: quão fácil é corrigir defeitos e adaptar o software a novos requisitos
Recuperação: o que precisa ser feito antes e depois de uma falha Escalabilidade: habilidade do sofware continuar funcionando bem quando ampliado
Disponibilidade: razão entre o tempo durante o qual um software mantem-se operacional
Segurança: a segurança, a confidencialidade e a integridade do projeto/sistema
Políticos & Culturais: fatores humanos
7
Não Funcionais: Exemplo:
• “A base de dados deve ser acessada apenas por usuários autorizados.”
• “A capacidade de processamento deverá suportar em média 20 transações por segundo.”
• “O sistema deve suportar 1000 operações de I/O simultaneamente.” • “O banco de dados do sistema deve ser DB2.”
• “O correio eletrônico deve validar o “User-ID” em 5 seg. após o recebimento do dado.”
Requisitos Não Funcionais, existem apenas para dar suporte aos
Funcionais. Logo se não existir uma funcionalidade não tem como ter uma "Não Funcionalidade".
Exemplo:
-O ponto dos funcionários será feito no livro ponto.
-O ponto dos funcionários será feito via leitor biométrico. -O ponto dos funcionários será feito via código de barras. -O ponto dos funcionários será feito via RFID.
Nota-se que não funcionalidades cumprem apenas o quesito de "como fazer?" algo, no caso, o requisito funcional exemplificado "Registrar o ponto dos funcionários."
Nota-se também que ele não necessariamente precisa de um software para ser realizado, como no caso do uso de livro ponto.
O papel responsável, por esta atividade, normalmente é chamado de
analista de sistema, pois envolve aspectos mais técnicos, mas por vezes o analista de negócio também consegue fazê-la.
9
* Requisitos de Software, no entanto é o que elicitamos como útil e
possível de implementação num software, seja ele, Requisito Funcional ou Requisito Não Funcional.
O papel responsável, por esta atividade, normalmente é chamado de analista de sistema, que decidirá quais serão realmente usados no
software. Afinal nem todos os requisitos funcionais e não funcionais talvez sejam de implementação viável.
Regras de Negócio:
São políticas, condições ou restrições que devem ser consideradas na execução dos processos existentes em uma organização.
Descrevem a maneira pela qual a organização funciona.
Estas regras são identificadas e documentadas no chamado modelo de regras do negócio.
A descrição do modelo de regras do negócio pode ser feita utilizando-se texto informal, ou alguma forma de estruturação.
Regras do negócio normalmente têm influência sobre um ou mais casos de uso.
Os identificadores das regras do negócio devem ser adicionados à descrição do caso de uso.
11
Exemplos:
Regras de Negócio
O valor total de um pedido é igual à soma dos totais dos itens do pedido acrescido de 10% de taxa de entrega.
Um professor só pode estar lecionando disciplinas para as quais esteja habilitado.
Um cliente do banco não pode retirar mais de R$ 1.000 por dia de sua conta.
Os pedidos para um cliente não especial devem ser pagos antecipadamente.
Regras de Negócio, a exemplo do requisito funcional, também independe do software, porém nem tudo é possível inserir como regra de negócio, observando os requisitos de Software.
Exemplo:
-Caso o registro do ponto ultrapasse 10 minutos do horário de início do turno, será descontado do banco de horas do funcionário.
-Caso o registro do ponto ultrapasse 10 minutos do horário de término do turno, será adicionado no banco de horas do funcionário.
Estas regras somente existem, e fazem sentido de serem tratadas no software, porque existe um requisito funcional que faz "Registrar o ponto dos Funcionários".
13
Agora uma regra que o software não tem controle, não faz sentido ser escrita.
Exemplo:
-O funcionário tem que registrar as ausências por fumar.
Esta regra depende do fator humano, ou seja, se a pessoa não fizer o registro desta ausência, o sistema não saberá.
O papel responsável, por esta atividade, normalmente é chamado de analista de negócio e por último o analista de sistemas.
Agora a relação entre os Requisitos X Regras, o melhor é usar matrizes: Requisitos Funcionais X Requisitos Não Funcionais
Requisitos Funcionais X Regras de Negócio
Objetivo: identificar requisitos funcionais, não funcionais e regras de negócio.
O sistema permite que o aluno forneça críticas e sugestões quanto à avaliação;
O sistema permite que o fiscal libere a avaliação ao aluno;
O sistema permite a visualização das questões para revisão, após o “score” ter sido apresentado;
O sistema permite que o Cliente pesquise preços de produtos.
O sistema permite que o Cliente selecione um produto listado pra ir à página do Fornecedor.
O sistema permite que um Fornecedor seja avaliado pelo Cliente. A avaliação é de cinco níveis: péssimo, ruim, regular, bom, ótimo. Ao indicar um produto ou fornecedor, deve informar o e-mail do remetente e do destinatário.
Somente pode indicar produto ou fornecedor, um Cliente registrado e validado no sistema.
15
Objetivo: identificar requisitos funcionais, não funcionais e regras de negócio.
Para realizar pesquisas não é necessário o Cliente estar registrado e validado pelo sistema.
O sistema permite que um produto seja avaliado pelo Cliente. O sistema permite que um produto seja indicado pelo Cliente.
Quantidade de alunos possíveis: uma oferta de disciplina não pode ter mais de 40 alunos inscritos.
Pré-requisitos para uma disciplina: um aluno não pode se inscrever em uma disciplina para a qual não possua os pré-requisitos necessários. O sistema permite que o aluno comente e solicite a revisão de cada questão, que entenda não estar bem formulada;
O sistema apresenta as questões respondidas incorretamente em vermelho, na visualização das questões para revisão;
Atividades 2:
Objetivo: identificar requisitos funcionais, não funcionais e regras de negócio.
O sistema permite que o aluno informe que terminou a avaliação para que a mesma seja corrigida.
Quando o tempo máximo de realização da avaliação for alcançado, ou o aluno informar o término da avaliação, o sistema submete a mesma à correção, apresentando o “score”.
Após submeter a avaliação à correção, não é mais permitido alterar as respostas, mas apenas visualizá-las.
O aluno somente inicia a avaliação, após a liberação realizada pelo fiscal.
A avaliação deve ser feita utilizando o recurso visual de estrelas.
Quantidade máxima de inscrições por semestre letivo: em um semestre letivo, um aluno não pode se inscrever em uma quantidade de
disciplinas cuja soma de créditos ultrapasse 20. Atividades 3:
17
Referências Bibliográficas:
PFLEEGER, Shari Lawrence. Engenharia de software: teoria e prática. São Paulo: Prentice Hall, 2004
PRESSMAN, Roger S.; SANTOS, José Carlos Barbosa dos. Engenharia de Software. 7ª ed. São Paulo: Makron Books, 2007. POMPILHO, S.. Análise Essencial : Guia Prático de Análise de Sistemas. 2ª ed. Rio de Janeiro: Ciência Moderna, 2002.
