Marcelo Costa - Engenharia de Requisitos

Soluções Concretas
para Problemas
Práticos da Engenharia
de Requisitos
Palestrante: Marcelo Nascimento Costa, MSc
Diretor de Tecnologia
mnc@kalisoftware.com
Agenda
 Introdução
 A Engenharia de Requisitos
 A Motivação para Engenharia de Requisitos
 Problemas Práticos em Engenharia de
Requisitos
 Conclusões
www.kalisoftware.com
Evolução da Engenharia
de Requisitos no Brasil
• A implantação dos modelos CMMI e MPS.BR

indicam a preocupação com a qualidade dos
serviços
• Os modelos exigem implantação de diversos
processos dentro da organização.
• Os modelos servem como arcabouço para a
implantação da Engenharia de Requisitos
• O arcabouço deve ser implantada e customizado
de acordo com os problemas da organização
Meta do Processo de Engenharia
de Requisitos
Consideramos de fundamental importância

para um processo de engenharia de
requisitos que ele seja capaz de lidar e
suportar dificuldades e problemas
relacionados a requisitos que possam
surgir durante o desenvolvimento de
software na prática.
(Costa et al, 2009)
Importância dos Requisitos
 Estudo feito pelo Standish Group em 1995

(Pfleeger, 2004)
 350companhias e 8.000 projetos de software
 Resultados:
 31% dos projetos cancelados antes de estarem completos
 Em pequenas companhias, somente 16% dos projetos foram
entregues no prazo e no orçamento inicialmente
estabelecidos
 Em grandes companhias, apenas 9% atenderam esses
critérios
5
Engenharia de Requisitos
Algumas Estatísticas
 Standish Group
descreveu 3 categorias
de projetos:
 Sucesso (16.2%)
Sucesso
 Cobre todas as Problemático
funcionalidades em tempo Fracasso
e dentro do custo previsto

 Problemático (52.7%)
 Não cobre todas as
funcionalidades exigidas,
custo aumentado e está
atrasado.
 Fracasso (31.1%)
 Cancelado durante o
desenvolvimento
Engenharia de Requisitos 6
Causas para os projetos falhos –
Standish Group
Fatores de Projetos Críticos % Resp.

1. Requisitos Incompletos 13.1%
2. Falta de Envolvimento do Usuário 12.4%
3. Falta de Recursos 10,6%
4. Expectativas Irreais 9,9%
5. Falta de Apoio Executivo 9,3%
6. Mudança de Requisitos e Especificações 8,7%
7. Falta de Planejamento 8,1%
8. Sistema não mais necessário 7,5%
Requisitos estão envolvidos na maioria das causas!

7
Custos gerados
por problemas em requisitos
 Segundo Boehm e Papaccio (Pfleeger, 2004), o

custo relativo para o conserto de um problema
de requisitos em cada fase de desenvolvimento
de sistema é:
 $1 na fase de análise de requisitos
 $5 na fase de projeto do sistema
 $10 na fase de codificação
 $20 na fase de teste de unidade
 $200 após a entrega do sistema
8
Cenário Atual de
Desenvolvimento
 Gasta-se cada vez
mais na manutenção
e teste dos sistemas
 85% dos erros são
causados por
defeitos inseridos
durante a análise de
requisitos e projeto
do sistema.
9
Cenário Atual de
Desenvolvimento
10
Tipos de Requisitos
• Requisitos funcionais - São requisitos diretamente ligados a
funcionalidade do software, descrevem as funções que o
software deve executar.
• Requisitos não funcionais - São requisitos que expressam

condições que o software deve atender ou qualidades
específicas que o software deve ter.
• Requisitos de domínio - São requisitos derivados do domínio

da aplicação e descrevem características do sistema e
qualidades que refletem o domínio. Podem ser requisitos
funcionais novos, restrições sobre requisitos existentes ou
computações específicas.
O processo de Engenharia de
Requisitos
Visão macro da
Dificuldades na
 Foram identificados diversos problemas na fase de produção
de requisitos e nas demais atividades da gerência de
requisitos
 Os problemas foram levantados com base na experiência

prática de anos de consultoria de apoio para a implantação
do processo de engenharia de requisitos em empresas de
diferentes portes e de diferentes domínios de negócios
(incluindo fábricas de software).
 Foi considerada também a experiência de avaliação de

empresas nos modelos de maturidade CMMI e MPS.
Dificuldades na Engenharia de
Requisitos – Elicitação de Requisitos
Problema Possível Solução
Envolver interessados -Identificar os interessados, identificando seus
inapropriados. papéis e interesses com o patrocinador.
-Envolver em entrevistas ou de atividades como
workshops de requisitos ou sessões JAD
Problemas políticos na - Utilização de um ciclo de vida iterativo

