EngenhariaRequisitos

INSTITUTO FEDERAL CATARINENSE

Campus Ibirama

Engenharia de Requisitos

Engenharia de Requisitos

● São os processos usados para descobrir, analisar, e validar os requisitos do projeto de software

● Atividades

– Estudo de viabilidade – Elicitação

– Especificação

Estudo de Viabilidade

● É a fase inicial do projeto, e tem como objetivo decidir se vale a pena ou não desenvolver o sistema

Estudo de Viabilidade

● Na analise de viabilidade verifica-se:

– Se o projeto pode ser feito ou não;

– Se já existe algo parecido que resolva o problema; – Decidir entre “Make or Buy";

– O sistema pode ser desenvolvido com a tecnologia

atual e com os recursos disponíveis

– Existência de um sistema atual dentro da empresa – Restrições

Estudo de Viabilidade

● Ao final da analise de viabilidade tem-se um relatório que recomenda ou não o desenvolvimento do projeto;

● O relatório pode propor mudanças (no escopo,

orçamento, prazos, etc.) com o objetivo de tornar o projeto viável;

Análise de Requisitos

● Caso a análise de viabilidade aponte que é viável desenvolver o

sistema, inicia-se a fase de elicitação e análise dos requisitos

● Atividades realizadas nessa etapa:

– Compreensão aprofundada do domínio/problema; – Identificação das partes interessadas;

– Obtenção dos requisitos (funcionais e não funcionais);

– Identificação e análise de problemas, restrições do ambiente,

software, hardware, orçamento, etc...;

Análise de Requisitos

– Os clientes podem não saber exatamente o que

desejam/esperam do sistema;

– Os requisitos identificados podem ser inatingíveis ou

inviáveis (do ponto de vista técnico, econômico, tecnológico, etc...);

– Cada parte interessada pode ter pontos de vista

diferentes ou expressar uma mesma ideia de formas distintas;

Análise de Requisitos: Técnicas

● Entrevistas com o cliente; ● Etnografia;

● Sistemas existentes ou análogos; ● SAC;

● Soluções do usuário; ● Workshop;

● Prototipação; ● Cenários;

Entrevista com o Cliente

● Fonte primaria de requisitos;

● Entrevistas fechadas e abertas;

● Obter um entendimento geral (O que cada stakeholder

faz?);

● Desejável que a quantidade de stakeholders seja reduzida

Questões Importantes

● Qual o principal objetivo da solução?

● Que resultados a solução deve apresentar?

● Que problemas a solução enfrentaria (tanto comercial quanto técnica)?

● Conte sobre o ambiente de negócios onde a solução será usada.

Questões Importantes

● Você é a pessoa certa para responder? Suas respostas são oficiais?

● Minhas questões são relevantes para o problema?

● Mais alguém pode fornecer informações adicionais?

● Existe algum documento oficial que podemos incluir?

Etnografia

● Trabalhe com o usuário;

● Passe um tempo no ambiente dele;

● Peça para ele contar o que esta fazendo;

● Porque esta demorando em alguma atividade em particular;

Sistemas Existentes ou Análogos

● Normalmente já existe uma solução informatizada;

● Verificar os processos que já foram sistematizados;

● Lista de principais relatórios e gráficos;

● Cuidado: não ser subjugado e viciar pelo

SAC – Sistema de Atendimento

● Descubra os problemas dos clientes do seu cliente;

● Se a empresa busca uma solução, e porque não deve estar atendendo suficientemente os seus clientes;

Soluções do Usuário

● Ele resolveu o problema com uma planilha?

● Anotações

● Lembretes

● Levar muito serio esses artefatos, pois a vida do

Workshop

● Discussões sobre requisitos já levantados;

● Confrontar diferentes pontos de vista;

● O desejo de um usuário pode ir contra o desejo de outro;

● Pauta fechada: perguntas e requisitos pontuais;

Prototipação

● Validar o entendimento que o engenheiro teve do cliente;

● E uma técnica que pode ser usada em um estágio mais avançado da fase de requisitos;

Cenários

● Peça ao usuário para relatar exemplos da vida real;

● Podem criticar cenários com sistemas existentes;

Análise de Requisitos

● Após o levantamento dos requisitos é realizada a

negociação:

– Classificação e agrupamento dos requisitos com base nas

funcionalidades;

– Resolução de conflitos;

– Priorização de requisitos (ou grupo de requisitos);

– Confirmação do conjunto de requisitos (com base nos

objetivos do sistema)

