Princpios Fundamentais da Anlise de Requisitos

Marcelo Augusto Santos Turine

O ciclo de vida clssico

Engenharia de Sistemas Anlise Projeto Codificao Teste Manuteno

Uma compreenso completa dos Requisitos do Software fundamental para obter um software e um processo de desenvolvimento com alta qualidade No importa quo bem projetado ou codificado est um programa, se ele for mal analisado e especificado desapontar o usurio e trar aborrecimentos ao desenvolvedor
3

Fase de Anlise de Requisitos

Engenharia de Sistemas de Computador

PONTE
ANLISE DE REQUISITOS

Projeto de Software

Escopo do Software Primeiro passo tcnico Analista de Sistemas 4

Anlise de Requisitos
processo de descoberta e refinamento  ATORES: cliente e desenvolvedor
Cliente: reformula um conceito de funo e desempenho (s vezes nebuloso) Desenvolvedor: indagador e solucionador de problemas


PROBLEMA: grande propenso a mal entendidos "atividade aparentemente simples torna-se complexa"

Definio: Requisitos e Especificao



Glossrio de Engenharia de Software (IEEE) e do Aurlio Requisito (IEEE)

Uma condio ou capacidade necessitada por um usurio para resolver um problema ou alcanar um objetivo Uma condio ou capacidade que deve ser satisfeita por um sistema para satisfazer um contrato ou um padro
6

Requisito (Aurlio)
Condio necessria para a obteno de certo objetivo, ou para o preenchimento de certo fim

Especificao:
descrio rigorosa e minuciosa das caractersticas que um material, uma obra, ou um servio dever apresentar processo de representao dos requisitos de uma forma que leva implementao bem-sucedida
7

Exemplos


O sistema deve rodar em microcomputadores da linha IBM PC que possuam microprocessador 486 DX ou superior. A interface do sistema deve ser grfica, de acordo com um padro de interface dirigida a menu. Alternativamente, o sistema deve possibilitar o seu uso atravs de linhas de comando, para usurios avanados.
8

Tipos de Requisitos (diviso utilizada na literatura)

Funcionais No

Funcionais (de Qualidade)

ISO - The International Organization for Standardizatized IEC - The International Electrotechnical Commition (formam o sistema especializado para padronizao mais conhecido)
9

Requisitos de Software


A Norma ISO/IEC 9126 define seis caractersticas de qualidade de software que devem ser avaliados:
Funcionalidade (finalidade do produto) Usabilidade (esforo para utilizar, aprender o produto) Confiabilidade (freqncia de falhas, recuperabilidade) Eficincia (desempenho) Manutenibilidade (esforo necessrio para modificar) Portabilidade (capacidade de transferir o produto para outros ambientes)

10

elementos alocados ao software estabelecimento do alcance recursos, custo cronograma

Plano de Desenvolvimento do Software

reviso

reviso administrativa

aceitvel no
construir prottipo para estabelecer os requisitos os requisitos so conhecidos?

sim
determinar domnio das informaes e das funes, interfaces, restries de projeto e critrios de validao

reviso

reviso tcnica

aceitvel
revisar e justificar recursos, custos e cronogramas reviso do plano de projeto do software

Especificao dos Requisitos do Software

aceitvel

incio da fase de desenvolvimento

11

Dilema do Engenheiro de Software

Declarao de um cliente annimo: Sei que voc acredita que entendeu o que acha que eu disse, mas no estou certo de que percebe que aquilo que ouviu no o que eu pretendia dizer ...

12

ATIVIDADES de ANLISE: 1 - reconhecimento do problema 2 - avaliao do problema e

sntese da soluo (Modelagem)

3 - especificao dos requisitos do

software

4 - reviso
13

Atividade 1 Reconhecimento do Problema

A meta o reconhecimento dos elementos bsicos do problema, conforme percebidos pelo cliente.
Administrador do projeto

clientes

analista

desenvolvedores

Plano de projeto de software

Espec. requisitos de software

prottipo
14

Atividade 2 Avaliao do Problema e Sntese da Soluo

 

Avaliar os problemas na situao atual Principal Foco para o novo sistema: O QUE e no COMO:
- qual o fluxo e o contedo de informao - quais as funes do sistema - quais dados que o sistema produz e consome - qual o comportamento do sistema - qual as caractersticas de interface - quais so as restries do projeto