organização. incremental, onde nem toda a funcionalidade é
definida no início do processo.
- Através de processo de gerência de requisitos,
que envolve a análise de impacto das
modificações solicitadas.
Identificando Stakeholders
 O contato inicial normalmente indica pessoas com quem

se deve falar, seus papéis e seus interesses
 Stakeholders incluem usuários diretos do sistema e
interessados indiretos também
 Stakeholders podem sugerir outras pessoas que devem
ser consultadas …
16
Utilização de ciclos
interativos e incrementais
Waterfall Iterativo e Incremental
Tempo
Escopo
• No Iterativo e Incremental o escopo de validação é bem menor evitando a questão do
escopo ser definido em uma única etapa.
Dificuldades na Engenharia de Requisitos –
Análise e Negociação de Requisitos
Problema Discussão da Solução

A linguagem natural e a -Necessário aumentar a interação entre o
abstração os requisitos de engenheiro de requisitos e o usuário.
alto nível dificultam o -Iniciar as entrevistas com o cliente com
mapeamento das perguntas abertas.
capacidades macro em -possibilidade de empregar técnicas de
requisitos funcionais e não elicitação complementares como etnografia
funcionais. (observação do ambiente operacional do
cliente).
Separar premissas -Estabelecer templates e diretrizes que
relacionadas ao orientem a separação adequada do conteúdo
desenvolvimento do do documento de requisitos
sistema dos seus -Fazer uso de revisões técnicas para assegurar
requisitos. a qualidade dos documentos produzidos.
Entrevistas com perguntas
abertas
 Quais são os problemas?
 Por que eles precisam ser resolvidos?
 Existem outras razões para eles serem resolvidos?
 Quais os benefícios esperados de uma solução bem
sucedida?
 Como os problemas são resolvidos hoje? Qual é a situação
atual?
 Qual seria a situação desejada, ou seja, como você gostaria
de resolver os problemas?
 Como essa atividade é realizada?
 O que ela gera como resultado? Para quem?
 Quais são as dificuldades para a sua realização?
 O que tornaria sua realização mais fácil ou eficiente?
19
Exemplo de Templates –
Especificação de Requisitos
1. Fronteiras do Software
Permitir a gestão dos usuários do *SISTEMA XYZ* e dos direitos de acesso desses
usuários às diversas funcionalidades disponibilizadas pelo sistema, de forma que
cada usuário tenha acesso somente às funcionalidades necessárias para
cumprimento das suas atividades. Permitir que os diversos usuários do *SISTEMA
XYZ* possam realizar a manutenção de seus dados pessoais e a gestão de seus
substitutos sem a necessidade de intervenção dos administradores do *SISTEMA
XYZ*.
2. Premissas
< Conjunto de condições que devem ser assumidas como verdadeiras para a
entrega do produto>
• O fornecedor ABC deve responder às solicitações de alterações das bibliotecas em
3 dias úteis
• O fornecedor ABC deve disponibilizar uma versão da interface até 3 dias antes do
início dos testes integrados.
• O ambiente de testes integrado deve estar disponível 3 dias antes do início dos
testes integrados
3. Características não-contempladas
• O módulo de autenticação por biometria não será entregue nessa versão do software
Documentação dos Requisitos

Dificuldade na descrição de - Utilização de revisões técnicas formais.
requisitos funcionais e não- - Treinamentos podem ser conduzidos focando nos
funcionais. problemas encontrados nas inspeções.
Complexidade no -Manter os passos simplificados, contudo

detalhamento dos casos de assegurando que todas as informações necessárias
uso para definição da solução. (informações recebidas, opções disponibilizadas,
informações fornecidas e ações realizadas) estejam
descritas.
-A separação do caso de uso em diversos casos de
uso relacionados através de inclusões (includes) e
extensões (extends)
Documentação dos Requisitos

Detalhamento técnico - Utilização de revisões técnicas formais.
desnecessário durante a - Treinamento pode ser fornecido para
especificação funcional do esclarecer o conteúdo apropriado da
sistema. especificação funcional.
Disponibilidade limitada -Dividir o projeto em módulos que possam ser

para a realização de tratados em sessões JAD separadas com
sessões JAD/workshops diferentes interessados em cada uma das
de requisitos. sessões.
Definição de Workshops de
Requisitos
 Idealizado para encorajar o consenso acerca dos
requisitos da aplicação e acerca das ações a serem
tomadas em um curto intervalo de tempo
 Formato: reunião intensiva (1 ou 2 dias) com pessoas
chaves visando criar ou revisar as principais
funcionalidades do sistema em desenvolvimento, com a
participação de um mediador
23
Verificação dos Requisitos

