Carlos Eugnio Palma da Purificao

Contedo

Histrico

Problemas

Evoluo

Anlise Estruturada

Anlise Essencial

Anlise Orientada a Objetos
Histrico

Crise do Software 70s

Criao artesanal desenho de telas e arquivos

Problemas de execuo bugs

Prazos, custos e qualidade

Sistemas legados sem documentao

Insatisfao de usurios

Empresas dependentes de software

Proposio da Engenharia de Software 68

Surgimento de Metodologias de Desenvolvimento de
Software

Anlise Estruturada

Anlise Essencial

Anlise Orientada a Objetos
Introduo

Definio de Anlise.

Relacionamento Usurio-Analista.

Problemas da Anlise.
Anlise

Auxilia no entendimento do software

Gesto de complexidade

Diminuio de Custos

Diminuio de Riscos

Melhora de Qualidade

Melhora de Comunicao

Anlise Estruturada estuda as funes focado nos processos.

Diagrama de fluxo de dados.

Dicionrio de Dados.

Especificao lgica dos processos.

Anlise Essencial processos, dados e controle lista de eventos.

Anlise Orientada a Objetos conceitos mais prximos das
abstraes do mundo real.
Anlise Estruturada

Diagrama de Fluxo de Dados

Representa um sistema manual, automtico ou ambos.

Perspectiva de funes com nfase nos processos.

Elementos:

Entidades externas

Depsito de dados

Processo

Fluxo de dados

Diagramas

Diagrama de Contexto

Exploses: Diagrama Zero, Diagramas Extendidos

Especificao lgica do processo.
 Diagrama de Contexto

Anlise Estruturada
Diagrama Zero

1
2

Diagrama 1 Diagrama 2

1.2 2.1

1.1 2.2

Especificao
Processo Processo Processo Processo
da lgica dos
1.1 1.2 2.1 2.2
processos
Anlise Essencial

Adiciona informaes sobre controle baseado em uma lista de eventos externos .

O modelo essencial inicial assume que no existem restries de implementao.

Modelos:

Ambiental fronteira entre o sistema e o ambiente externo.

Diagrama de Contexto

Lista de Eventos

Comportamental comportamento do sistema.

Diagrama de Fluxo de Dados

Dicionrio de Dados

Especificao dos processos

Informao dados que o sistema necessita armazenar ou recuperar.

Diagrama de Entidade e Relacionamento.

Dicionrio de Dados.

Implementao extende o modelo inicial levando em conta a implementao.

Fronteiras da aplicao

Tempo de execuo

Capacidade de armazenamento.

Comunicao.
Anlise Orientada a Objetos

Segundo Yourdon, Um sistema construdo usando um
mtodo Orientado a Objetos aquele cujos
componentes so partes encapsuladas de dados e
funes, que podem herdar atributos e
comportamentos de outros componentes da mesma
natureza, e cujos componentes comunicam-se entre si
por meio de mensagens.
Anlise Orientada a Objetos

Modelagem focada em objetos que simulam entidades do mundo real.

Objetos mantm seu estado e operam sobre tais dados.

Representao do estado privado e no pode ser acessado pelo mundo
exterior.

Design de objetos, seus dados, operaes e relacionamentos.

Usa a Unified Modeling Language para representar o sistema.

Vrios modelos mostrando aspectos diferentes das entidades:

Casos de Uso

Classes e Objetos

Colaborao

Atividades

Estados

Componentes

Execuo

Implantao
Diagramas UML
Requisitos de Software

Summerville:
Processo de estabelecer servios que o cliente requer de um sistema e
as restries sobre as quais o sistema opera e desenvolvido.
Os requisitos, desta forma, so descries dos servios do sistema e
restries que so estabelecidas durante a fase de levantamento dos
requisitos.

Propriedade que deve ser exibida por um software desenvolvido ou
adaptado de forma a resolver um problema do mundo real

