Qualidade no levantamento de requisitos
Trecho do Pequeno Príncipe: Antoine Saint-Exupéry, 1996.
“E ele repetiu-me então, brandamente, como uma coisa muito séria: - Por favor ... desenha-me um carneiro ...
Quando o mistério é muito impressionante, a gente não ousa desobedecer. Por mais absurdo que aquilo me parecesse a mil milhas de todos os lugares habitados e em perigo de morte, tirei do bolso uma folha de papel e uma caneta. Mas lembrei-me, então, que eu havia estudado de preferência geografia, história, cálculo e gramática, e disse ao garoto (com um pouco de mau humor) que eu não sabia desenhar. Respondeu-me:
-Não tem importância. Desenha-me um carneiro.
Como jamais houvesse desenhado um carneiro, refiz para ele um dos dois únicos desenhos que sabia. O da jibóia fechada. E fiquei estupefato de ouvir o garoto replicar:
Qualidade no levantamento de requisitos
- Não! Não! Eu não quero um elefante numa jibóia. A jibóia é perigosa e o elefante toma muito espaço. Tudo é pequeno onde eu moro. Preciso é dum carneiro. Desenha-me um carneiro.Então eu desenhei. Olhou atentamente, e disse:
- Não! Esse já está muito doente. Desenha outro. Desenhei de novo.
-Bem vês que isto não é um carneiro. É um bode... Olha os chifres... -Fiz mais uma vez o desenho.
Mas ele foi recusado como os precedentes: - Este aí é muito velho. Quero um carneiro que viva muito. -Então, perdendo a paciência, como tinha pressa de desmontar o motor, rabisquei o desenho ao lado.
E arrisquei:
-Esta é a caixa. O carneiro está dentro.
Mas fiquei surpreso de ver iluminar-se a face do meu pequeno juiz: -- Era assim mesmo que eu queria! Será preciso muito capim para esse carneiro?”
Requisitos
Consistem em uma série de sentenças
que descrevem de maneira clara,
concisa, consistente e não ambígua
todos os aspectos significativos do
sistema a ser desenvolvido
Por que qualidade no Gerenciamento de requisitos?
Alto custo dos erros dos requisitos
Fonte :
G.T.E. Developments é uma companhia de software fundada em 1989, a qual se especializou no desenvolvimento de aplicações de software específicas para pinturas industriais.
IBM desenvolve e manufatura diversas tecnologias da informação, dentre as quais sistemas operacionais, softwares, sistemas de armazenamento de dados e microeletrônicos.
DAVIS, Alan M. Software requirements – objects, functions and states. Englewood Cliffs : Prentice Hall, 1993.
Qualidade no levantamento de requisitos
Fontes de erros em um projeto da US Air Force
Qualidade no levantamento de requisitos
Principais problemas
Problemas de escopo – limite é mal definido
Problemas de entendimento – Usuários não
estâo completamente certos do domínio do
problema ou mesmo tem pouca compreensão
das capacidades e limitações do ambiente
computacional
Problemas de volatilidade – requisitos
mudam ao longo do tempo
Qualidade no levantamento de requisitos
O modelo de avaliação de maturidade do
processo
de
desenvolvimento
CMM-SW
(Capability Maturity Model-SW) considera o
gerenciamento de requisitos como sendo uma
das primeiras etapas para alcançar a
maturidade organizacional, e para haver o
gerenciamento é preciso que o processo de
desenvolvimento de requisitos esteja implantado
na empresa.
Qualidade no levantamento de requisitos
Os requisitos não ficam somente com a
equipe de desenvolvimento: eles se
propagam por toda a área de Tecnologia
da Informação (TI).
homologação
métrica
produção
telecomunicações
outras
requisitos
Qualidade no levantamento de requisitos
Classificação
dos
requisitos
Requisitos
funcionais
Requisitos não
funcionais
Qualidade no levantamento de requisitos
Requistos
funcionais
Descrevem as diversas funções que
os clientes e usuários querem ou
precisam que o software execute.
Compreendem requisitos funcionais:
- funções;- interação com usuário e outros sistemas; - dados, relatórios/consultas; e - inversos: o que não deve fazer.
Ex. "o sistema deve possibilitar o cálculo dos gastos diários, semanais, mensais e anuais com pessoal".
"o sistema deve emitir relatórios de compras a cada quinze dias".
Qualidade no levantamento de
requisitos
Requistos
não
funcionais
São as qualidades globais de um
software
Compreendem requisitos não
funcionais:
-
características de
funcionalidade, usabilidade, confiabilidade, desempenho e suportabilidade−
"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 segundos";
-
"o software deve ser operacionalizado no
sistema Linux";
-
"o tempo de desenvolvimento não deve
ultrapassar seis meses".
São exemplos de requisitos não-funcionais:
- Uma sub área da Engenharia de
Software
- Engenharia de requisitos é um
conjunto estruturado de atividades
para extrair, validar e manter um
conjunto de documentos de requisitos.
Engenharia de Requisitos
Macro atividades:
1.
Elicitação;
2.
Definição;
3.
Análise;
4.
Especificação;
5.
Gerência dos Requisitos
6. Gerência de mudanças
Engenharia de Requisitos
Elicitação dos requisitos
Principais atividades da Engenharia de Requisitos
-
Nesta fase o engenheiro de requisitos
procura captar os requisitos do software,
buscando obter conhecimento do
domínio do problema.
-Para alcançar tal objetivo, esta fase utiliza
tr
ê
s atividades
principais:
identifica
çã
o
das fontes de informa
çã
o
,
coleta de fatos
e
comunica
çã
o
, além de ferramentas,
pessoal e métodos.
Elicitação
dos
requisitos
Obter informação sobre domínio do problema e
sistema atual
(Antes de manter as reuniões com os clientes e usuários e identificar os requisitos, é fundamental conhecer o domínio do problema e os contextos organizacional e operacional (situação atual). A equipe responsável pelo levantamento deve se familiarizar com o vocabulário próprio do domínio a ser considerado.
Preparar e realizar reuniões de levantamento
/negociações
(Utilizar técnicas específicas para o levantamento de requisitos e técnicas de negociação).
Identificar e revisar os objetivos do sistema
(
Identificar e revisar quais informações relevantes para o cliente que o sistema deverá gerir e armazenar.)
Identificar e revisar os requisitos funcionais
Identificar e revisar os requisitos não
funcionais
Onde falhamos?
Falhamos quando
realizamos uma
pobre elicitação dos
requisitos
Poucos
desenvolvedores
fazem uso de técnicas
no momento de elicitar
os requisitos de um
sistema
Falhamos
por
não
termos método e não
utilizarmos
técnicas
para
elicitar
os
requisitos.
Definição dos requisitos
-É uma descrição abstrata dos serviços que o sistema
deve oferecer e das restrições sob as quais ele deve
operar (requisitos funcionais e não funcionais)
-Tem por função modelar o sistema a ser desenvolvido
e apresentar esse modelo ao cliente e usuários.
Portanto, esse documento deve ser escrito utilizando-se
modelos bastante inteligíveis como a linguagem natural
e diagramas de fácil compreensão
Principais atividades da Engenharia de Requisitos
Onde falhamos?
Falhamos quando
realizamos uma
pobre definição dos
requisitos
Uma pobre definição dos
requisitos, que devem ser
escritos em linguagem
natural para serem lidos e
entendidos por clientes,
gerentes, usuários finais do
sistema, gerentes
contratantes e arquitetos
de sistemas, acarreta em
uma má definição do
sistema
Falhamos por não termos
uma
clara
visão
do
problema
que
estamos
tentando resolver.
Análise dos requisitos
-O projetista (engenheiro de requisitos) especifica as
funções e desempenho do software, indica a interface
do software com outros sistemas e estabelece as
restrições de projeto do software.
- O objetivo é avaliar e revisar o escopo do software. Por
meio de um processo de descoberta, refinamento,
modelagem e especificação, o objetivo é obter uma
especificação de requisitos completa e consistente.
Principais atividades da Engenharia de Requisitos
Onde falhamos?
Falhamos quando
realizamos uma
pobre análise dos
requisitos
Somente a partir de um
minucioso levantamento de
pessoas
e
atividades
poderemos identificar os
elementos do domínio –
informações e processos que
serão automatizados pelo
sistema computacional.
Falhamos
por
não
aprofundarmos a descoberta
do domínio da aplicação e
desconsiderarmos
informações importantes para
o sucesso da aplicação.
Especificação dos requisitos
-Traz informações adicionais à definição de requisitos,
podendo ser desenvolvida em uma linguagem mais
estruturada e acompanhada de modelos do sistema.
- Linguagem natural estruturada,
linguagem de
descrição de projetos, linguagens de especificação de
requisitos, notações gráficas, especificação
matemática.
Principais atividades da Engenharia de Requisitos
Onde falhamos?
Falhamos quando
realizamos uma
pobre especificação
dos requisitos
Quando deixamos de produzir a
especificação dos requisitos, que é a descrição sistemática e abstrata do quê o software deve fazer a partir daquilo que foi analisado e quais os critérios de validação serão utilizados para avaliar se o sistema cumpre o que foi definido, privamo-nos de um valioso instrumento de comunicação sistemática entre analistas e projetistas do software.
Falhamos por não aprofundarmos a descoberta do domínio da aplicação e desconsiderarmos informações importantes para o sucesso da aplicação.
Gerência de requisitos
-Estabelece um entendimento comum entre o cliente e os requisitos do cliente que serão tratados pelo projeto do software. -A Gerência de Requisitos envolve o estabelecimento e manutenção de um acordo com o cliente relativo aos requisitos do software.
-Este acordo cobre tanto os requisitos técnicos (funcionais) como os não técnicos (não funcionais) e será a base para estimativa, planejamento, execução e acompanhamento das atividades do projeto de desenvolvimento do software durante seu ciclo de vida.
Principais atividades da Engenharia de Requisitos
Onde falhamos?
Falhamos
quando
realizamos
uma pobre
gerência dos
requisitos
É uma atividade crucial no processo de
engenharia de requisitos, ou seja, é necessário não somente escrever os requisitos de forma compreensível mas também permitir que eles possam ser rastreados e gerenciados ao longo da evolução do sistema
Realizando-se uma Gerência de Requisitos
eficaz, é possível responder a questões como: Quantos requisitos há neste projeto? Quantos são de prioridade alta? Que percentagem dos requisitos está incorporada na linha de base do projeto?
Falhamos quando perdemos o controle do
processo, permitindo que cliente e gerentes interfiram diretamente na equipe e no processo de desenvolvimento do sistema.
Gerência de mudanças
-
O impacto das mudanças é avaliado sobre os compromissos assumidos e as mudanças são negociadas.−− Mudanças nos compromissos assumidos com pessoas ou grupos externos à organização são revisados com a gerência superior.
- Mudanças nos compromissos assumidos dentro da organização são negociadas com os grupos afetados.
- Mudanças que forem necessárias nos planos do software, produtos e atividades resultantes de mudanças nos requisitos alocados são:
-o Identificadas; -o Estimadas; -o Avaliados os riscos; -o Documentadas; -o Planejadas;
-o Comunicadas aos grupos e pessoas afetados; e -o Acompanhadas até a conclusão.
Principais atividades da Engenharia de Requisitos
Onde falhamos?
Falhamos
quando
realizamos
uma pobre
gerência dos
mudanças
Raramente nos preparamos para
acompanhar essas mudanças. Sem falar que, pouquíssimos projetos realizam algum processo formal para analisar o impacto e custo dessas mudanças.
Mudanças sempre implicam em
retrabalho. Mudanças sem planejamento, sem critério de avaliação e comunicação à equipe aumentam esse retrabalho.
Falhamos porque desconsideramos as
solicitações de mudanças que ocorrerão, não nos preparando para recebê-las, avaliá-las e implementá-las com o menor impacto para o projeto.