Requisito não funcionais - Deve-se associar forma de medida/referência
não verificáveis a cada requisito não-funcional elicitado.
-As revisões técnicas formais devem assegurar
que os requisitos não funcionais estejam
descritos de forma verificável.
Medidas de Requisitos (Não-
Funcionais)
Propriedade Medida
Velocidade Transações processadas/seg
Tempo de resposta do usuário/evento
Tamanho K bytes
No de chips de RAM
Facilidade de uso Tempo de treinamento
No de quadros de ajuda
Confiabilidade Tempo médio de falhas
Probabilidade de indisponibilidade
Taxa de ocorrência de falhas
Robustez Tempo de reinício após falha
Percentual de eventos causando falhas
Probabilidade de corrupção de dados após falha
Portabilidade Percentual de declarações dependentes do destino
No de sistemas destino
25
Dificuldades na Engenharia de Requisitos-
Validação dos Requisitos

Dificuldades para validação - Evitar o uso demasiado de heranças entre
de casos de uso por parte casos de uso
do usuário. - Treinar o usuário na leitura de documentos
que envolvam descrições de casos de uso.
-Uso de protótipos para apoiar o entendimento
dos requisitos por parte do usuário.
-Utilização de walkthroughs
Documentos funcionais -Realização de mais de uma revisão de
grandes dificultam a validação do documento
validação. -Utilização de protótipos no documento de
especificação funcional
- Utilização da estratégia de implementação
iterativo e incremental
Exemplo de Protótipo
Onde criar o Protótipo?
 Algumas ferramentas apóiam a criação do

protótipo:
 GoMockingBirds (free)
 Prototype Composer (free)
 Enterprise Architect (licença)
 Visual Studio (licença)
www.kalisoftware.com 28
Requisitos
Dificuldades de estabelecer - Criar uma biblioteca de casos de uso
uma estratégia para a estruturada de acordo a divisão funcional
atualização e reutilização (módulos) dos sistemas da organização
de casos de uso. - Tratar cada caso de uso como um item de
configuração
Como representar a -Preenchimento de um histórico de versões dos

atualização de casos de casos de uso, informando a data, as alterações
uso? realizadas e o responsável pelas alterações.
- Tratar cada caso de uso como um item de
configuração e inserir no processo de gerência
de configuração.
Exemplo de Histórico
de Versões
Data Versão Descrição Autor(es)
23/11/2005 1.0 Versão inicial com os requisitos identificados nas João
entrevistas com os usuários
13/03/2006 1.1 Identificação de fronteiras, itens e questões de José/João

interface com outros sistemas
31/03/2006 1.2 Revisão dos requisitos a partir do entendimento do João
antigo SCD e quebra da especificação do MSL e
MGU em 2 documentos (inicialmente estavam em
um único documento)
25/04/2006 1.3 Ajustes nos casos de uso João

03/07/2007 1.4 Revisão dos casos de uso João
13/07/2006 1.5 Ajustes no documento conforme defeitos apontados João
pela inspeção
Exemplo de Biblioteca de
Casos de Uso
Os casos de uso do sistema devem ser distribuídos de acordo com a estrutura

funcional dos módulos do sistema.
Casos de Uso como Item
de Configuração
Cada caso de uso do sistema é um documento separado e deve ser tratado como
um item de configuração durante o processo de gerência de configuração. Isto
Significa que deve ser versionado, possuir histórico, permissão de acessos.
Requisitos – Gerência de Requisitos

Dificuldade de integração - Definir um processo de gerência de
das práticas de gerência de configuração padrão. A evolução dos requisitos
requisitos com gerência de deve estar alinhada com a evolução das
configuração. baselines de requisitos
-Os requisitos acordados em uma baseline
somente podem ser alterados através de
solicitações de mudança.
Trabalhar com o backlog - Considerar uma abordagem evolutiva para a
de casos de uso criação dos casos de uso, onde inicialmente a
inexistentes para sistemas documentação consiste de um resumo do caso
em manutenção. de uso (contendo, por exemplo, apenas o fluxo
principal).
Requisitos – Gerência de Requisitos

Dificuldades de - Estabelecer um processo de desenvolvimento
implantação e manutenção que integre as atividades relacionadas ao
da rastreabilidade dos estabelecimento da rastreabilidade com as
requisitos. próprias atividades de engenharia do software.
- Algumas ferramentas CASE permitem o
estabelecimento dos links de rastreabilidade no
momento da criação e atualização dos
artefatos.
Dificuldades de -O estabelecimento retroativo de rastreabilidade
estabelecimento retroativo pode ser extremamente custoso e uma análise
de rastreabilidade dos de custo/benefício deve ser considerada antes
requisitos. de realizar esta tarefa
Matriz de Rastreabilidade
Matriz de Rastreabilidade
Rastreabilidade apoiada por Ferramentas: Enterprise Architect
Requisitos - Ferramentas