Pode expressar uma necessidade ou uma restrio, tipicamente
identificado unicamente, deve ser to claro e sem ambigidade quanto
possvel, deve poder ser verificvel dentro das restries existentes de
recursos.

So tipicamente uma combinao complexa de requisitos de diferentes
pessoas, de diferentes nveis da organizao e do ambiente em que o
software ir operar.
Requisitos de Software

iniciado no comeo do projeto e refinado ao longo do
ciclo de vida.

composto de elicitao, anlise, especificao e validao.

fundamentalmente interdisciplinar.

Recebe informaes de atividades tais como marketing e
estudos de viabilidade.

Necessita ser adaptado para o contexto da organizao e do
projeto.
Requisitos de Software

Varia desde uma sentena de alto nvel sobre o que o
sistema deve fazer at uma especificao matemtica
de uma funcionalidade.

Por exemplo, pode servir a duas funes:

Definio em alto nvel dos servios do sistema para uma
licitao.

Detalhamento do entendimento dos analistas das
funes detalhadas do sistema.
Tipos de Requisitos

Requisitos de usurios

Sentenas em linguagem natural, acompanhadas de diagramas sobre as funes do
sistema e suas restries operacionais. So escritos para o usurio final do sistema.

Requisitos de Sistema

Documento detalhado sobre as funes do sistema, servios e restries
operacionais. Define o que deve ser implementado podendo servir como contrato
entre o contratante e contratado.

Requisitos funcionais

Definies do que o sistema deve fornecer, como o sistema deve reagir a entradas de
dados especficas e como o sistema deve se comportar em situaes especficas.

Requisitos no funcionais

Restries sobre os servios ou funes oferecidas pelo sistema como tempo de
resposta, ambiente, processo de desenvolvimento de software a ser seguido, padres
de documentao e outros.

Requisitos de domnio

Requisitos que vem do domnio da aplicao e que refletem as caractersticas destes
domnios.
Tipod de Requisitos
Requisitos Funcionais

Descreve uma funcionalidade ou servio do sistema.

Depende do tipo de software, usurios finais e ambiente onde utilizado.

Requisitos funcionais do usurio podem ser definies de alto nvel sobre o que
o sistema deve fazer, mas requisitos funcionais do sistema devem descrever os
servios em detalhes.

Exemplos:

O usurio deve poder procurar em todas as bases de dados disponveis ou
escolher algum grupo dentre elas.

A aplicao deve prover interfaces apropriadas para o usurio poder ler
documentos armazenados no repositrio de documentos.

Toda ordem de compra deve ter um identificador nico que pode ser utilizado
pelo usurio para copiar o local de armazenamento da conta.
Problemas nos Requisitos

Geralmente problemas acontecem quando os requisitos no so
suficientemente precisos.

Requisitos ambguos podem ser interpretados diferentemente pelo usurio e
desenvolvedor.

Por exemplo, o termo visualizador apropriado pode ser interpretado:

Pelo usurio visualizador especial para cada tipo de documento.

Pelo desenvolvedor visualizador de texto para mostrar o contedo do
documento.

Os requisitos devem ser completos e consistentes.

Exemplo:

Completo: Deve incluir descries de todos os recursos necessrios

Consistente: No deve haver conflitos nas descries dos recursos do sistema

Na prtica, praticamente impossvel produzir documentos totalmente
completos e consistentes.
Problemas nos Requisitos
Requisitos no funcionais

Definem propriedades ou restries do sistema, como por exemplo,
segurana, tempo de resposta e requisitos de armazenamento.

Podem incluir utilizao de ferramentas especficas, linguagem de
programao ou metodologia de desenvolvimento.

Podem ser mais crticos do que requisitos funcionais. Por vezes, se no
forem atendidos o sistema se torna intil.

Classificao:

Requisitos de produto especificam que o produto produzido deve se comportar de
uma maneira particular, por exemplo, velocidade de execuo, resistncia a falhas,
etc.

