Engenharia de requisitos

Engenharia de Requisitos
• Ramo da engenharia de software envolvido
com os objetivos reais de funções de
sistemas de software e de restrições sobre
eles. (Zave, 1997)
• Termo relativamente novo que foi inventado
para cobrir todas as atividades envolvidas em
descobrir, documentar e manter um conjunto
de requisitos para um sistema baseado em
computador. (Sommerville e Sawyer, 1997)

Requisito
• Condição ou capacidade que um sistema de
software deve possuir ou atender,
determinada por contrato, padrão,
especificação ou qualquer outra forma de
imposição (IEEE, 1983 apud Davis 1993).
• Constitui-se de uma declaração completa do
que o sistema deverá fazer sem referir-se a
como o sistema o fará (Siddiqi e Shekaran,
1996).

Relação de o quê incluir como requisito
• Facilidades (funções do sistema) a nível de usuário (por
exemplo: o sistema deve imprimir o comprovante de
pagamento dos funcionários).
• Propriedades gerais do sistema (por exemplo: o acesso
a informações pessoais não dever ser permitido sem
autorização).
• Restrições específicas sobre o sistema (por exemplo:
excetuando-se documentos oficiais, deve-se evitar
informações em papel).
• Restrições sobre o desenvolvimento do sistema (por
exemplo: a base de dados deve ser implementada em
Oracle).
(Sommerville e Sawyer, 1997)

Problemas com Engenharia de Requisitos
Problemas de investigação de objetivos,
funções e restrições de um sistema de software:
•Sobrepor barreiras de comunicação.
•Gerar estratégias para converter objetivos vagos em
propriedades ou comportamento específico.
•Compreender prioridades e limites de satisfação.
•Gerar estratégias para estabelecer requisitos que
relacionem o sistema e os vários agentes de seu
ambiente.
•Estimar custos, riscos e programação de atividades.
•Garantir que os requisitos se complementam.

Problemas de especificação do
comportamento do sistema de software:
•Integrar múltiplas visões e representações.
•Avaliar estratégias alternativas para satisfazer
requisitos.
•Obter uma ERS completa, consistente e não ambígua.
•Verificar se o sistema especificado satisfaz os
requisitos.
•Obter especificações que se ajustem bem à atividade
de projeto e de implementação.

Problemas de gerenciamento de evolução de
sistemas e de famílias de sistemas:
•Reutilização de ERSs durante fases evolucionárias.
•Reutilização de ERSs para desenvolvimento de
sistemas similares.
•Reconstrução de requisitos (engenharia reversa de
requisitos).

Atividades da Engenharia de Requisitos
• Davis (1993): a análise do problema e a descrição do produto.
• Jark e Pohl (1994): eliciação, descrição e validação.
• Sommerville (1995): estudo de viabilidade, análise de requisitos,
definição de requisitos, e especificação de requisitos.
• Sommerville e Sawyer (1997): eliciação de requisitos, negociação e
análise de requisitos e validação de requisitos.
• Graham (1998): a eliciação de requisitos e a análise dos requisitos.
Não há unanimidade quanto aos termos a serem usados para
classificar as atividades do processo de engenharia de requisitos.
Na inexistência de consenso, divide-se a ER em:
• Análise do problema
• Descrição do produto
• Validação de requisitos

Análise do Problema
Contempla atividades de:
•expansão de informações e de conhecimento sobre o problema a
resolver, sobre o ambiente em que ocorre.
•identificação de quem são os interessados no sistema e
compreensão de suas necessidades.
•levantamento de restrições a possíveis soluções.
•Definição de funções e desempenho para o sistema de software.
A análise do problema estender-se-á até que o nível de
compreensão do problema e de seu domínio possibilite a
especificação de soluções que sejam adequadas às necessidades
dos interessados no sistema e respeitem as restrições
estabelecidas.

