Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Identificando requisitos Requisito: é uma característica do sistema

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


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


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


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


Tipos de requisitos Ambiente físico Interfaces Usuários e fatores humanos Funcionalidade Documentação Dados Recursos Segurança Garantia de qualidade


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?


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


<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 > : : = | . | . |

. <r egname> : : = $ <r egchar > | <r egname> <r egchar > : : = <di gi t > | <di gi t > <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)


Abstração de dados


Descrições dinâmicas

Tabelas de decisão


Descrições dinâmicas (2)

Descrição funcional e tabelas de transiçãof(Si, Cj) = Sk


Descrições dinâmicas (3)

Tabelas de eventos

• Redes de Petri


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


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


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


Etapas da SREM


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


Prototipação de requisitos

Protótipo descartável Protótipo evolutivo Protótipo rápido


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


Exemplo


Participantes no processo de requisitos

Monitores do contrato Clientes e usuários Gerentes de negócios Projetistas Testadores




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


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


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]


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;

Documents

Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Identificando requisitos Requisito: é uma característica do sistema