Engenharia de Software: Teoria e PráticaShari Lawrence Pfleeger Capítulo 4 Prentice Hall
Identificando requisitos
Requisito: é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar para atingir seus objetivos
Três categorias de requisitos: requisitos que devem ser totalmente satisfeitos requisitos que são altamente desejáveis, mas não
necessários requisitos que são possíveis, mas poderiam ser
eliminados
Engenharia de Software: Teoria e PráticaShari Lawrence Pfleeger Capítulo 4 Prentice Hall
Documentos de requisitos
Definição dos requisitos: listagem completa de tudo que o cliente espera que o sistema proposto faça
Especificação dos requisitos: redefine os requisitos em termos técnicos apropriados para o desenvolvimento do projeto do sistema
Gerência de configuração: correspondência direta entre os dois requisitos
Engenharia de Software: Teoria e PráticaShari Lawrence Pfleeger Capítulo 4 Prentice Hall
Gerência de configuração
Conjunto de procedimentos que controlam os requisitos que definem o que o sistema deverá
fazer os módulos de projeto gerados a partir dos
requisitos o código do programa que implementa o projeto os testes que verificam a funcionalidade do
sistema os documentos que descrevem o sistema
Engenharia de Software: Teoria e PráticaShari Lawrence Pfleeger Capítulo 4 Prentice Hall
Requisitos funcionais versus não-funcionais Funcional: descreve uma
interação entre o sistema e seu ambiente
Exemplos: o sistema dever ter
comunicação com um sistema ‘x’ externo
Quais estados devem ser encontrados para uma mensagem ser enviada
Não-funcional: descreve uma restrição do sistema que limita nossas opções para criar uma solução para o problema
Exemplos: Contracheques
distribuídos em não mais que quatro horas depois de os dados iniciais terem sido lidos
Sistema limita o acesso a gerentes seniores
Engenharia de Software: Teoria e PráticaShari Lawrence Pfleeger Capítulo 4 Prentice Hall
Tipos de requisitos Ambiente físico Interfaces Usuários e fatores humanos Funcionalidade Documentação Dados Recursos Segurança Garantia de qualidade
Engenharia de Software: Teoria e PráticaShari Lawrence Pfleeger Capítulo 4 Prentice Hall
Características dos requerimentos Estão corretos? São consistentes? Estão completos? São realistas? Cada requisito descreve algo necessário ao
cliente? Podem ser verificados? Podem ser rastreados?
Engenharia de Software: Teoria e PráticaShari Lawrence Pfleeger Capítulo 4 Prentice Hall
Descrições estáticas dos requerimentos Referência indireta
Exemplo: k equações em n variáveis Relações de recorrência
Exemplo: F(0) = 1; F(1) = 1; F(n + 1) = F(n) + F(n – 1)
Definição axiomática Expressão como uma linguagem
Exemplo: BNF
Engenharia de Software: Teoria e PráticaShari Lawrence Pfleeger Capítulo 4 Prentice Hall
<condi t i on> : : = <bool - t er m> | <bool - t er m> or <condi t i on><bool - t er m> : : = <bool - f act or > | <bool - f act or > and <bool -
t er m><bool - f act or > : : = <expr > <r el op> <expr > | ( <condi t i on>)<r el op> : : = < | < | = | > | > | < ><expr > : : = <t er m> | <expr > <addop> <t er m> | <addop>
<expr ><t er m> : : = <f act or > | <t er m> <mpyop> <f act or ><f act or > : : = <scal ed- expr > | <pr i mar y><scal ed- expr > : : = ( <expr >) <scal e> | <number > <scal e><pr i mar y> : : = ( <expr >) <r egname> | <number > | <f unc>
( <expr >)<number > : : = <i nt eger > | <i nt eger >. | . <i nt eger > |
<i nt eger >. <i nt eger ><r egname> : : = $ <r egchar > | <r egname> <r egchar ><i nt eger > : : = <di gi t > | <di gi t > <i nt eger ><r egchar > : : = <di gi t > | <l et t er > | <under scor e><addop> : : = + | -<di gi t > : : = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9<f unc> : : = abs | t r unc<l et t er > : : = A | a | B | b | C | c | D | d | E | e |
. . . | Y | y | Z | z<myop> : : = * | / | mod<scal e> : : = c | d | h | i | l | P | p | q | t | v<under scor e> : : = _ ( ASCI I char act er 95)
Engenharia de Software: Teoria e PráticaShari Lawrence Pfleeger Capítulo 4 Prentice Hall
Abstração de dados
Engenharia de Software: Teoria e PráticaShari Lawrence Pfleeger Capítulo 4 Prentice Hall
Descrições dinâmicas
Tabelas de decisão
Engenharia de Software: Teoria e PráticaShari Lawrence Pfleeger Capítulo 4 Prentice Hall
Descrições dinâmicas (2)
Descrição funcional e tabelas de transiçãof(Si, Cj) = Sk
Engenharia de Software: Teoria e PráticaShari Lawrence Pfleeger Capítulo 4 Prentice Hall
Descrições dinâmicas (3)
Tabelas de eventos
• Redes de Petri
Engenharia de Software: Teoria e PráticaShari Lawrence Pfleeger Capítulo 4 Prentice Hall
Abordagem orientada a objetos
Cada entidade no sistema é um objeto. Um método ou uma operação é uma ação que pode
ser realizada pelo objeto ou pode acontecer com o objeto
Encapsulamento: maneira pela qual os métodos formam um limite de proteção em torno do objeto
Hierarquias de classe de objetos estimulam a herança Polimorfismo: mesmo método para diferentes
objetos, cada qual com diferentes comportamentos
Engenharia de Software: Teoria e PráticaShari Lawrence Pfleeger Capítulo 4 Prentice Hall
Notações de requisitos adicionais Técnicas hierárquicas
diagramas de Warnier Diagramas de fluxo de dados Software Requirements Engineering
Methodology — SREM Structured Analysis and Design Technique —
SADT Z
Engenharia de Software: Teoria e PráticaShari Lawrence Pfleeger Capítulo 4 Prentice Hall
R_NET: PROCESS_TRANSACTI ONSTRUCTURE:
I NPUT_I NTERFACE_ACCOUNT_REQUEST_RECORDEXTRACT_DATESDO ( REQUEST=TRANSACTI ON)
RECORD_TRANSACTI ONTERMI NATE
OTHERWI SEFI ND_ACCOUNT- RECORDSCOMPUTE_SAVI NGS_BALANCEAND COMPUTE_CHECKI NG_BALANCEAND COMPUTE_MONEY- MARKET_BALANCEPRI NT_BALANCESTERMI NATE
ENDEND
Engenharia de Software: Teoria e PráticaShari Lawrence Pfleeger Capítulo 4 Prentice Hall
Etapas da SREM
Engenharia de Software: Teoria e PráticaShari Lawrence Pfleeger Capítulo 4 Prentice Hall
Exemplo ZST = Key VALI NI T st ’ : ST st ’ = {} I NSERT st , st ’ : ST k : KEY v : VAL k dom( st ) st ’ = st {k v} LOOKUP st , st ’ : ST k : KEY v : VAL k dom( st ) v’ = st ( k) st ’ = st DELETE st , st ’ : ST k : KEY k dom( st ) st ’ = {k} st
Engenharia de Software: Teoria e PráticaShari Lawrence Pfleeger Capítulo 4 Prentice Hall
Prototipação de requisitos
Protótipo descartável Protótipo evolutivo Protótipo rápido
Engenharia de Software: Teoria e PráticaShari Lawrence Pfleeger Capítulo 4 Prentice Hall
Documentação de requisitos Documento de definição de requisitos: o que o
cliente gostaria de ver: propósito geral fundamentos e objetivos de desenvolvimento do
sistema descrição da abordagem características detalhadas ambiente operacional
Documento de especificação de requisitos: o que o desenvolvedor precisa saber
Engenharia de Software: Teoria e PráticaShari Lawrence Pfleeger Capítulo 4 Prentice Hall
Exemplo
Engenharia de Software: Teoria e PráticaShari Lawrence Pfleeger Capítulo 4 Prentice Hall
Participantes no processo de requisitos
Monitores do contrato Clientes e usuários Gerentes de negócios Projetistas Testadores
Engenharia de Software: Teoria e PráticaShari Lawrence Pfleeger Capítulo 4 Prentice Hall
Engenharia de Software: Teoria e PráticaShari Lawrence Pfleeger Capítulo 4 Prentice Hall
Engenharia de Software: Teoria e PráticaShari Lawrence Pfleeger Capítulo 4 Prentice Hall
Revisão dos requisitos Rever metas e objetivos estabelecidos para o sistema Comparar requisitos metas o objetivos Descrever o ambiente operacional Examinar
interfaces fluxo de informações funções
Verificar omissões, imperfeições e inconsistências Documentar riscos Discutir sobre como o sistema será testado
Engenharia de Software: Teoria e PráticaShari Lawrence Pfleeger Capítulo 4 Prentice Hall
Escolhendo uma técnica de especificação de requisitos
Aplicabilidade Possibilidade de implementação Testabilidade/simulação Avaliabilidade Manutenibilidade Modularidade Nível de abstração/expressividade Solidez
• Verificabilidade
• Segurança durante a execução
• Maturidade da ferramenta
• Imprecisão
• Curva de aprendizado
• Maturidade técnica
• Modelagem de dados
• Disciplina
Engenharia de Software: Teoria e PráticaShari Lawrence Pfleeger Capítulo 4 Prentice Hall
Exemplo de sistema de informação
Adver t i si ng Campai gn = *Ent i t y. Recor ds t he condi t i ons and ai msf or a campai gn t o adver t i se a pr oduct . *Campai gn Number + Campai gn St ar t Dat e + Campai gn End Dat e
+ Tar get Audi ence + Tar get Rat i ng Per cent age+ Campai gn Pr edi ct ed Rat i ng + Campai gn Budget Tot al+ Pi ccadi l l y Budget Amount + Campai gn Dur at i on+ {Requi r ed Spot Dur at i on}*Wor k necessar y t o r emove or j ust i f y t he r epeat i ng gr oup. *
Tar get Audi ence = *Dat a el ement . The audi ence at whi ch a campai gni s ai med. See Audi ence Type f or val ues. *
Audi ence Type = *Dat a el ement . Used t o cl assi f y r at i ngs fi gur es. *[Homes | Homemakers | Adults | Men | Women | Children]
Engenharia de Software: Teoria e PráticaShari Lawrence Pfleeger Capítulo 4 Prentice Hall
Exemplo em tempo realSTATE SEL_WORKI NG;
I NPUT Cl ear ( l i ne) ;DECI SI ON ( ( cond[ l i ne] == OOS)
| | ( cond[ WORK] == OOS) ) ;( TRUE) :
TASK ‘ badi nput = 1’ ;NEXTSTATE- ’
ENDDECI SI ON;TASK ‘ cond[ l i ne] = NORMAL’ ;DECI SI ON ( ( l i ne == PROT) &&
( cond[ WORK] > cond[ PROT] ) ) ;( TRUE) :
NEXTSTATE SEL_PROTECTI ON;ENDDECI SI ON;NEXTSTATE- ;
ENDSTATE SEL_WORKI NG;
CLAI M;( ( APSENV FI RSTMSG Done)&& ( envmsg == CONDSWI TCH)&& ( sel ! = psel ) )I MPLI ES ( cond[ sel ] <= pcond[ psel ] )UNTI L ( sel == psel ) ;
ENDCLAI M;