Universidade Federal de Santa Maria Mestrado em Computação
ELC 923 – Processos de Negócio e Engenharia de Requisitos
Profa. Rosana Wagner
Adaptado do material de Lisandra M. Fontoura
ENGENHARIA DE REQUISITOS
Especialização em Modelagem e
Roteiro
Introdução Requisitos de Software Funcionais Não funcionais De usuário De sistema Especificação de interface Documentação de requisitos Processos de Engenharia de Requisitos
Estudos de viabilidade
Elicitação e análise de requisitos Validação de requisitos
Gerenciamento de requisitos
Introdução
Roberto quer modernizar sua empresa. Ele tem uma agência de turismo.
Ele não tem uma equipe de desenvolvedores, então ele decide contratar uma empresa para fazer o sistema
para ele. Ele diz:
Eu preciso de um website onde os clientes possam ver nossas ofertas e onde eles possam reservar e pagar online.Também quero oferecer um serviço de luxo que inclua viagem de e para o hotel/aeroporto e acomodação.
Introdução
Sua tarefa é analisar o que Roberto disse e construir os requisitos iniciais.
A grosso modo...
Introdução
Requisito #1
Título: mostrar ofertas
Descrição: O site deve mostrar ofertas aos clientes da agência.
Requisito #2
Título: reservar oferta
Descrição: O site deve permitir que os clientes possam reservar ofertas.
Requisito #3
Título: reservar pacotes especiais
Descrição: O site deve
permitir que os clientes consigam reservar
pacotes e adicionar serviços extras.
Requisito #4
Título: reservar transporte Descrição: O site deve
permitir ao cliente
reservar transporte do hotel ao aeroporto e vice-versa.
Requisito #5
Título: reservar hotel Descrição: ...
Introdução
Mas o que são requisitos afinal?
Requisitos de um sistema são descrições dos serviços fornecidos e as suas restrições operacionais
(SOMMERVILLE).
Engenharia de Requisitos
Ajuda os engenheiros de SW melhor entender o problema
que eles vão trabalhar para resolver.
Quem faz?
• Engenheiros de SW e demais stakholders (clientes, gerentes,
usuários finais)
Por que é importante?
• Não adianta fazer um SW que não atenda as necessidades!!
Qual é o produto do trabalho?
Importância da Engenharia de Requisitos
Classificação de Requisitos
Quanto ao nível de detalhamento
Requisitos de sistema
Funcionais
Não Funcionais De Domínio
Requisitos de usuário
Requisitos Funcionais
São as declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas
específicas e como o sistema deve se comportar em
determinadas situações. Também podem estabelecer o que o sistema não deve fazer.
Requisitos Funcionais - Exemplos
"O software deve possibilitar o cálculo dos gastos diários, semanais, mensais e anuais com pessoal";
"O software deve emitir relatórios de compras a cada quinze dias";
"Os usuários devem poder obter o número de
aprovações, reprovações e trancamentos em todas as disciplinas por um determinado período de tempo.
Requisitos não funcionais
São aqueles não diretamente relacionados às funções específicas fornecidas pelo sistema.
Geralmente vinculados às propriedades emergentes do sistema (confiabilidade, tempo de resposta e espaço de armazenamento).
Esses requisitos especificam ou restringem as propriedades emergentes do sistema.
Requisitos não funcionais - Exemplos
"A base de dados deve ser protegida para acesso apenas de usuários autorizados".
"O tempo de resposta do sistema não deve ultrapassar 30 segundo".
"O software deve ser operacionalizado no sistema Linux".
"O tempo de desenvolvimento não deve ultrapassar seis meses".
Tipos de requisitos não funcionais
Requisitos de produto
Especificam o comportamento do produto. Ex: requisitos de
desempenho quanto à rapidez com que o sistema deve operar e quanto de memória ele requer, tolerância à falhas, portabilidade e usabilidade.
Requisitos organizacionais
Derivados de políticas e procedimentos da organização do cliente e do
desenvolvedor. Ex: padrões de processo a serem usados, linguagem de programação, método de projeto, documentação.
Requisitos externos
Derivados de fatores externos ao sistema e ao seu processo de
desenvolvimento. Ex: requisitos de interoperabilidade (como o sistema interage com outros sistemas de outras organizações), requisitos legais e éticos.
Requisitos não funcionais
Detalhes importantes
Podem ser mais importantes que os funcionais;
São difíceis de verificar (clientes raramente os vêem como metas gerais);
Requisitos ambíguos serão interpretados pelos
programadores de modo a simplificar a implementação; Alguns requisitos são difíceis de traduzir em metas (Ex:
manutenibilidade);
Requisitos não funcionais podem entrar em conflito com requisitos funcionais (sistema em tempo real e tamanho);
Requisitos de usuário
Descrevem requisitos funcionais e não funcionais, de modo
que os usuários que não possuem conhecimento técnico possam entender;
Devem especificar o comportamento do sistema e evitar,
sempre que possível, características de projeto do sitema;
Cuidar jargões de software, notações formais...
Utilizar linguagem simples, tabelas, formulários e diagramas
intuitivos;
Problemas comuns: falta de clareza, confusão de requisitos,
Requisitos de usuário – Exemplo
O sistema deve fornecer um módulo de contabilidade financeira que mantenha registros de todos os
pagamentos realizados pelos usuários do sistema.
Os gerentes podem configurar esse módulo de forma que os usuários frequentes possam receber descontos.
Requisitos de Sistema
São versões expandidas dos requisitos de usuário
usados pelos engenheiros de software como ponto de partida para o projeto de sistema.
Eles adicionam detalhes e explicam como os requisitos de usuário devem ser fornecidos pelo sistema.
Não deveriam estar relacionados como o sistema pode ser implementado (mas na prática é muito difícil excluir essas informações, dado o nível de detalhamento
Especificação de requisitos do sistema –
Formulário Padrão
Descrição da função/entidade
Descrição das entradas e de onde elas são provenientes Descrição das saídas e para onde elas irão
Indicações de quais outras entidades são usadas Descrição da ação a ser tomada
Pré-condição e pós-condição (para abordagens funcionais)
Ex: Software de controle – bomba de insulina
Função: Calcular a dose de insulina, nível seguro de açúcar Descrição: Calcula a dose de insulina a ser liberada quando
o nível medido de açúcar atual está na zona segura entre 3 e 7 unidades.
Entradas: Leitura atual do açúcar (r2), as duas leituras
anteriores (r0, r1)
Saídas: CompDose – a dose de insulina a ser liberada Destino: Loop de controle principal
Ação: CompDose será zero se o nível de açúcar estiver
estável ou em queda, ou se o nível de açúcar estiver
aumentando mas a taxa de aumento estiver diminuindo. Se o nível de açúcar ...
Ex: Software de controle – bomba de insulina
Requer: Duas leituras anteriores de modo que a taxa de mudança do nível de açúcar possa ser calculada
Pré-condição: O reservatório de insulina deve conter, pelo menos, o máximo de dose única permitida de insulina (o que acontece se não for satisfeita?)
Pós-condição: r0 é substituído por r1 e r1 é substituído por r2
Especificação de interface
Quase todos os sistemas de software devem operar com
sistemas existentes já implementados e instalados em um ambiente;
Essas interfaces devem ser especificadas com precisão; Devem ser definidas no início do processo;
Devem ser incluídas no documento de requisitos; Tipos de interface
De procedimentos: APIs
Estruturas de dados que são passadas de um subsistema para
outro;
Documento de requisitos de software
Também conhecido como SRS (Software Requirements Specification);
Declaração oficial do que os desenvolvedores devem implementar;
Possui os requisitos de usuário e de sistemas; Possui um conjunto diversificado de usuários
Padrão IEEE – Documentos de requisitos
Introdução Propósito do documento Escopo do produto Definições, acrônimos e abreviaturas Referências Visão geral do restante do
documento
Descrição Geral
Perspectiva do produto Funções do produto
Características dos usuários Restrições gerais
Suposições e dependências
Requisitos Específicos
Abrangem requisitos
funcionais, não funcionais e de interface.
Não há uma estrutura padrão para essa parte.
Apêndices Índice
Características dos Requisitos
Para assegurar que os requisitos estão entendidos de
maneira apropriada, é importante verificar se eles têm as seguintes características:
Os requisitos estão corretos? (foram definidos sem erros)
Os requisitos são consistentes? (não-ambíguos e não-conflitantes)
Os requisitos estão completos? (conjunto completo de requisitos)
Os requisitos são realistas? (é possível fazer o que o cliente
pede)
Cada requisito descreve algo que é necessário para o cliente?
Os requisitos podem ser verificados?
Processos de engenharia de requisitos
Etapas [PRESSMAN] Concepção, Levantamento, Elaboração Negociação Especificação Validação, Gestão. Etapas [SOMMERVILLE] Estudo de viabilidade; Obtenção de requisitos (elicitação e análise); Especificação de requisitos; Validação de requisitos; Gerenciamento de Requisitos.Estudo de viabilidade
Um estudo de viabilidade decide se vale a pena ou não gastar
tempo e esforço com sistema proposto.
É um estudo breve e focalizado que verifica
Se o sistema contribui para os objetivos da organização;
Se o sistema pode ser implementado usando tecnologia atual e dentro
do orçamento;
Se o sistema pode ser integrado a outros.
Muitas vezes as empresas desenvolvem sistemas que não
contribuem para os seus objetivos pois elas não têm um perfil claro desses objetivos.
O que faria se o sistema não fosse implementado? Quais são os
Elicitação e análise de requisitos
Envolve pessoal técnico trabalhando com os clientes para
descobrir sobre o domínio de aplicação, os serviços que o sistema deve fornecer e sobre as restrições operacionais.
Por que esse processo é tão difícil?
Stakeholders não sabem o que eles realmente querem.
Stakeholders expressam requisitos em seus próprios termos.
Diferentes stakeholders podem ter requisitos conflitantes.
Fatores organizacionais e políticos podem influenciar os requisitos
de sistema.
A mudança de requisitos durante o processo de análise. Novos
Processo de elicitação e análise
Processo iterativo e contínuo!
Processo de elicitação e análise - Etapas
Obtenção de requisitos
Interação com os stakeholders para coletar seus requisitos.
Classificação e organização de requisitos
Agrupa requisitos relacionados e organiza-os em conjuntos
coerentes.
Priorização e negociação de requisitos
Priorização de requisitos e resolução de conflitos de requisitos.
Documentação de requisitos
Os requisitos são documentados e colocados na próxima volta da
Especificação de Requisitos
Pode ser um documento escrito, modelo, diagrama, cenários de uso, prototipação, entre outros;
Ou uma combinação de um conjunto desses elementos. Especificação é o produto final produzido pelos
Validação de Requisitos
Dedica-se a mostrar que os requisitos definem o sistema que o cliente realmente deseja.
Custos de erros de requisitos são altos e, desse modo, a validação é muito importante:
A custo da reparação de um erro de requisitos depois da entrega pode equivaler a 100 vezes o custo de reparação de um erro de implementação.
Verificação de Requisitos
Verificação de validade: O sistema fornece as funções que
melhor apóiam as necessidades do cliente?
Verificação de consistência: Existe algum tipo de conflito de
requisitos?
Verificação de completeza: Todas as funções requisitadas
pelo cliente foram incluídas?
Verificação de realismo: Os requisitos podem ser
implementados com o orçamento e a tecnologia disponíveis?
Facilidade de verificação: Os requisitos podem ser
Validação de Requisitos - Revisões de Requisitos
Processo manual que envolve os stakeholders (verificação do
documento em busca de anomalias e omissões);
Revisores podem verificar:
Facilidade de verificação (requisito é testável de forma realista?)
Facilidade de compreensão (stakeholders compreendem de
forma adequada?)
Rastreabilidade (origem do requisito está claramente
estabelecida?)
Adaptabilidade (requisito pode ser mudado sem grandes
efeitos?)
Conflitos, contradições e omissões devem ser registrados
Gerenciamento de Requisitos
O que é? Processo de gerenciamento de mudanças de requisitos durante o processo de engenharia de
requisitos e o desenvolvimento de sistema. Evolução de requisitos
Gerenciamento de Requisitos
Processo pra compreender e controlar a mudança dos
requisitos de sistema;
Necessário manter acompanhamento dos requisitos
individuais e manter as ligações entre os requisitos
dependentes, de modo que seja possível avaliar o impacto das mudanças de requisitos;
Requisitos permanentes: relativamente estáveis, se
relacionam diretamente com o domínio de aplicação do sistema;
Requisitos voláteis: provavelmente irão mudar durante o
Gerenciamento de Requisitos
Gerenciamento de Requisitos
Planejamento
Durante o processo de engenharia de requisitos, você tem
de planejar:
A Identificação de requisitos
Como os requisitos são identificados individualmente;
O processo de gerenciamento de mudanças
É o processo seguido quando da análise de uma mudança de requisitos;
Políticas de rastreabilidade
É a quantidade de informações que é mantida sobre os relacionamentos
de requisitos;
Apoio de ferramenta CASE
O apoio de ferramenta requisitada para auxiliar no gerenciamento das
Gerenciamento de Requisitos
Planejamento: Rastreabilidade
A rastreabilidade está relacionada aos relacionamentos entre os requisitos, suas fontes e o projeto de sistema.
Tipos de informações de rastreabilidade:
Rastreabilidade da fonte:
Ligam os requisitos aos stakeholders que propuseram os requisitos;
Rastreabilidade de requisitos:
É a ligação dos requisitos dependentes;
Rastreabilidade de projeto
Gerenciamento de Requisitos
Gerenciamento de Mudanças
Deve ser aplicado à todas as mudanças propostas aos requisitos. Estágios principais:
Análise de problema: discutir problemas e mudanças de requisitos;
Análise de mudança e estimativa de custo: avaliar os efeitos das mudanças sobre outros requisitos;
Implementação de mudança: Modificar documentos de requisitos e outros documentos para refletir as mudanças.
Tópicos considerados
Introdução: O que é requisitos, eng. de requisitos, para que serve,
quem faz?
Requisitos de Software
Funcionais, Não funcionais, De usuário, De sistema; Especificação de interface
Documentação de requisitos
Processos de Engenharia de Requisitos
Estudos de viabilidade (O que é, para que serve)
Elicitação e análise de requisitos: Obtenção (stakeholders, pontos de
vista, entrevista, cenários, casos de usos), Etnografia
Validação de requisitos (verificação e revisões de requisitos)
Gerenciamento de requisitos (o que é, planejamento, rastreabilidade e
Bibliografia
SOMMERVILLE, I. Engenharia de Software, 8 edição. São
Paulo: Pearson Addison-Wesley, 2007.
PRESSMAN, R. Engenharia de Software, 6 edição. São
Paulo: McGraw-Hill, 2006.
MILES, R. e PILONE, D. Head First Sofware Development.
O'Reilly.
Requirements Definition: Bringing Software Requirements to
Life:http://www.youtube.com/watch?v=fHjc3cJ6m00 The Problem with Software Definition:
http://www.youtube.com/watch?v=FqkQrPmsP2w&feature= related