15

Avaliao do Problema e Sntese da Soluo



Sintetizar uma ou mais solues (dentro

do alcance delineado no Plano de Projeto do Software) O processo de avaliao e sntese continua at que o analista e o cliente concordem que o software pode ser adequadamente especificado.

a maior rea de esforo

16

Modelagem


Durante a atividade de avaliao e sntese devem ser criados modelos do sistema para se compreender melhor o fluxo de dados e de controle, o processamento funcional e a operao comportamental, alm do contedo da informao. O modelo serve como fundamento para o projeto de software e como base para a criao de sua especificao
17

Atividade 3 Especificao de Requisitos

Definio de Especificao: descrio rigorosa e minuciosa das caractersticas que um material, uma obra ou um servio devero apresentar descrio do fluxo e estrutura da informao refinamento detalhado de todas as funes do software estabelecimento das caractersticas de interface identificao das restries de projeto especificao dos critrios de validao
18

Atividade 4 Revises
Devem ser efetuadas revises tcnicas e revises no Plano de Projeto de Software as revises so conduzidas pelo Cliente e pelo Desenvolvedor a base para a reviso so os documentos produzidos na Especificao dos Requisitos O Plano de Projeto do Software deve ser revisto devido ao conhecimento adquirido durante a anlise.
19

Engenheiro de Sistemas Projetista de sistemas-chefe Programador/Analista

Caractersticas do Analista de Sistemas

- Capacidade para compreender conceitos abstratos, reorganizar esses conceitos em divises lgicas e sintetizar "solues" baseado em cada diviso. 2- Capacidade de absorver fatos pertinentes a partir de fontes conflitantes ou confusas. 4- Capacidade de se comunicar bem de forma escrita e verbal. 5- Capacidade de "ver a floresta ao invs das (no se perder nos detalhes) rvores
21

Papel do Analista de Sistemas

1- Coordenar cada uma das atividades da Anlise de Requisitos de Software - comunicao com cliente - convoca pessoal de desenvolvimento durante avaliao e sntese 2- Responsvel pelo desenvolvimento do documento de Especificao de Requisitos do Software e participa de todas as revises

22

reas Problemas
1. Aquisio da Informao 2. Tamanho do Sistema
(complexidade dos problemas)

3. Alteraes
(mudanas que ocorrem durante e aps a anlise)

23

reas Problemas
1. Aquisio da informao
que informao deve ser coletada e como ela deve ser representada? quem fornece as informaes? que tcnicas e ferramentas esto disponveis para facilitar a coleta de informaes?

24

reas Problemas
2. Tamanho do sistema
como eliminar inconsistncias na especificao de grandes sistemas? possvel detectar omisses? pode um grande sistema ser efetivamente particionado para que se torne intelectualmente administrvel?

25

reas Problemas
3. Alteraes
como as alteraes efetuadas em outros elementos do software so coordenadas com os requisitos do software? como se determina o impacto de uma alterao em outras partes do software aparentemente no relacionadas? como se corrige erros na especificao para que no se gere efeitos colaterias?
26

Causas dos Problemas

comunicao ineficiente tcnicas e ferramentas inadequadas
(especificao inadequada e imprecisa)

tendncias de se eliminar a tarefa de Especificao dos Requisitos falhas ao considerar alternativas antes que o software seja especificado

27

Abordagem de Engenharia de Software



 

Aplicao de tcnicas de comunicao slidas Princpios de anlise fundamentais Mtodos de anlise sistemticos reduziro o impacto dos problemas

28

Responde ao pedido de ajuda do cliente

Problema cuja soluo baseada em computador

29

Princpios Fundamentais de Anlise



domnio de informao do problema p

representado e compreendido (para que a funo possa ser entendida + completamente)

modelos que descrevam a informao, a funo e o comportamento do sistema p

desenvolvidos (para que a informao possa ser comunicada compactamente)
30

Princpios de Anlise


modelos (e o problema) p particionados, de maneira que revele os detalhes em forma de camadas (ou hierarquicamente) (para reduzir a complexidade) processo de anlise p mover-se da informao essencial para os detalhes de implementao (para acomodar as restries lgicas impostas por requisitos de processamento e as restries fsicas impostas por outros elementos do sistema) = (Concepes lgicas e fsicas)
31