Requisitos organizacionais so consequncia de polticas organizacionais, por
exemplo, padres de documentos e processos, requisitos de implementao, padres
de cdigo e nomenclatura, etc.

Requisitos exeternos aqueles que surgem de fatores que so externos ao sistema e
ao seu processo de desenvolvimento, por exemplo, requisitos de interoperabilidade
com outros aplicativos ou ambientes, requisitos legais, etc.
Tipos de Requisitos no
Funcionais
Problemas com objetividade

Requisitos no funcionais podem ser muito difceis de
definir precisamente e definies imprecisas de requisitos
podem ser difceis de verificar. Por exemplo:

Um desejo vago do usurio: Facilidade de uso.

Requisito no funcional verificvel

Utiliza alguma forma de medio em que o requisito pode ser objetivamente
mensurado e testado, por exemplo, mximo de 10 segundos de resposta para cada
tela.

Conflitos entre requisitos no funcionais so comuns
em sistemas complexos.
Requisitos - Processo

Papel chave em termos do custo e tempo de um
produto de software

Suporte e Gerncia do Processo

Recursos

Treinamentos

Ferramentas

Qualidade e Melhoria do Processo

Padres e modelos de melhoria

Medies e benchmarking

Planejamento e implementao de melhorias
Requisitos - Elicitao

Trata da origem dos requisitos e de como os engenheiros de software podem colet-los

Identificao dos stakeholders

Estabelecimento do relacionamento entre equipe de

desenvolvimento e cliente

Fontes:

Objetivos gerais e de alto nvel do software

Conhecimento do domnio

Stakeholders

Ambiente Operacional

Ambiente Organizacional

Tcnicas:

Entrevistas

Cenrios

Prottipos

Encontros Facilitados

Observao
Requisitos de Software -
Anlise

Trata da deteco e resoluo de conflitos entre requisitos, definio da fronteira e da interao com o
ambiente, elaborao dos requisitos do sistema para derivar requisitos do software

Classificao dos requisitos

Classificaes j apresentadas

Prioridade

Escopo

Estabilidade

Negociao dos requisitos

Consenso

Rastreabilidade

Modelagem Conceitual

Fluxos de Dados e Controle

Dados

Estados

Interaes com usurio

Objetos

Fatores que influenciam a escolha do modelo:

Natureza do problema

Conhecimento do engenheiro de software

O processo de requisitos do cliente

Disponibilidade de mtodos e ferramentas
Requisitos de Domnio

Derivados do domnio da aplicao e descreve as caractersticas do sistema e caractersticas que
refletem o domnio.

So novos requisitos funcionais que restrigem requisitos funcionais j definidos ou especificam
computaes especficas.

Se requisitos de domnio no forem satisfeitos o sistema pode ser tornar inutilizvel.

Exemplos:

Deve existir uma interface entre todos os bancos baseado no padro X.

Por causa de restries legais os documentos devem ser deletados imediatamente depois que forem
analisados pelo sistema.

Problemas:

Entendimento

Geralmente so especificados na linguagem do domnio da aplicao.

Possivelmente no vai ser entendido por analistas do sistema sem prvio treinamento no domnio da
aplicao.

Elucidao

Os usurios atuantes no negcio entendem to bem o requisito que no sentem necessidade de maiores
explicaes.
Requisitos do Usurio

Devem descrever aspectos funcionais e no funcionais de uma maneira
que eles sejam entendidos pelos usurios do sistema que no possuem
conhecimento tcnico especfico.

Requisitos do usurio so definidos utilizando linguagem natural,
tabelas e diagramas j que estes podem ser facilmente entendidos por
todos os usurios.

Problemas da linguagem natural:

Falta de clareza difcil atingir um alto grau de preciso sem tornar o
documento de difcil leitura.

Mistura de requisitos requisitos funcionais e no funcionais tendem a
ser misturados.

