Title: Slide sem t
1Gerência de Requisitos
07/11/2006
2Objetivo
- Conscientizar os participantes da importância dos
requisitos no processo de desenvolvimento de
sistemas, em conformidade com as normas de
qualidade de software
3Parte I Introdução a Requisitos
4Sumá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
5 Introdução a Engenharia de Sistemas
6O 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
7Desenvolvimento 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
8Ciclo de vida clássico (em cascata)
Engenharia de Sistemas
Análise
Projeto
Codificação
Teste
Manutenção
9Desenvolvimento 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
10Modelagem 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
11O 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.
12Caracterí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)
13Caracterí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?
14Como 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)
15 Problemas do Processo de Desenvolvimento
16Software 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
17Software 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
18Quais 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
19Causas ó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
20Causas 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
21Mitos 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)
22Mitos do Software - do Cliente
- Uma declaração geral é suficiente para começar a
escrever programas - Mudanças podem ser facilmente acomodadas em um
projeto
23Mitos 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
24Recursos 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.
25(No Transcript)
26As 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)
27 Motivação
28A crise do software
- Força Aérea Americana, software de comando e
controle (anos 80) - custo inicial estimado U400.000,00
- custo final U3.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
U90.000.000,00 para corrigir o software que
custou U103.000.000,00 - devido ao atraso, a RF ainda teve de pagar mais
U63.000.000,00 de multas por atraso e juros - (B.Brügge 1997, Notas de curso TUM)
29A crise do software
- Ônibus Espacial
- Custo U10.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)
30Motivaçã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 necessidades ?
software inútil
(Chaos, 1994)
31Motivaçã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)
32(No Transcript)
33Motivaçã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
34Motivaçã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
35(No Transcript)
36 A Importância dos Requisitosno Processo de
Desenvolvimento
37(No Transcript)
38Requisitos
- 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)
39Requisitos
- 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
40Requisitos 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)
41Requisitos
- 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 facilidade encontrada no nível do usuário
- uma propriedade geral do sistema
- uma restrição do sistema
- uma restrição ao desenvolvimento do sistema
- (Sommerville, 2003)
42Requisitos - 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
43Requisitos 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
44Requisitos 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
45Como 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
46Itens 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
47Abordagem 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
48Abordagem 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
49Conceitos
- Regra de Negócio
- Requisitos Funcionais e Não Funcionais
- ISO/IEC 9126
50Regra 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
51Importâ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
52Exemplo 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
53Requisitos Classificação
- requisitos funcionais, não funcionais, inversos
- requisitos funcionais
- aqueles diretamente relacionados à
funcionalidade do software - dependentes do problema e independentes da
solução
54Requisitos 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
55Exemplos 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
56(No Transcript)
57Exemplos 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