ENGENHARIA DE REQUISITOS

CONTEXTO

• Crescente custo com manutenção de sistemas.

• Custo das atividades relacionadas a análise de requisitos é baixo.
• Grande parte dos problemas surge nas fases iniciais do projeto.
• Custo da correção dos problemas aumenta no decorrer do desenvolvimento.
CONTEXTO
CONTEXTO
● Fatores críticos para o sucesso de projetos de software (pesquisa Standish Group)
REQUISITOS
REQUISITOS

• Um requisito é uma característica do sistema ou a descrição de algo que o sistema é

capaz de realizar para atingir os seus objetivos.
• As descrições das funções e restrições são os requisitos do sistema.​
• Um requisito é uma propriedade que o software deve exibir para resolver algum
problema no mundo real.
• Uma condição ou uma capacidade que deve ser alcançada ou estar presente em um
sistema para satisfazer um contrato, padrão, especificação ou outro documento
formalmente imposto...
IMPORTÂNCIA DOS REQUISITOS

• Estabelecer uma base de concordância entre o cliente e o fornecedor sobre o que o

software fará.
• Fornecer uma referência para a validação do produto final.
• Reduzir o custo de desenvolvimento (requisitos mal definidos causam retrabalho). 
REQUISITOS FUNCIONAIS

• Requisitos diretamente ligados a funcionalidades do software:

• O software deve permitir o cadastro de clientes.
• O software deve permitir a geração de relatórios sobre o desempenho de
vendas no semestre.
• O software deve permitir o pagamento das compras através de cartão de
crédito.
REQUISITOS NÃO FUNCIONAIS

• Requisitos que expressam condições que o software deve atender:

• O software deve ser compatível com os browsers IE (versão 5.0 ou superior) e
Firefox (1.0 ou superior).
• O software deve garantir que o tempo de retorno das consultas não seja maior
do que 5 segundos.
REQUISITOS DE DOMÍNIO

• Requisitos derivados do domínio da aplicação:

• O calculo da média final de cada aluno é dado pela fórmula:
(Nota1 * 2 + Nota2 * 3)/5;
• Um aluno pode se matricular em uma disciplina desde que ele tenha sido
aprovado nas disciplinas consideradas pré-requisitos.
ENGENHARIA DE REQUISITOS

• Termo usado para descrever as atividades relacionadas à investigação e definição de

escopo de um sistema de software.
• Processo sistemático de desenvolvimento de requisitos através de um processo
cooperativo de análise.
• Resultados de observações são codificados em uma variedade de formatos e a
acurácia das observações é constantemente verificada.
• Processo de descobrir, analisar, documentar e verificar as funções e restrições do
sistema. 
ENGENHARIA DE REQUISITOS
ENGENHARIA DE REQUISITOS
ENTRADAS PARA O PROCESSO

• Descrições do que os stakeholders necessitam para suportar suas atividades;

• Informações a respeito do sistema que será substituído ou de qualquer sistema com
o qual o sistema sendo definido terá que interagir; ​
• Padrões vigentes na organização a respeito de práticas de desenvolvimento de
sistemas, gerência de qualidade, etc.; 
• Regulamentos externos, tais como leis, regulamentos de segurança ou saúde;
• Informações gerais sobre o domínio de aplicação. 
OBJETIVOS

• Estabelecer uma visão comum entre o cliente e a equipe de projeto em relação aos
requisitos que serão atendidos pelo projeto de software; ​
• Registrar e acompanhar requisitos ao longo de todo o processo de desenvolvimento;
• Documentar e controlar os requisitos alocados para estabelecer uma baseline para
uso gerencial e da engenharia de software; 
• Manter planos, artefatos e atividades de software consistentes com os requisitos
alocados.
OBJETIVOS
PRODUÇÃO DE REQUISITOS
PRODUÇÃO DE REQUISITOS

• Um dos documentos produzidos no início do processo de desenvolvimento de

software é a Especificação de Requisitos.
• É a base para as demais atividades de desenvolvimento e sua qualidade é
fundamental para o sucesso do projeto.
• Durante a produção de requisitos devemos possuir, além das atividades essências de
levantamento e especificação, atividades relacionadas a garantia de qualidade.
LEVANTAMENTO

• Obtenção dos requisitos do Software.

• Engenheiros de Software e Analistas trabalham com clientes e usuários finais.
• Objetivo de identificar o problema a ser resolvido, desempenho necessário, serviços
do sistema, restrições de hardware…
• Utilização de diversas técnicas de apoio as atividades de levantamento dos
requisitos.
LEVANTAMENTO

• ENTREVISTAS:
• Conversas realizadas com o usuário para esclarecimentos das necessidades.
• Podem decorrer de diferentes formas, de acordo com o estilo participativo do
cliente.
LEVANTAMENTO

• PROTOTIPAÇÃO:
• É uma versão inicial do sistema para experimentação
• Permite aos utilizadores identificar os pontos fortes e fracos do sistema
• Podem ajudar no levantamento e desenvolvimento, suportando requisitos mais
difíceis de perceber
• Ou também ajudam o desenvolvimento rápido de uma versão inicial do sistema
LEVANTAMENTO

• JAD (Joint Application Development): técnica que permite a interação entre

pessoas que necessitam tomar decisões que afetem múltiplas áreas de uma
organização
REGISTRO

• Após identificados e negociados os requisitos. Estes devem ser documentados.