Condensao de requisitos muitos requisitos diferentes tendem a ser
colocados sobre a mesma definio.
Alternativas da LN
Notation Description
Structured natural This approach depends on defining standard forms or templates to express the
language requirements specification.
Design This approach uses a language like a programming language but with more abstract
description features to specify the requirements by defining an operational model of the system.
languages This approach is not now widely used although it can be useful for interface
specifications.
Graphical A graphical language, supplemented by text annotations is used to define the
notations functional requirements for the system. An early example of such a graphical
language was SADT. Now, use-case descriptions and sequence d iagrams are
commonly used .
Mathematical These are notations based on mathematical concep ts such as finite-state machines or
specifications sets. These unambiguous specifications reduce the arguments between customer and
contractor about system functionality. However, most customers dont understand
formal specifications and are reluctant to accept it as a system contract.
Baseado em Formulrio
Insulin Pump/Control Software/SRS/3.3.2
Function Compute insulin dose: Safe sugar level
Description Computes the dose of insulin to be delivered when the current measured sugar level is in
the safe zone between 3 and 7 units.
Inputs Current sugar reading (r2), the previous two readings (r0 and r1)
Source Current sugar reading from sensor. Other readings from memory.
Outputs CompDose the dose in insulin to be delivered
Destination Main control loop
Action: CompDose is zero if the sugar level is stable or falling or if the level is increasing but the rate of
increase is decreasing. If the level is increasing and the rate of increase is increasing, then CompDose is
computed by dividing the difference between the current sugar level and the previous level by 4 and
rounding the result. If the result, is rounded to zero then CompDose is set to the minimum dose that can
be delivered.
Requires Two previous readings so that the rate of change of sugar level can be computed.
Pre-condition The insulin reservoir contains at least the maximum allowed single dose of insulin..
Post-condition r0 is replaced by r1 then r1 is replaced by r2
Side-effects None
Tabular
Condition Action
Sugar level falling (r2 < r1) CompDose = 0
Sugar level stable (r2 = r1) CompDose = 0
Sugar level increasing and rate of CompDose = 0
increase decreasing ((r2-r1)<(r1-r0))
Sugar level increasing and rate of CompDose = round ((r2-r1)/4)
increase stable or increasing. ((r2-r1) If rounded result = 0 then
(r1-r0)) CompDose = MinimumDose
Sequncia
Especificao de Interface
interface PrintServer {

// defines an abstract printer server

// requires: interface Printer, interface PrintDoc
// provides: initialize, print, displayPrintQueue, cancelPrintJob, switchPrinter

void initialize ( Printer p ) ;

void print ( Printer p, PrintDoc d ) ;
void displayPrintQueue ( Printer p ) ;
void cancelPrintJob (Printer p, PrintDoc d) ;
void switchPrinter (Printer p1, Printer p2, PrintDoc d) ;
} //PrintServer
Boas prticas

Defina um formato padro e utilize-o para todos os
requisitos.

Use a linguagem de uma forma conviniente e correta.

Use a ferramenta de marcao de texto para identificar
partes importantes dos requisitos. Cuidado para no
exagerar.

Tente no utilizar jarges da rea de computao.
Conceitos Chave

Requisitos definem o que o sistema deve fazer e restries em sua operao e
implementao.

Requisitos funcionais so servios que o sistema deve prover.

Requisitos no funcionais so restries ao sistema que est sendo
desenvolvido ou ao seu processo de desenvolvimento.

Requisitos de usurio so definies de alto nvel sobre o que o sistema deve
fazer. Devem ser escritos utilizando linguagem natural, tabelas e diagramas.

Requisitos de sistema so destinados a comunicar as funes que o sistema deve
prover.

O documento de requisitos de software um acordo sobre os requisitos do
sistema.

O padro IEEE til como um modelo inicial para definio de padres mais
especficos de documentos de requisitos de sistema.