1r princpio:

Domnio da Informao
Todo software construdo para processar dados e eventos. Dados: software embutido de tempo real para controlar
o fluxo de combustvel no motor de automvel

Eventos: um sensor de presso detecta que a presso

ultrapassa determinado valor de segurana e envia um sinal de alarme para o software de monitorao

32

Domnio da Informao
1r princpio:
Os dados e itens de controle residem no domnio de informao de um problema. Encerra 3 diferentes pontos de vista:

33

1r princpio: Domnio da Informao

Fluxo da Informao maneira pela qual os Informao:
dados e o controle se modificam medida que cada um se movimenta pelo sistema

Contedo da Informao os dados e os Informao:

itens de controle individuais que compreendem certo item de informao mais amplo.
- o contedo do item de dados cheque de pagamento definido pelos itens que so necessrios para cri-lo: nome do recebedor, quantidade lquida a ser paga, pagamento bruto, etc.

Estrutura da Informao a organizao Informao:

interna de vrios itens de controle e de dados
34

2. princpio:

Modelagem
 

Modelos: melhor compreenso da entidade real a ser construda Entidade fsica (prdio): modelo idntico, mas em escala menor Entidade software:
o modelo deve ser capaz de modelar a informao que o software transforma as funes (ou subfunes) que possibilitam que as transformaes ocorram o comportamento do sistema quando a transformao est se desenvolvendo.

35

2. princpio:

Modelagem
Os modelos concentram-se naquilo que o sistema deve fazer, no em como ele faz.
 

Modelos fazem uso de notao grfica e textual Os mtodos de anlise discutidos nos captulos seguintes so mtodos de modelagem Atividade de Modelagem fundamental ao bom trabalho da anlise 36

2. princpio:

Modelagem
Papis importantes do Modelo: 1) ajuda o analista a entender a informao, a funo e o comportamento de um sistema, tornando a tarefa + fcil e sistemtica. 2) torna-se o ponto focal para a reviso e, portanto, a chave para a determinao da completitude, consistncia e preciso da especificao. 3) torna-se a base para o projeto, fornecendo ao projeto projetista uma representao essencial do software, a qual pode ser "mapeada" num 37 contexto de implementao.

3. princpio:

Particionamento (decomposio)
Os problemas freqentemente so grandes demais e muito complexos para serem compreendidos como um todo. O particionamento divide o problema em partes mais facilmente entendidas Atravs das interfaces estabelecidas entre as partes a funo global do software pode ser executada.

38

3r princpio: Particionamento Particionamento Horizontal: decomposio funcional do problema Particionamento Vertical: expe detalhes crescentes
Particionamento horizontal

39

4r princpio: Concepes essenciais e de implementao

A concepo essencial dos requisitos do software apresenta as funes a serem realizadas sem tratar dos detalhes de implementao. Ao se concentrar ateno na essncia do problema nas primeiras etapas da anlise de requisitos, deixa-se as opes abertas para especificar detalhes de implementao durante as ltimas etapas de especificao dos requisitos e projeto de software.

40

4r princpio: Concepes essenciais e de implementao

A concepo de implementao dos requisitos de software apresenta a manifestao das funes de processamento e estruturas de informao no mundo real. No deve ser interpretada como uma representao do como. Um modelo de implementao representa o modo de operao corrente, ou seja a atribuio existente ou proposta para todos os elementos do sistema.
41

Especificao de Requisitos de Software



Desenvolvida como uma conseqncia da fase de anlise de requisitos Serve como um padro para testar se as fases de projeto e implementao do processo de desenvolvimento de software esto corretas

42

Princpios de uma boa especificao

(Balzer e Goldman)
1. Separe funcionalidade de implementao 2. necessria uma linguagem de especificao de sistemas orientada ao processo 3. A especificao deve abranger o sistema do qual o software um componente 4. Uma especificao deve abranger o ambiente no qual o sistema opera 5. Uma especificao de sistema deve ser um modelo cognitivo 6. Uma especificao deve ser operacional 7. A especificao do sistema deve ser tolerante com a no completitude e ser expansvel 8. Uma especificao deve ser localizada e fracamente acoplada.
43