• Servirá de base para o restante do processo de desenvolvimento.
• Necessário administrar o grande volume de informações geradas no levantamento.
• Os requisitos devem ser documentados num nível apropriado de detalhe.
• Facilita o controle de alterações, e a geração de versões do documento.
VERIFICAÇÃO

• Examina a especificação do software.

• Assegura que os requisitos foram definidos sem ambiguidades, inconsistências ou
omissões.
• Detecta e corrige possíveis problemas ainda durante a fase de definições dos
requisitos.
VERIFICAÇÃO

• Um tipo particular de revisão de software são as Inspeções:

• Processo de detecção de defeitos rigoroso e bem definido.
• Benefícios são maiores para artefatos do início do processo. Ex: documento de
requisitos.
VALIDAÇÃO

• Representa a aceitação do cliente sobre determinado artefato.

• Em Engenharia de Requisitos, significa aprovar junto ao cliente os requisitos que
foram especificados.
• Pode ser dificultado pelo cliente e/ou por um processo de validação inadequado da
empresa.
GERÊNCIA DE REQUISITOS
GERÊNCIA DE REQUISITOS

• Administrar os requisitos ao longo do tempo = Gerência de requisitos

• Requisitos são voláteis. Podem mudar conforme legislação, mercado, erros, etc.
• Precisa ser conduzida de forma ordenada.
• Os benefícios são vistos a médio prazo, mas administrados a curto prazo.
GERÊNCIA DE REQUISITOS

• Gerência de Configuração:
• Tem o objetivo de manter a integridade e consistência do software em meio às
mudanças
• Feito pela determinação de ferramentas e templates, de uma forma que sua
evolução seja passível de rastreamento
GERÊNCIA DE REQUISITOS

• Uma das técnicas empregadas é o "baseline":

• Checar validade
• Identificar os requisitos afetados
• Identificar dependências entre requisitos
• Assegurar mudança
• Estimar custos
• Obter acordo com usuário
BASELINE

• Em cada etapa do desenvolvimento, conjunto de definições deve ser estabelecido,

chamado de "baseline".
• Cada baseline guarda o estado do projeto, auxiliando na geração do próximo
baseline.
• Baselines ajudam a realizar modificações de forma controlada, possibilitando um
controle sistemático, e ajudando na avaliação da evolução do software.
RASTREABILIDADE

• É a habilidade de acompanhar a vida de um requisito em ambas as direções.

• Grande volume de informação gerada, pois tudo deve ser catalogado.
• Matriz de rastreabilidade.
• Os seus rastros podem ser de duas formas: Pré-rastreabilidade e Pós-rastreabilidade.
GERÊNCIA DE QUALIDADE DE REQUISITOS

• Correção: Todos os requisitos presentes no documento representam algo que deve

estar presente no sistema desenvolvido
• Não ambiguidade: Um requisito deve ser claro a ponto de poder ser interpretado
apenas de uma maneira.
• Completude: Um requisito deve descrever todas as demandas de interesse do
usuário
GERÊNCIA DE QUALIDADE DE REQUISITOS

• Consistência: Um conjunto não deve entrar em conflito com outros.

• Verificabilidade: Um requisito deve haver uma forma efetiva de verificar se esse
requisito cumpre sua especificação.
• Modificabilidade: O requisito deve poder ser modificado de forma simples e
consistente quanto ao seu estilo e estrutura.
CONCLUSÃO

• A engenharia de requisitos mostra-se extremamente importante em projetos de

desenvolvimento de software.
• Não garante a qualidade dos produtos gerados.
• É um pré-requisito para o sucesso no desenvolvimento de projetos atualmente.
• Qual é a vantagem de se empregar conceitos de Engenharia de
Requisitos em um projeto de Software?
 • Qual é a vantagem de se empregar conceitos de Engenharia de
Requisitos em um projeto de Software?

R: As vantagens são percebidas a longo prazo, onde serão

significativamente reduzidos os custos com possíveis erros
ocasionados nas etapas iniciais do desenvolvimento.
Estes custos não necessariamente são em dinheiro, como podem ser
em tempo, satisfação e qualidade.
• Qual é a importância do trabalho conjunto de analistas e
engenheiros de software, clientes e usuários finais para
identificação dos requisitos?
 • Qual é a importância do trabalho conjunto de analistas e
engenheiros de software, clientes e usuários finais para
identificação dos requisitos?

R: Uma das etapas mais importantes e críticas ao se lidar com

Engenharia de Requisitos, é a etapa do levantamento, cabendo aos
envolvidos uma completa dedicação ao entendimento da aplicação e
das reais necessidades que o software irá possuir junto aos usuários.
Provento um bom levantamento, facilitando as etapas futuras de
planejamento do software.
• A gerência de requisitos é necessária para manter o controle da
evolução do projeto. Quando são empregadas as técnicas da
gerência de requisitos? Quando vemos resultados? Se elas não
forem empregadas, quando perceberemos?
 • A gerência de requisitos é necessária para manter o controle da
evolução do projeto. Quando são empregadas as técnicas da
gerência de requisitos? Quando vemos resultados? Se elas não
forem empregadas, quando perceberemos?

R: As ténicas de gerência de requisitos precisam ser empregadas a

curto prazo, geralmente no inicio da etapa atual. Os resultados serão
vistos a médio prazo, quando o projeto começar a ficar complexo. Se
não houver gerência de requisitos, aparecerão problemas a longo prazo
pela falta de controle da evolução do projeto.