– Cliente confirma o conjunto de requisitos levantados (É

Especificação dos Requisitos

● Formalização dos requisitos por meio de um documento

ou modelo

– “ O sistema DEVE .... “

● Um requisito especifica uma funcionalidade externamente

visível pelo usuário ou um atributo de um sistema

– Serviços fornecidos pelo sistema; – Restrições operacionais;

Especificação dos Requisitos

● O que um software deve fazer dentro de certas restrições

● Tarefa mais difícil e importante para um engenheiro de software

Tipos de Requisitos

● Funcionais, não funcionais e regras de negocio;

● Usuário e sistema;

Requisitos Funcionais

● Serviços que o sistema deve fornecer;

● Como o sistema deve reagir a entradas específicas;

● O que o sistema não deve fazer;

● Independente de linguagem;

Requisitos Funcionais: Exemplos

● O sistema deve permitir gerenciar pedidos de venda

● O sistema pode permitir gerar relatórios de vendas

mensais

● O sistema deve permitir a emissão de notas fiscais

Requisitos Não Funcionais

● São aplicados a todo o sistema (maior abrangência);

● Restrições que medem a qualidade do software;

● Podem restringir o próprio processo;

Requisitos Não Funcionais: Exemplos

● O tempo de resposta máximo para relatórios deve ser 20

segundos

● Toda tela deve ter uma pagina de ajuda

● O sistema deve ser desenvolvido utilizando a linguagem

Java

Regras de Negócio

● Funcionalidades que restringem os requisitos funcionais;

● Detalham regras de calculo ou do processo;

Regras de Negócio: Exemplos

● Um pedido pode ter no máximo 10 itens

● Pode ser comprado no máximo R$ 100.000,00 de um

fornecedor por mês

● Um pedido não pode ser alterado

Requisitos de Usuário

● São declarações em linguagem natural

acompanhadas de diagramas intuitivos de quais

serviços são esperados do sistema e das restrições sob as quais ele deve operar

● Devem estar em um nível de abstração mais alto, de modo que sejam compreensíveis pelos usuários do sistema que não possuem conhecimento técnico

Requisitos de Sistema

● Definem detalhadamente as funções, serviços e restrições do sistema

● São versões expandidas dos requisitos de usuário usados pelos desenvolvedores para projetar,

Requisitos Permanentes

● Os requisitos estão bem compreendidos?

● Funcionalidade menos propensas a sofrerem alterações no desenvolvimento e com o sistema concluído;

Requisitos Voláteis

● Sofrem forte influência de ambientes externos não

controlados;

● Mercado ou cliente não maduros (não sabem exatamente o

que querem)

● Tecnologias não dominadas;

Defina um Requisito por Vez

● O software DEVE permitir o cadastro de clientes

● O software DEVE negar o cadastro de dois clientes com o mesmo CNPJ

● O software deve permitir o cadastro de clientes e

deve negar o cadastro de clientes com o mesmo CNPJ

Evite as Palavras...

● E, OU, SOMENTE SE, EXCETO, SE NECESSÁRIO, MAS,

CONTUDO, POSSÍVEL, ENTRETANTO, USUALMENTE, GERALMENTE, FREQUENTEMENTE, TIPICAMENTE, AMIGÁVEL, PROVAVELMENTE, VERSÁTIL, FLEXÍVEL, APROXIMADAMENTE, TÃO LOGO QUANTO, TALVEZ

● Ou similares

● Estas palavras fazem com que os requisitos não fiquem bem

Evite o Uso de Adjetivos

● O software DEVE permitir o registro dos clientes da empresa

● O software DEVE permitir o registro dos clientes da

Matriz de Rastreabilidade: RF X RN

● Um novo requisito é um detalhamento de um requisitos anterior?

● Transformar este novo requisito em regra de negócio, e criar a rastreabilidade

Matriz de Rastreabilidade: RF X RN

Exercício

● Uma administradora de condomínios deseja ter a possibilidade

de imprimir seus próprios boletos bancários. Como os contratos tem duração de 12 meses, quando um cliente vir assinar um novo contrato, o atendente já pode imprimir e entregar no mesmo instante os boletos ao cliente. Os boletos vencem sempre no dia 10 de cada mês.

● Dois dias úteis após o dia 10, o tesoureiro da administradora

baixa do banco a remessa de boletos pagos. Após analisar os pagamentos, ele entrega ao atendente uma relação de todos os clientes em atraso. O atendente liga para cada um dos clientes lembrando do atraso no pagamento da parcela