Custo das ferramentas - O processo de engenharia de requisitos deve
para gerência de ser muito bem definido e compatível com a
requisitos. ferramenta.
-É importante ressaltar que um processo de
engenharia de requisitos pode ser estabelecido
utilizando somente ferramentas gratuitas
Requisitos – Recursos Humanos

Falta de conhecimento -Em domínios muito complexos e específicos
dos analistas de requisitos o envolvimento com os clientes deve ser
em um domínio específico intensificado
do problema. - Considerar a contratação de suporte
constante de consultores externos,
especialistas no domínio.
Conclusão
 Alguns problemas são bastantes críticos e devem ser atacados
constantemente:
 Validação de Casos Usos com semântica mais complexa
 Criação de documentos funcionais muito grandes
 Mapeamento da abstração da linguagem natural para requisitos funcionais e
não-funcionais
 Outros são praticamente problemas abertos e inerentes a engenharia de

requisitos:
 Problemas Políticos na Organização
 Criar e Manter a Matriz de Rastreabilidade
 Criar o Backlog Funcional de Casos de Uso
 Estabelecer um processo de engenharia de requisitos bem estruturado é

fundamental
 Suporte de analistas de requisitos seniores pode ajudar a capacitar a

empresa a lidar com essas questões.
Conclusão
 Algumas considerações a respeito da utilização de
ferramentas na Engenharia de Requisitos:
 A área de gerência de requisitos não possui ferramentas open
source no mesmo nível das ferramentas pagas
 O pagamento da licença da ferramenta não resolve todos os
problemas da implantação
 Os analistas e desenvolvedores devem ser treinados efetivamente
na ferramenta
 A curva de aprendizagem da ferramenta e input dos requisitos
preexistentes precisam de um esforço maior durante os primeiros
projetos
 Deve existir uma equipe de suporte para apoiar a utilização das
ferramentas
Conclusão
 Utilizar a análise causal de defeitos para melhorar o processo de
 Treinamentos e revisões formais são bastantes importantes para implantar

as soluções para cada problema enfrentado.
 Os modelos CMMI e MPS.BR fazem uma ligação forte entre gerência de

Configuração e Gerência de Requisitos. Pode-se ser notado que alguns
problemas são resolvidos através da integração dessas práticas.
 Os modelos CMMI e MPS.BR fornecem um arcabouço interessante e

bastante útil para servir como base para implantação de um processo eficaz
de engenharia de requisitos.

Marcelo Costa - Engenharia de Requisitos

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Marcelo Costa - Engenharia de Requisitos

Transféré par

Droits d'auteur :

Formats disponibles

Soluções Concretas

• A implantação dos modelos CMMI e MPS.BR

Consideramos de fundamental importância

 Estudo feito pelo Standish Group em 1995

e dentro do custo previsto

Fatores de Projetos Críticos % Resp.

Requisitos estão envolvidos na maioria das causas!

 Segundo Boehm e Papaccio (Pfleeger, 2004), o

• Requisitos não funcionais - São requisitos que expressam

• Requisitos de domínio - São requisitos derivados do domínio

 Os problemas foram levantados com base na experiência

 Foi considerada também a experiência de avaliação de

Problemas políticos na - Utilização de um ciclo de vida iterativo

 O contato inicial normalmente indica pessoas com quem

Problema Discussão da Solução

Problema Discussão da Solução

Complexidade no -Manter os passos simplificados, contudo

Problema Discussão da Solução

Disponibilidade limitada -Dividir o projeto em módulos que possam ser

Problema Discussão da Solução

Problema Discussão da Solução

 Algumas ferramentas apóiam a criação do

Como representar a -Preenchimento de um histórico de versões dos

13/03/2006 1.1 Identificação de fronteiras, itens e questões de José/João

25/04/2006 1.3 Ajustes nos casos de uso João

Os casos de uso do sistema devem ser distribuídos de acordo com a estrutura

Problema Discussão da Solução

Problema Discussão da Solução

Problema Discussão da Solução

Problema Discussão da Solução

 Outros são praticamente problemas abertos e inerentes a engenharia de

 Estabelecer um processo de engenharia de requisitos bem estruturado é

 Suporte de analistas de requisitos seniores pode ajudar a capacitar a

 Treinamentos e revisões formais são bastantes importantes para implantar

 Os modelos CMMI e MPS.BR fazem uma ligação forte entre gerência de

 Os modelos CMMI e MPS.BR fornecem um arcabouço interessante e

Vous aimerez peut-être aussi