Slide sem t

1
Gerência de Requisitos
07/11/2006
2
Objetivo

• Conscientizar os participantes da importância dos
  requisitos no processo de desenvolvimento de
  sistemas, em conformidade com as normas de
  qualidade de software

3
Parte I Introdução a Requisitos
4
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

5
Introdução a Engenharia de Sistemas
6
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

7
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

8
Ciclo de vida clássico (em cascata)
Engenharia de Sistemas
Análise
Projeto
Codificação
Teste
Manutenção
9
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

10
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

11
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.
12
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)

13
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?

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

15
Problemas do Processo de Desenvolvimento
16
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

17
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

18
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

19
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

20
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

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

22
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

23
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

24
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.
25
(No Transcript)
26
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)

27
Motivação
28
A 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)

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

30
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 necessidades ?
  software inútil

(Chaos, 1994)
31
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)
32
(No Transcript)
33
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

34
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

35
(No Transcript)
36
A Importância dos Requisitosno Processo de
Desenvolvimento
37
(No Transcript)
38
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)

39
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

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

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

42
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

43
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

44
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

45
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

46
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

47
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

48
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

49
Conceitos

• Regra de Negócio
• Requisitos Funcionais e Não Funcionais
• ISO/IEC 9126

50
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

51
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

52
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

53
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

54
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

55
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

56
(No Transcript)
57
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