Gerência de Requisitos
07/11/2006
Objetivo
Conscientizar os participantes da importância dos
requisitos no processo de desenvolvimento de
sistemas, em conformidade com as normas de
qualidade de software
Parte I:
Introdução a Requisitos
Sumário
Introdução a Engenharia de Sistemas
Problemas do Processo de Desenvolvimento
A Importância dos Requisitos no Processo de
Desenvolvimento
Motivação
Conceitos
– Regras de Negócio
– Requisitos Funcionais e Não Funcionais
– ISO/IEC 9126
Introdução a Engenharia de Sistemas
O Conceito de Sistemas
Um sistema pode ser definido como:
"Um conjunto, identificável e coerente, de
elementos que interagem coesivamente,
onde cada elemento pode ser um
sistema."
– equivale a traçar uma fronteira conceitual separando esse conjunto de
elementos do resto do universo
Desenvolvimento de Sistemas
O processo de desenvolvimento é composto de
(independente de metodologia):
–
–
–
–
Especificação do Problema
Elicitação e Especificação dos Requisitos (Análise)
Planejamento da Solução (Projeto)
Implementação em uma Linguagem de Programação
Metodologia
– conjunto de conceitos, ferramentas e técnicas que
permitem a construção de um modelo do domínio do
problema e da adição de detalhes de implementação
durante o projeto do sistema
Ciclo de vida clássico (em cascata)
Engenharia
de Sistemas
Análise
Projeto
Codificação
Teste
Manutenção
Desenvolvimento de Sistemas
Sistemas apresentam uma complexidade
– Porte
– Intrínseca
Seu desenvolvimento é um processo de elaboração de
modelos
– A modelagem é aplicada a cada etapa do processo de
desenvolvimento
– A cada etapa podem ser empregadas um conjunto diferente de
ferramentas e técnicas de modelagem
Modelagem de Sistemas
Objetivo
– reconhecimento do padrão interno que permite ao sistema
responder aos estímulos do ambiente externo
– padrão Interno = comportamento + informação
Recursividade do Conceito de Sistemas
– Sistema = {subsistemas}, onde cada subsistema é também um
sistema
O Conceito de Modelo
“Modelo é a representação abstrata que
permite descrever e/ou prever
comportamentos específicos de um
Sistema através do estudo de suas
características relevantes.”
Características de um Modelo
Aplicação de critérios de:
– segmentação (porte)
– abstração de características irrelevantes ao modelo (intrínseca)
Objetivo:
– explicitação de entidades (objetos) e relacionamentos relevantes
ao modelo
Utiliza uma linguagem de representação rigorosa
(sintaxe, semântica e formalismo)
Características de um Modelo
Possui capacidade preditiva
– O modelo é capaz de responder a perguntas específicas
• O comportamento do modelo é compatível com o sistema modelado?
• O modelo se adequa aos objetivos a serem atingidos pelo sistema?
Como modelar?
o que será modelado é função da relevância dos
aspectos a serem inseridos no modelo em função do seu
objetivo
não existe receita "pronta", envolve a intuição,
criatividade e julgamento crítico do modelador
manutenção de consistência interna dos aspectos
representados no modelo
validação experimental (correspondência de
comportamento previsto a partir do modelo com o
comportamento real do sistema)
Problemas do Processo de Desenvolvimento
Software x Hardware
O software é desenvolvido ou projetado por engenharia,
não manufaturado no sentido clássico
– O software é um elemento de sistema lógico e não físico
– existem semelhanças entre o desenvolvimento de software e o
de hardware (manufatura)
• a alta qualidade é obtida a partir de um bom projeto mas os
custos do software estão concentrados no trabalho de
engenharia
Software x Hardware
O software não se desgasta (como o hardware) mas se
deteriora
– Durante sua vida o software enfrentará mudanças, que podem
introduzir novos defeitos
Não existem “peças de reposição” para o software
– Quando o hardware se desgasta é substituído por uma peça de
reposição
– A complexidade e o custo de manutenção do software é muito
maior
A maioria dos softwares é feita sob medida
– Montagem por reuso de componentes
– Este é um cenário que está mudando
Quais são os problemas?
A sofisticação do software ultrapassou
nossa capacidade de desenvolvimento
– A construção de programas não acompanha a demanda por novos programas
– A manutenção de programas é ameaçada por projetos ruins
– Geralmente não há metodologia e controle de qualidade para projetos
Causas óbvias
Não dedicamos tempo para coletar dados
sobre o desenvolvimento do software resulta em estimativas “a olho”
Comunicação entre o cliente e o
desenvolvedor é fraca
Falta de testes sistemáticos e completos
Causas menos óbvias
Gerentes sem background em
desenvolvimento de software
Profissionais recebem pouco treinamento
formal
Falta investimento (em ES)
Faltam métodos e automação
Falta acompanhamento do processo de
desenvolvimento
Mitos do Software - Administrativos
Um manual oferece tudo que se precisa
saber
Computadores de última geração
solucionam problemas de desenvolvimento
Se estamos atrasados, basta adicionarmos
programadores e tirar o atraso (chamado
“conceito de hordas de mongóis”)
Mitos do Software - do Cliente
Uma declaração geral é suficiente para
começar a escrever programas
Mudanças podem ser facilmente
acomodadas em um projeto
Mitos do Software - do Profissional
Um programa está terminado ao funcionar
Quanto mais cedo escrever o código, mais
rápido terminarei o programa
Só posso avaliar a qualidade de um
programa em funcionamento
A única coisa a ser entregue em um
projeto é o programa funcionando
Recursos Humanos - Importância
Qual a importância dos Recursos Humanos
no processo de desenvolvimento de
software?
Motivo: a comunicação é absolutamente essencial
para o desenvolvimento do software.
Todo novo caminho de comunicação exige
esforço adicional e portanto, tempo adicional.
Recursos Humanos – Grau de participação em
projetos
alto
Pessoal
técnico senior
Grau de
participação
no projeto
baixo
Pessoal
técnico junior
Administrador
Planejamento
Projeto
Codificação
Projeto
Análise de preliminar
Teste de
detalhado
requisitos
unidade
As 10 Áreas da Engenharia de Software
Gerência de Configuração de Software
Gerência de Engenharia de Software
Processo de Engenharia de Software
Ferramentas e Métodos
Qualidade de Software
Requisitos de software
Design de software
Construção de Software
Teste de Software
Manutenção de Software
(SWEBOK, 2004)
Motivação
A crise do software
Força Aérea Americana, software de comando e controle
(anos 80):
– custo inicial estimado: U$400.000,00
– custo final: U$3.200.000,00
(Jalote, 1997)
Software de recebimento de imposto de renda
(EUA):
– qualidade: o sistema se mostrou inadequado para a carga esperada
– custo: a Receita Federal dos EUA gastou mais U$90.000.000,00 para
corrigir o software que custou U$103.000.000,00
– devido ao atraso, a RF ainda teve de pagar mais U$63.000.000,00 de
multas por atraso e juros
(B.Brügge 1997, Notas de curso TUM)
A crise do software
Ônibus Espacial:
– Custo: U$10.000.000.000,00 (vários milhões a mais do que o
estimado)
– Prazo: 3 anos de atraso
– Qualidade: primeiro lançamento do Columbia foi cancelado devido a
problemas de sincronização de seus 5 computadores de bordo
• Causa: modificação feita 2 anos antes, em que o tempo de espera de um
tratador de interrupção passou de 50ms para 80ms
• O erro era um evento raro, tanto que não foi detectado durante as mais de
mil horas de teste
– Muitos erros ainda subsistem. Os astronautas recebem um livro
contendo os problemas de software que já são conhecidos
(B.Brügge 1997, Notas de curso TUM)
Motivação
70% dos projetos de software falham ou
são gravemente prejudicados:
– negligenciam os cuidados com a elicitação dos requisitos
– gerenciam mal seus requisitos
Um software que não satisfaz as (Chaos, 1994)
necessidades  software inútil
Motivação
Pesquisa realizada com 365 gerentes executivos de TI dos EUA
Três principais critérios de sucesso
1. Envolvimento do Usuário
2. Apoio da Gerência Executiva
3. Indicação Clara dos Requisitos
Projetos falham ou são prejudicados
1. Requisitos Incompletos
2. Falta de Envolvimento do Usuário
3. Falta de Recursos
(Chaos, 1994)
Motivação
O que acontece se:
– o usuário mudar de idéia em relação a uma funcionalidade?
– o engenheiro de requisitos (ou analista) não entendeu corretamente a
necessidade do usuário?
– o ambiente mudar?
– o usuário perceber novas possibilidades na automação?
Mudanças
Motivação
Mudanças são inevitáveis
Razões para mudanças:
– modificações no ambiente: regras de negócios, leis, políticas
internas
– mudanças tecnológicas
– a complexidade dos sistemas impõe mudanças à medida que se
adquire maior conhecimento sobre os mesmos
– correção ou ajustes em requisitos incorretos ou mal definidos
– desenvolvedores querem adicionar funcionalidades mais
avançadas de modo a oferecer vantagem
– clientes mudam de idéia
Motivação
é preciso gerenciar as mudanças!
mudanças em requisitos ao longo do desenvolvimento de
software fazem parte do processo
alterações em requisitos podem implicar em mudanças
em artefatos de design, de código, casos de testes, etc
Requisitos que tendem a mudar devem ser tratados
isoladamente
Isolar regras de negócio para reuso
Motivação
re-trabalho e custo
associado à correção de
erros
quanto mais tarde o erro
é descoberto, mais
custosa será a correção
(Boehm, 1981)
A Importância dos Requisitos
no Processo de Desenvolvimento
Requisitos de Software
Uma compreensão completa dos Requisitos do
Software é fundamental para obter um software e um
processo de desenvolvimento com alta qualidade
O software deve evoluir para atender às
necessidades mutáveis dos clientes
.....“a construção por múltiplas pessoas de um
software de múltiplas versões” (Parnas, 1987)
Requisitos
Requisito
– Uma condição ou capacidade que deve ser satisfeita ou
possuída por um sistema ou componente do sistema para
satisfazer um contrato, um padrão ou uma especificação
(IEEE, 1990)
Especificação:
– Uma descrição rigorosa e minuciosa das características que
um material, uma obra, ou um serviço deverão apresentar
(Aurélio, 1999)
Requisitos
Requisitos do usuário
– Declarações, em linguagem natural e diagramas, sobre os serviços que o
sistema oferece e as restrições para a sua operação. Escrito para os
clientes
Requisitos do sistema
– Estabelecem detalhadamente as funções e restrições do sistema. O
documento de requisitos, chamado de especificação funcional, pode
servir como um contrato entre cliente e desenvolvedor
Especificação de software
–
Especificação abstrata e precisa do software, indicando o que ele deve
fazer (sem dizer como) que serve de base para o projeto e para a
implementação
– Acrescenta mais detalhes à especificação funcional e é escrito para a
equipe de desenvolvimento
Requisitos PETROBRAS
Requisito de Negócio
– Descrevem as atividades que os usuários deverão ser capazes de
executar com a utilização do sistema, delimitando o domínio do
problema
– Estão descritos no Documento de Visão
– Funcionais, não funcionais e inversos
Requisito de Produto
– Descrevem características associadas a implementação da
solução
– Funcionais (Doc. de Caso de Uso) e não funcionais (Doc. de
Especificação Suplementar)
Requisitos
Requisitos servem como especificação do que deve ser
implementado
Requisitos são descrições de como o sistema deve se
comportar, de uma propriedade ou atributo do sistema
Um requisito pode descrever:
–
–
–
–
uma
uma
uma
uma
facilidade encontrada no nível do usuário
propriedade geral do sistema
restrição do sistema
restrição ao desenvolvimento do sistema
(Sommerville, 2003)
Requisitos - Exemplos
“O sistema deve rodar em microcomputadores da
linha PC que possuam microprocessador Pentium ou
superior”
“A interface do sistema deve ser gráfica, de acordo
com um padrão de interface dirigida a menu”
“Alternativamente, o sistema deve possibilitar o seu
uso através de linhas de comando, para usuários
avançados”
“O gerente da padaria deve consultar quanto vendeu
em um dia”
Requisitos: diretrizes para elaboração 1/2
Definir um formato padrão e usá-lo para todos os
requisitos
Utilizar o idioma de forma consistente. Usar “deve”
para requisitos obrigatórios, “deveria” (ou é
recomendável) para requisitos desejáveis
Evitar o uso de jargões de computação
Empregar termos característicos do problema
Requisitos: diretrizes para elaboração 2/2
Use sentenças diretas e objetivas
Use vocabulário limitado
Defina requisitos verificáveis
Evite ambigüidades
Evite sentenças muito longas
Evite uso de conjunções como ou, e, com,
também
Evite termos vagos ou indefinidos
Como especificar Requisitos
Linguagem natural estruturada
– A abordagem estruturada emprega templates para registrar, validar e gerenciar
requisitos
– Nesta abordagem é preciso definir um ou mais formulários ou templates para
expressar os requisitos.
– Vantagens
• Uniformidade
• Possibilidade de agrupar requisitos
• Possibilidade de rastrear os requisitos
Itens importantes de um template
Para especificar requisitos:
–
–
–
–
–
–
Descrição da necessidade atendida pelo requisito
Descrição da função ou entidade que está sendo especificada
Descrição de suas entradas e de onde elas se originam;
Descrição de suas saídas e para onde elas prosseguirão
Indicação de quais outras entidades são utilizadas
Pré-Condição
• Condição que deve ser verdadeira para que seja executado
– Pós-Condição
• O estado resultante do sistema
Abordagem estruturada
Pré-condições:
– definem o que deve ser verdadeiro na estrutura da informação
armazenada para que a operação ou consulta possa ser
executada
– algum mecanismo externo deverá garantir sua validade antes de
habilitar a execução da operação ou consulta ao sistema
Pós-condições:
– estabelecem o que uma operação de sistema muda na estrutura
da informação armazenada
– estabelece a resposta gerada pelo sistema quando a operação é
executada
Abordagem estruturada - Exemplo
Requisitos
– um novo cliente deve ser cadastrado em uma Video Locadora
– O cadastro do cliente contém nome, endereço e telefone
Pré-condição:
– Não existe nenhum cliente com o nome informado
Pós-condição:
– O cliente foi adicionado ao cadastro
– Os dados informados sobre o cliente são atualizados nos
atributos do cliente
– O cliente é criado com o débito zerado
Exemplo – Copiar/Colar
Descrição da necessidade:
– O usuário necessita acrescentar um trecho em um documento que é cópia de um
trecho já existente
Descrição da função ou entidade:
– Função Copiar/Colar: copiar uma parte de um documento em um editor de texto
Descrição de entradas e origem:
– O usuário seleciona o trecho a copiar e posiciona o cursor no documento na
posição onde a cópia do trecho será inserida
Descrição de saídas e destino
– Texto duplicado na posição do cursor
Entidades envolvidas:
– Documento, Usuário
Pré-Condição:
– O documento está aberto para edição
Pós-Condição:
– O documento é alterado, recebendo o trecho marcado para cópia na posição
selecionada
Exercício 1
Em dupla, debater:
– De posse da descrição do sistema de Emissão de passagens de trem (próximo
slide) descubra ambigüidades ou omissões no sistema
Sistema de emissão de passagens de trem
Um sistema automático de emissão de passagens vende
passagens de trem. Os usuários escolhem seu destino e
apresentam um cartão de crédito e um número de identificação
pessoal. A passagem é emitida e o custo desta passagem é
incluído em sua conta do cartão de crédito. Quando o usuário
pressiona o botão para iniciar, uma tela de menu com os
possíveis destinos é ativada, juntamente com uma mensagem
para que o usuário selecione um destino. Uma vez selecionado
um destino pede-se que os usuários insiram seu cartão de
crédito. A validade do cartão é checada e o usuário, então, deve
fornecer um número de identificação pessoal. Quando a
transação de crédito é validada, a passagem é emitida.
Exercício 2
Reescreva a descrição anterior usando a
Abordagem estruturada.
•
•
•
•
•
•
•
Descrição da necessidade
Descrição da função ou entidade
Descrição de entradas e origem
Descrição de saídas e destino
Entidades envolvidas
Pré-Condição
Pós-Condição
Conceitos
• Regra de Negócio
• Requisitos Funcionais e Não Funcionais
• ISO/IEC 9126
Regra de Negócio
O que é uma Regra de Negócio?
– Define ou restringe aspectos da organização
– Fontes:
• decisões estratégicas
• leis e regulamentações
• obrigações contratuais
Importância de identificar
Regras de Negócio
As melhores práticas de engenharia de
software advogam código reusável e
modular
Separar regras de negócio de projetos
específicos é uma forma de adaptar esta
regra para a gerência de requisitos
– as regras de negócio podem ser empregadas em vários projetos
Exemplo de Regra de Negócio
“Os remédios comercializados devem ter,
no mínimo, 30 dias de validade”
“Para ser considerado dependente, a
pessoa não pode ter renda ou a renda
deve ser abaixo de um salário mínimo”
Requisitos: Classificação
requisitos funcionais, não funcionais,
inversos
requisitos funcionais:
–
–
aqueles diretamente relacionados à funcionalidade do software
dependentes do problema e independentes da solução
Requisitos: Classificação
Requisitos não funcionais: relacionados a
aspectos de qualidade que o software
deverá apresentar, ou a restrições a
serem atendidas
Exemplo: Norma de Qualidade da ISO/IEC 9126
– Dependente da solução
Requisitos inversos: representam
funcionalidades que estão fora do escopo
da solução
Exemplos de Requisitos
Requisito funcional
“O sistema deve controlar o horário de entrada e
saída dos funcionários”
Requisito não funcional
“O relatório mensal dos horários, por funcionários,
deve ser impresso em papel timbrado”
Requisito inverso
“O sistema somente será implementado em
idioma nacional”