Descrição do Produto
Tem como finalidade a produção de
uma detalhada especificação de
requisitos funcionais e não
funcionais, a partir dos quais o sistema
pode ser projetado e implementado e
contra a qual o sistema pode ser
testado (Olsem, 1994).

Validação de Requisitos
• Incorpora as atividades destinadas a validar o
conjunto de requisitos que tem sido definido e
descobrir possíveis problemas com estes requisitos.
Estas atividades devem envolver interessados no
sistema, engenheiros de requisitos e projetistas do
sistema. (Sommerville e Sawyer, 1997)
• A validação de requisitos não deve ser vista como
um procedimento independente a ser realizado após
a conclusão da análise do problema e da descrição
do produto. Revisões regulares são essenciais e
devem ser realizadas sempre que resultados
considerados acabados forem obtidos. (Sommerville,
1995)

Descrição de requisitos
• O sistema deve informar local de exposição de
publicações
• O sistema deve manter (inclusão, exclusão e
alteração) publicações
• O sistema deve manter (inclusão, exclusão e
alteração) tipos de publicação
• O sistema deve implementar a função informar local
de exposição de publicação com leitor de código de
barras
• O sistema deve exigir senha de acesso para a
função de manter tipos de publicação

Restrições de projeto
• O sistema deve ser implementado para
funcionar em micro padrão PC.
• O sistema não deve ser implementado com
SGBD que precise de licença para uso, pois
seu custo tornaria proibitivo o sistema.
• O sistema deve ser de fácil manipulação,
pois será operado por pessoas de baixo grau
de instrução.

Especificação de Requisitos de
Software - ERS
• Declaração detalhada e precisa dos requisitos do
sistema que é fixada para funcionar como um
contrato entre cliente e desenvolvedores de software.
• O padrão IEEE Std 830-1993
Normatização estabelecida pelo Instituto de
Engenharia Elétrica e Eletrônica (IEEE) estabeleceu
por meio do padrão 830-1993 - IEEE Recommended
Practice for Software Requirements Specifications
(IEEE, 1994) - para a elaboração de uma boa
Especificação de Requisitos de Software.

Técnicas de Elicitação de Requisitos
  Entrevistas individuais; (camila)
  Reuniões Estruturadas (Ex. jad - joint application development);
– (Armando)
  Observação direta;(francisco)
  Questionários; (camila)
  Simulação; (francisco)
  Amostragem estatística; (francisco)
  Brainstorming; (camila)
  Pesquisa bibliográfica; (camila)
  Análise de tarefas; (francisco)
  Consultas - a formulários, relatórios, manuais, registros históricos etc;
– (Armando)
  Prototipação; (Armando)
  Avaliação de outros sistemas computadorizados. (Armando)
As técnicas relacionadas não são exclusivas de métodos particulares, são
recursos de elicitação que podem ser aplicados a qualquer momento
durante a análise do problema para fornecer subsídios ao engenheiro de
requisitos.

Atores
Usuários que devem ser consultados para se especificar os requisitos de
um sistema de informação computadorizado.
Atores
“um sistema (um ser humano é também considerado um sistema) atuando no negócio”.
(Eriksson e Penker, 1998)
Atores podem ser:
• Usuários: entidades que usufruem das informações produzidas por um S.I.
• Fontes de dados: entidades passivas, do ponto de vista do sistema, que são postas em ação
para fornecer dados relevantes para a produção de informações.
• Processadores: entidades que realizam os processos organizacionais, incluindo-se os
processos de sistemas de informação - custodiais ou fundamentais.
• Condutores de interação: responsáveis pela interação com o sistema computadorizado.
A classificação de atores em um dos grupos acima não é exclusiva.
Devem ser considerados como atores até mesmo aqueles que, embora não interagindo
explicitamente com o sistema de informação, podem ser influenciados pelas informações por
ele produzidas para tomar atitudes que contribuam para maximizar os objetivos do sistema
organizacional que é apoiado pelo sistema de informação.