A Especificao pode ser acompanhada de um PROTTIPO executvel (ou em papel) e/ou um MANUAL PRELIMINAR DE USURIO.

44

Reviso da Especificao
(nvel macroscpico)
Os revisores tentam garantir que a especificao seja completa, consistente e precisa. Questes:
Metas e objetivos do software permanecem consistentes com metas e objetivos do sistema? Foram descritas as interfaces importantes para todos os elementos do sistema? O fluxo e a estrutura de informao so adequadamente definidas para o domnio da informao? Os diagramas so claros?

45

Reviso da Especificao
(nvel macroscpico)
As funes importantes permanecem dentro do escopo e cada uma foi adequadamente descrita? O comportamento do software consistente com a informao que ele deve processar e as funes que deve executar? As restries de projeto so realsticas? Qual o risco tecnolgico desenvolvimento? Requisitos de software alternativos foram considerados? Critrios de Validao foram declarados detalhadamente? Eles so adequados para descrever um sistema bem sucedido? Existem inconsistncias, omisses ou redundncias? O usurio revisou o Manual Preliminar ou o prottipo? Como as estimativas do Plano de projeto de Software foram afetadas?
46

Reviso da Especificao
(nvel detalhado)
A preocupao com o enunciado da especificao. Tenta-se descobrir problemas que possam estar ocultos no contedo da especificao Diretrizes: Esteja alerta para perceber conectivos persuasivos (certamente, claramente, obviamente ) e perguntar por que eles esto presentes. Procure termos vagos e pea esclarecimento (algum, s vezes, usualmente, freqentemente) Quando forem fornecidas listas que no sejam completas, certifique-se de que todos os itens sejam entendidos (evite 47 colocar etc, tal como, assim por diante)

Reviso da Especificao
(nvel detalhado)
Esteja certo de que os limites declarados no contenham pressuposies no declaradas (os cdigos vlidos variam de 0 a 100 - nmeros inteiros, reais???) Cuidado com verbos vagos. H muitas maneiras de interpret-los. (manuseado, rejeitado, pulado, processado) Cuidado com pronomes "pendentes (o mdulo I/O comunica-se com o mdulo de validao de dados e seu sinal de controle est ligado. Sinal de controle de qual?). Procure declaraes que impliquem certeza (sempre, cada, todos, nunca) e depois pea prova
48

Reviso da Especificao
(nvel detalhado)
Quando um termo for explicitamente definido num lugar, evite utilizar outras definies para o mesmo termo (normalizao dos termos: documento - arquivo) Quando uma estrutura for descrita em palavras, verifique se h um grfico ou uma figura para auxiliar a compreenso Quando um clculo for especificado, desenvolva pelo menos dois exemplos.

49

Ferramentas de Especificao Automatizadas

1a categoria: tcnicas automatizadas que nada
mais so do que um mtodo manual que foi complementado com uma ferramenta CASE Possibilitam que o analista atualize informaes e rastreie as conexes entre representaes novas e existentes do sistema

Ex: DEC Design (Digital Equipment Corp.), Design

Aid (Transform Logic Corp.), Excelerator (Intersolv), IEF (Texas Instruments), ADW (Knowledgeware), STP (Interative Development Environments), Teamwork (Cadre Technologies).
50

Ferramentas de Especificao Automatizadas

2a categoria: tcnicas automatizadas que
fazem uso de uma notao especial (na maioria dos casos, essa uma linguagem de especificao de requisitos) que foi explicitamente projetada para processamento usando-se uma ferramenta automatizada.

Ex: SREM (linguagem de especificao: RSL),

PSL/PSA (linguagem de especificao: PSL), TAGS (linguagem de especificao: IORL)
51

Anlise de Requisitos
Concluso


Logo que a Reviso for concluda, a Especificao de Requisitos de Software "assinada" pelo cliente e pelo desenvolvedor A especificao torna-se um "contrato" de desenvolvimento de software. Mudanas solicitadas depois que a Espec. for concluda sero consideradas, porm cada mudana posterior pode aumentar o custo e/ou alongar o prazo de entrega Mesmo com os melhores procedimentos de reviso em andamento, uma srie de problemas de especificao ainda persiste
52