Marcelo Costa - Engenharia de Requisitos

Soluções Concretas

para Problemas

Práticos da Engenharia

de Requisitos

Palestrante: Marcelo Nascimento Costa, MSc

Diretor de Tecnologia

[email protected]

www.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


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)

www.kalisoftware.comEngenharia de Requisitos 5

Importância dos Requisitos

Estudo feito pelo Standish Group em 1995 (Pfleeger, 2004) 350 companhias 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


Algumas Estatísticas

Standish Group descreveu 3 categorias de projetos: Sucesso (16.2%)

Cobre todas as funcionalidades em tempo 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

Sucesso

Problemático

Fracasso


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!


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


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.


Cenário Atual de

Desenvolvimento


• 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.

Tipos de Requisitos


O processo de Engenharia de

Requisitos


Visão macro da

Engenharia de Requisitos


Dificuldades na

Engenharia de Requisitos 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

inapropriados.

-Identificar os interessados, identificando seus

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

organização.

- Utilização de um ciclo de vida iterativo

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 …


Utilização de ciclos

interativos e incrementaisWaterfall Iterativo e Incremental

Tempo

Escopo

• No Iterativo e Incremental o escopo de validação é bem menor evitando a questão doescopo 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

abstração os requisitos de

alto nível dificultam o

mapeamento das

capacidades macro em

requisitos funcionais e não

funcionais.

-Necessário aumentar a interação entre o

engenheiro de requisitos e o usuário.

-Iniciar as entrevistas com o cliente com

perguntas abertas.

-possibilidade de empregar técnicas de

elicitação complementares como etnografia

(observação do ambiente operacional do

cliente).

Separar premissas

relacionadas ao

desenvolvimento do

sistema dos seus

requisitos.

-Estabelecer templates e diretrizes que

orientem a separação adequada do conteúdo

do documento de requisitos

-Fazer uso de revisões técnicas para assegurar

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?


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

requisitos funcionais e não-

funcionais.

- Utilização de revisões técnicas formais.

- Treinamentos podem ser conduzidos focando nos

problemas encontrados nas inspeções.

Complexidade no

detalhamento dos casos de

uso para definição da solução.

-Manter os passos simplificados, contudo

assegurando que todas as informações necessárias

(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

desnecessário durante a

especificação funcional do

sistema.

- Utilização de revisões técnicas formais.

- Treinamento pode ser fornecido para

esclarecer o conteúdo apropriado da

especificação funcional.

Disponibilidade limitada

para a realização de

sessões JAD/workshops

de requisitos.

-Dividir o projeto em módulos que possam ser

tratados em sessões JAD separadas com

diferentes interessados em cada uma das

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



Verificação dos Requisitos


Requisito não funcionais

não verificáveis

- Deve-se associar forma de medida/referência

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 MedidaVelocidade Transações processadas/seg

Tempo de resposta do usuário/eventoTamanho K bytes

No de chips de RAMFacilidade de uso Tempo de treinamento

No de quadros de ajudaConfiabilidade Tempo médio de falhas

Probabilidade de indisponibilidadeTaxa de ocorrência de falhas

Robustez Tempo de reinício após falhaPercentual de eventos causando falhasProbabilidade de corrupção de dados após falha

Portabilidade Percentual de declarações dependentes do destinoNo de sistemas destino


Dificuldades na Engenharia de Requisitos-

Validação dos Requisitos


Dificuldades para validação

de casos de uso por parte

do usuário.

- Evitar o uso demasiado de heranças entre

casos de uso

- 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

grandes dificultam a

validação.

-Realização de mais de uma revisão de

validação do documento

-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)

28



RequisitosProblema Discussão da Solução

Dificuldades de estabelecer

uma estratégia para a

atualização e reutilização

de casos de uso.

- Criar uma biblioteca de casos de uso

estruturada de acordo a divisão funcional

(módulos) dos sistemas da organização

- Tratar cada caso de uso como um item de

configuração

Como representar a

atualização de casos de

uso?

-Preenchimento de um histórico de versões dos

casos de uso, informando a data, as alterações

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

entrevistas com os usuários

João

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

interface com outros sistemas

José/João

31/03/2006 1.2 Revisão dos requisitos a partir do entendimento do

antigo SCD e quebra da especificação do MSL e

MGU em 2 documentos (inicialmente estavam em

um único documento)

João

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

pela inspeção

Joã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 comoum 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

das práticas de gerência de

requisitos com gerência de

configuração.

- Definir um processo de gerência de

configuração padrão. A evolução dos requisitos

deve estar alinhada com a evolução das

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

de casos de uso

inexistentes para sistemas

em manutenção.

- Considerar uma abordagem evolutiva para a

criação dos casos de uso, onde inicialmente a

documentação consiste de um resumo do caso

de uso (contendo, por exemplo, apenas o fluxo

principal).



Requisitos – Gerência de Requisitos


Dificuldades de

implantação e manutenção

da rastreabilidade dos

requisitos.

- Estabelecer um processo de desenvolvimento

que integre as atividades relacionadas ao

estabelecimento da rastreabilidade com as

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

estabelecimento retroativo

de rastreabilidade dos

requisitos.

-O estabelecimento retroativo de rastreabilidade

pode ser extremamente custoso e uma análise

de custo/benefício deve ser considerada antes

de realizar esta tarefa


Matriz de Rastreabilidade

35


Matriz de Rastreabilidade

Rastreabilidade apoiada por Ferramentas: Enterprise Architect

36



Requisitos - Ferramentas


Custo das ferramentas

para gerência de

requisitos.

- O processo de engenharia de requisitos deve

ser muito bem definido e compatível com a

ferramenta.

-É importante ressaltar que um processo de

engenharia de requisitos pode ser estabelecido

utilizando somente ferramentas gratuitas



Requisitos – Recursos Humanos


Falta de conhecimento

dos analistas de requisitos

em um domínio específico

do problema.

-Em domínios muito complexos e específicos

o envolvimento com os clientes deve ser

intensificado

- 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

40


Conclusão

Utilizar a análise causal de defeitos para melhorar o processo de Engenharia de Requisitos

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

Documents

Transcript of Marcelo Costa - Engenharia de Requisitos