Regras de Negócio
• Diretrizes bem definidas que devem ser estabelecidas para guiar a
realização das operações organizacionais
• Diretrizes são normalmente conhecidas como regras de negócio
• São elaboradas nos níveis tático e estratégico
• Uma observação importante, e que merece a atenção de quem analisa
e modela sistemas organizacionais, é ser na prática quase impossível
que organizações distintas apresentem estruturas operacionais
idênticas, mesmo tendo missões e objetivos semelhantes e
manipulando os mesmos tipos de recursos. Fatores distintivos, como
cultura organizacional, histórico de evolução, interesses pessoais,
situações de mercado, entre outros, determinam estruturas e regras de
negócios que tornam único cada sistema organizacional e,
conseqüentemente, únicos os modelos resultantes de sua análise.

Boas Práticas em Engenharia
de Requisitos

Documentação de requisitos
• Definir uma estrutura padrão de documentos.
• Definir roteiro de como usar os documentos
• Fazer uma descrição preliminar do sistema.
• Definir termos especializados.
• Estabelecer formas auxiliares de encontrar
informações
• Criar documentos fáceis de serem alterados.

Eliciação de requisitos
• Estimar a viabilidade do sistema.
• Considerar aspectos organizacionais e políticos.
• Identificar e consultar os interessados no sistema.
• Registrar as fontes dos requisitos.
• Definir o ambiente operacional do sistema.
• Usar interesses do negócio para conduzir a eliciação dos
requisitos.
• Identificar restrições de domínio.
• Registrar razões fundamentais dos requisitos.
• Coletar requisitos de múltiplos pontos de vista.
• Prototipar requisitos pouco compreendidos.
• Usar cenários para eliciar requisitos.
• Definir processos operacionais.
• Reutilizar requisitos.

Análise e negociação de requisitos
• Definir fronteiras do sistema de software.
• Usar listas de verificação para análise dos
requisitos.
• Prover software para suportar negociações.
• Planejar para conflitos e resolução de conflitos.
• Priorizar requisitos.
• Usar matrizes de interação para encontrar conflitos
e sobreposições.
• Avaliar requisitos de risco.

Descrição de requisitos
• Definir modelos padrões para descrição de
Requisitos.
• Usar linguagem simples, concisa e consistente.
• Usar diagramas apropriadamente.
• Suplementar linguagem natural com outras
descrições de requisitos.
• Especificar requisitos quantitativamente.

Modelagem de sistemas
• Desenvolver modelos de sistema complementares.
• Modelar o ambiente do sistema.
• Modelar a arquitetura do sistema.
• Usar métodos estruturados para modelagem de
sistemas.
• Usar um dicionário de dados.
• Documentar as ligações entre os requisitos
estabelecidos por usuários do sistema e modelos
do sistema.

Validação de Requisitos
• Preparar documentos de requisitos satisfazendo
padrões pré-definidos.
• Organizar inspeções formais de requisitos.
• Usar grupos multidisciplinares para rever
requisitos.
• Definir listas de verificação de validação.
• Escrever um esboço do manual do usuário para ser
validado.
• Propor casos de testes de requisitos

Gerenciamento de requisitos
• Identificar unicamente cada requisito.
• Definir políticas de rastreabilidade.
• Manter um manual de rastreabilidade.
• Usar um banco de dados para gerenciar requisitos.
• Definir políticas de gerenciamento de mudanças.
• Identificar requisitos globais de sistemas.
• Identificar requisitos voláteis.
• Registrar requisitos rejeitados.

EXERCÍCIO
Especifique RF para um sistema de compras
que:
• Receba Requisições de compras de
departamentos da empresa
• Solicite cotações para fornecedores
• Emita Pedido de Compras para a cotação
selecionada

Engenharia de requisitos

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Engenharia de requisitos

Semelhante a Engenharia de requisitos (20)

Engenharia de requisitos