Análise de Sistemas

Anlise de Sistemas
Alessandra Casses Zoucas
Florianpolis
2010
Z91a
Zoucas, Alessandra Casses

Anlise de Sistemas / Alessandra Casses Zoucas.
Florianpolis : Publicaes do IF-SC, 2010.
74 p.
Inclui Bibliografia.
1. Anlise de sistemas. 2. Diagrama de casos de uso. 3.
Diagrama de sequncia. 4. Diagrama de Fluxo de Dados. 5.
Ciclo de vida. II. Ttulo.
CDD: 001.61
Catalogado por: Augiza Karla Boso CRB 14/1092

Rose Mari Lobo Goulart CBR 14/277
Organizao de contedo:
Andrino Fernandes
Elaine Luz Barth
Comisso Editorial:
Hamilcar Boing
Andrino Fernandes
Elaine Luz Barth
Produo e design instrucional:

Andrino Fernandes
Elaine Luz Barth
Projeto grfico:
Paulo Ricardo Rodrigues de Lima
Capa:
Lucio Baggio
Reviso ortogrfica:
Marcos Pessoa
Editorao Eletrnica:
Hudson Ricardo Borges
Sumrio
Captulo 1 - Introduo a Anlise de Sistemas
1.1Conceitos Bsicos...........................................................................................................11
1.2 Linha do Tempo............................................................................................................12
1.3.1 Anlise Estruturada...................................................................................................14
1.4 Revendo a histria........................................................................................................15
1.5 Anlise Essencial...........................................................................................................16
1.6 Anlise Orientada a objeto............................................................................................18
1.6.1 Abstrao de Dados:..................................................................................................19
1.6.2 Atributos:....................................................................................................................19
1.6.3 Relacionamentos:.......................................................................................................20
1.7 Problema X Soluo......................................................................................................21
Captulo 2 - Levantamento de Requisitos

2.1 Requisitos Funcionais....................................................................................................27
2.3 Rastreabilidade..............................................................................................................29
2.4 Processo de Engenharia de Requisitos...........................................................................30
2.5 Tcnicas para Levantamento de requisitos....................................................................31
2.7 Gerncia de Requisitos..................................................................................................33
2.8 Quais so as pricipais atividades da Gerncia de Requisitos? .......................................34
2.9 Regra de Negcio (RNE) ..............................................................................................34
Captulo 3 - Diagrama de casos de uso

3.1 Sistema.........................................................................................................................3 8
3.2 Ator...............................................................................................................................3 8
3.3 Casos de uso.................................................................................................................39
3.4 Documentao de casos de uso.....................................................................................4 0
3.6 Relacionamentos..........................................................................................................43
Captulo 4 - Diagrama de Sequncia

4.1 Alguns elementos de um diagrama de sequncia...........................................................50
4.2 Diagrama de Classe.......................................................................................................51
4.3 Exerccios de Aprendizagem..........................................................................................52
Captulo 5 - Diagrama de Fluxo de Dados - DFD

5.1 Como elaborar um DFD................................................................................................56
5.2 Nveis do DFD...............................................................................................................58
5.3 Vantagem do uso de DFDs em nveis ........................................................................5 9
5.4 Exerccios de aprendizagem...........................................................................................60
Captulo 6 - Ciclo de Vida

6.2 Os componentes do desenvolvimento de um ciclo de vida............................................64
6.3 Modelos de ciclo de vida...............................................................................................64
6.3.1 MODELO SEQUENCIAL.....................................................................................64
6.3.2 MODELO CASCATA............................................................................................64
6.3.2 MODELO V..........................................................................................................6 6
6.3.4 MODELOS INCREMENTAIS................................................................................66
6.3.5 RUP (Rational Unified Process)............................................................................67
6.3.6 MODELO EVOLUTIVO 71
Apresentao
Caro estudante,
Voc j pensou que um dos fatores de sucesso na construo de um software tem relao direta
com a comunicao entre o fornecedor do sistema e os seus clientes?
Sabe por que isso acontece? Porque o fornecedor do sistema deve procurar compreender os
problemas do seu cliente para propor solues de software que se aproximem das expectativas
destes clientes. Para isto, necessrio que se obtenha e se documente informaes sempre coletadas junto ao cliente. Elas servem de suporte na construo do software que deve estar alinhado
a essas expectativas.
Existem outros fatores importantes. Por exemplo, o sucesso de um software tem relao direta
com a comunicao do fornecedor do sistema e sua equipe de desenvolvimento de software. Isto
acontece por que o fornecedor do sistema deve procurar transmitir claramente para sua equipe
de desenvolvimento de software as caractersticas da soluo proposta e aprovada pelo cliente.
Assim, ele poder ter uma garantia inicial de que o software que ser construdo atender s
expectativas do seu cliente.
Entretanto, as coisas no so to simples como podem parecer. Estabelecer estas comunicaes
de forma eficiente no uma tarefa fcil. Tipicamente, pode ocorrer rudo nesta comunicao, e
isto pode acarretar na construo de um software com problemas do ponto de vista do usurio.
Sendo assim, nesta disciplina voc estudar os elementos que auxiliam na gerao de uma
comunicao eficiente (com a menor interferncia de rudos possvel) visando sempre a garantia
de que o produto criado atender as expectativas do cliente. Para atingir este objetivo iremos
estudar tcnicas de levantamento e documentao das necessidades dos nossos clientes, tanto
do ponto de vista do usurio quanto do ponto de vista do desenvolvedor de software.
Seja bem-vindo(a) a disciplina Anlise de sistemas. um prazer acompanh-lo (a) em mais uma
jornada no mundo virtual. Realize todas as atividades recomendadas e planeje os seus estudos.
Sucesso e boas aulas!
Um abrao,
Profa. Alessandra Zoucas
CAPTULO
1
Introduo a Anlise de Sistemas
Objetivo
Apresentar alguns conceitos bsicos que
esto relacionados anlise de sistemas.
Verificar as principais metodologias de desenvolvimento. Estudar a diferena entre
domnio do problema e soluo.

A seguir so apresentados conceitos que esto presentes no contedo desta apostila. Logo, para maior aproveitamento da leitura importante que o leitor saiba onde encontrar as definies
apropriadas para os conceitos tratados neste material de modo a
familiarizar-se com eles.
1.1Conceitos Bsicos
Anlise: derivado do grego analein - desatar, soltar, significa
dissoluo de um conjunto em suas partes. Em sentido amplo,
empregam-se os termos anlise e analisar como sinnimo
de exame e examinar, pesquisa e pesquisar, verificao e verificar [1].
Anlise de Sistemas: representa o estudo detalhado de uma

rea de trabalho (processo), que antecede uma ao que, quase
sempre, implica no desenvolvimento de um conjunto de programas integrados (sistemas) destinados execuo, controle
acompanhamento do processo [1].
Analista de Sistemas: o profissional que atua na rea de desenvolvimento, manuteno e produo de sistemas e na customizao de sistemas.
Caractersticas (Features): permite definir um escopo mais refinado do trabalho a ser feito. uma abstrao intermediria
entre as necessidades dos stakeholders e os requisitos do sistema
[12].
Necessidades: est ligada diretamente com o real problema

de negcio que ser resolvido, ou seja, o objetivo resolver o
problema. Deve orientar todo o processo de identificao de
requisitos [12].
Processo: conjunto de atividades inter-relacionadas, que transforma entradas em sadas (ABNT, 1998).
Produto de Software: a entidade de software disponvel para

liberao do usurio [12].
Qualidade de Software: a totalidade das caractersticas de

um produto de software que lhe concede a capacidade de satis-
11
Anlise de Sistemas
fazer s necessidades explcitas e implcitas, ou seja, a capacidade em
atender aos requisitos [12].
Sistema: conjunto de elementos (subsistemas) independentes entre si,

com vistas a atingir um objetivo [1].
1.2 Linha do Tempo

Inicialmente falaremos sobre a linha do tempo relacionada ao desenvolvimento de software [2]:
12
1970 - Crise do Software

Entre outros, foram atribudos como principais fatores dessa crise: o desenvolvimento de softwares de forma artesanal, con-
13
Anlise de Sistemas
tnuos erros de execuo, tempo da coleta de dados, descumprimento

de prazos, problemas relacionados aos custos, inexistncia de documentao ou elegibilidade da mesma, falta de comunicao durante
do desenvolvimento do software, falta de testes e a insatisfao dos
usurios [2].
1.3 Metodologias de desenvolvimento de Softwares

A partir de 1970 surgiram metodologias para o desenvolvimento de
Softwares identificadas como: Anlise Estruturada, Anlise Essencial,
e Anlise Orientada a Objetos.
1.3.1 Anlise Estruturada

Esta anlise utilizada para auxiliar
na comunicao entre as pessoas envolvidas no processo de desenvolvimento do software, assim como no
gerenciamento da complexidade, entendimento do problema e na reduo dos custos [2].
A metodologia de Anlise Estruturada
baseada na decomposio funcional e na utilizao de diagramas de
fluxos de dados (DFD). Suas principais fases so [3]:
Figura 1. Fonte: http://www.zsc.com.br/images/ANALISAR.gif
Fase 1- Estudo Inicial

O ponto inicial desta metodologia dado pelo esforo de garantir que
os sistemas escolhidos para serem desenvolvidos so aqueles que se
garantem em ambientes competitivos. A relao custo benefcio (do
ponto de vista financeiro) considerada como o critrio mais importante no processo de seleo, quando ento, os sistemas so apontados como responsveis pela contribuio crescente do faturamento,
crescentes custos ou a melhoria dos servios oferecidos [3].
14

Fase 2 Estudo Detalhado
Nesta fase procura-se entender o sistema de forma detalhada e
o usurio pode participar de forma informal para sanar algumas
dvidas que o analista do sistema possa ter sobre o processo [3].
Neste estudo detalhado os seguintes elementos devero estar
presentes [3]:
A definio dos usurios do novo sistema, com suas responsabilidades e funes.
Um modelo lgico do sistema atual que um diagrama de
fluxo de dados geral, os sistemas de interfaces e um DFD
detalhado de cada processo considerado importante.
Uma declarao com os ganhos que so esperados com o
sistema;
Um oramento dos gastos necessrios para finalizao das
prximas fases.

Fase 3 Definio e Projeto de Solues Alternativas

Nesta fase busca-se definir as solues para os problemas do
sistema atual. Os objetivos da organizao, definidos da fase inicial, so convertidos em um conjunto de objetivos do sistema
[3].
Fase 4 Projeto Fsico

O grupo do projeto refina a alternativa escolhida em um projeto
fsico especfico que envolver o detalhamento do DFD, projeto
do banco de dados e a racionalizao e normalizao [3].
1.4 Revendo a histria

No final da dcada de 60,
com a introduo da programao estruturada, apareceram as tcnicas estruturadas. Foi na dcada de 70
que Steven Myers e Constantine propuseram os conceitos de projeto estruturado.
Figura 2. Fonte: http://www.exkola.com.br/site/files/carreira/carreira-818.jpg
15
Anlise de Sistemas
Neste sentido buscou-se aplicar os conceitos de projeto estruturado

anlise de sistemas com o intuito de desenvolver um mtodo de especificao de requisitos adequado ao projeto estruturado [3].
Em 1979, Gane e Sarson, descrevem em seu trabalho a metodologia
de desenvolvimento de sistemas denominada STRADIS (Structured
Analysis, Design and Implementation of Information Systems) que incorpora a anlise, projeto e implementao estruturada de sistemas de
informao.
Gane e Sarson salientam em seu trabalho que para completar o desenvolvimento do sistema necessrio definir um planejamento que
contenha os planos de testes e aceitabilidade do sistema [3].
De modo geral, na Anlise Estruturada so enfatizadas as funes do
sistema e os processos. Ela no modela o comportamento temporal,
bem como os relacionamentos complexos de dados. Nesta anlise so
utilizadas as seguintes ferramentas [2]:
Diagrama de Fluxo de Dados;
Dicionrio de Dados
Especificao da Lgica de Processos.
1.5 Anlise Essencial

A Anlise Essencial considerada uma evoluo da Anlise Estrutura
em funo de preocupar-se com o controle e utilizar ferramentas para
representao dos requisitos do sistema.
Na etapa de anlise procura-se detalhar o propsito do sistema (definio do problema) e identificar os requisitos do software. Onde os
requisitos correspondem ao conjunto de caractersticas que o sistema
deve possuir para alcanar o propsito do sistema [5].
No decorrer do processo de anlise, o analista precisa encarar a complexidade das situaes reais, entend-las e represent-las de uma forma simplificada que permita a compreenso do sistema que ser desenvolvido. Para tal, necessrio limitar o escopo, subdividindo o todo
complexo em partes simples e gerenciveis, obtendo as caractersticas
essenciais da realidade e modelar o relacionamento destas caractersticas criando um modelo [5].
16

O modelo uma representao da abstrao da realidade, ou
seja, ele representa o conjunto de caractersticas de uma situao
real. Os modelos possuem nveis de abstrao que representam
o grau de detalhes das caractersticas do sistema.
De um modo geral, os sistemas de informao so considerados
em trs nveis [5]:
Conceitual: as caractersticas do sistema so consideradas
independentes do ambiente computacional (hardware e software) onde o sistema ser implementado.
Lgico: as caractersticas so consideradas como dependentes de um dado tipo de sistema computacional e independentes dos produtos.
Fsico: as caractersticas so consideradas como dependentes de um dado sistema computacional, ou seja, dependem
da linguagem de programao, do compilador, do sistema
gerenciador de banco de dados etc.
Nas etapas iniciais do processo de desenvolvimento, o analista
de sistemas representa o sistema atravs de modelos conceituais.
Em seguida, as caractersticas lgicas e fsicas so representadas
por outros modelos.
O mtodo de Anlise Essencial de Sistemas indica que um sistema deve ser modelado por meio de trs dimenses [5]:
Dados: refere-se aos aspectos estticos e estruturais do sistema;
Controle: considera os aspectos temporais e comportamentais do sistema; e
Funes: considera a transformao de valores.
A Anlise Essencial considera dois nveis relacionados ao grau
de abstrao, so eles [5]:
Modelo Essencial: representa o sistema em um grau de
abstrao totalmente independente das restries de tecnologias; e
Modelo de Implementao: leva em considerao as restries tecnolgicas relacionadas ao hardware e software
que sero utilizados na implementao (desenvolvimento)
do sistema.
17
Anlise de Sistemas
De um modo geral a Anlise Essencial foi considerada uma evoluo
da Anlise Estruturada de Sistemas. No entanto, a Anlise Essencial
procurou determinar um novo ponto de partida para a especificao
de um sistema: a identificao dos eventos que o afetam. Passando a
abranger tambm o levantamento de requisitos, uma vez que a anlise
estruturada focava somente na anlise de requisitos [5].
A anlise essencial depurava os sistemas em subsistemas para tornlos mais leves e operacionais, percebendo-se ento a proximidade
entre funes e dados, pois cada subsistema era provido de dados
atravs de banco de dados particionado e conhecido como memria
essencial. Pode-se dizer que esta metodologia foi o limite para o estudo
mais slido dos mtodos orientados a objetos [6].
1.6 Anlise Orientada a objeto

A Anlise Orientada ao Objeto tem como caracterstica a intercalao
de mtodos e atributos em um nico plano, na especificao de encapsulamento, o banco de dados orientado ao objeto visto como
um modelo de dados munido de inteligncia.
Para entendermos melhor o conceito da anlise orientada a objetos
utilizaremos o exemplo do corpo humano. A menor unidade do nosso corpo a clula, ela possui mtodos e funes integradas [6]. No
entanto, no temos apenas uma, mas um conjunto de clulas que formam os tecidos e respectivamente um rgo, e os rgos formam sistemas (Digestivo, Nervoso, etc ...). Em uma viso geral, o conjunto de
todos esses sistemas forma o nosso corpo.
Sendo assim, analogamente definimos: a) clula como Objeto, b) rgo como Classe, c) Sistema como pacote e d) nosso corpo como um
componente [6].
Por meio destas relaes temos a capacidade de nos comunicarmos
com as pessoas, e do ponto de vista da orientao ao objeto, podemos concluir que os componentes devem ser compatveis entre si e
para interpretar a comunicao existem ferramentas que suportam as
linguagens unificadas de modelagem, como a UML (Unified Modeling
Language) [6].
As caractersticas fundamentais de uma metodologia orientada a objetos so: abstrao de dados, atributos e relacionamentos.
18
1.6.1 Abstrao de Dados:

Ao invs de decompor em funes e procedimentos, caractersticas predominantes das tcnicas estruturadas, a metodologia
orientada a objetos refora a abstrao. A abstrao dos dados
inclui o conceito de superclasse e subclasse [3].
A partir da abstrao surge o conceito de objeto, que uma
abstrao de um conjunto de coisas do mundo real, de tal forma
que [3]: a) todas as coisas do mundo real do conjunto devem ter
as mesmas caractersticas; b) todas as instncias esto sujeitas (e
conforme) as mesmas normas.
Todo objeto tem uma descrio que uma declarao formal
que permite afirmar se um dado elemento do mundo real ou
no uma instncia do objeto [3].
Os objetos podem se enquadrar em cincos categorias, so elas
[3]:
Tangveis (exemplos: carro, casa, computador, etc.);
Funes (exemplos: analista de sistemas, advogado, cliente,
etc.);
Interaes (exemplos: venda casamento, ensinamento, etc.);
Incidentes (exemplos: evento, acidente, abrir, etc.);
Especificaes (exemplos: modelo 123, codigo23, etc.);
1.6.2 Atributos:
Um atributo a abstrao de uma nica caracterstica possuda
pelo objeto (entidade) [3], por exemplo, um objeto Livro possui como atributo o ISBN.
Um atributo pode ser classificado como: [3]
Completo: possui todas as informaes pertinentes ao objeto;
Fatorado: Cada atributo deve captar um aspecto separado
da abstrao do objeto;
Mutuamente independente: os atributos possuem valores independentes uns do outros.
A classificao dos atributos dada por elementos [3]:
Descritivos: so as caractersticas so intrnsecas do objeto;
Nominativos: os nomes e rtulos arbitrrios; e
Referenciais: h fatos que ligam uma instncia de um deter-
19
Anlise de Sistemas
minado objeto a instncia de outro objeto.
1.6.3 Relacionamentos:
Eles representam a abstrao do conjunto de associaes existentes no
mundo real. Eles so classificados conforme a sua multiplicidade [3],
em trs tipos, tais como:
1:1 Uma dada instncia de um objeto do tipo X associada a uma,
e somente uma, instncia de um objeto do tipo Y [3].
1:M Um objeto do tipo X associado com um ou mais instncias de
um objeto do tipo Y [3].
M:M Para cada instncia de um objeto do tipo X associada com
uma ou mais instncias de um objeto do tipo Y.
IMPORTANTE LEMBRAR QUE...
A essncia da abordagem orientada a objetos est voltada ao conceito de encapsular os dados e as funes de tal maneira que o
nico meio de obter acesso ou atualizar os dados atravs das
funes associativas [3].
De um modo geral a anlise de sistemas consiste em mtodos e
tcnicas de investigao e especificao da soluo de problemas,
a partir dos requisitos levantados para criao e implementao de
um software [7]. Ou seja, uma atividade cujo objetivo entender
o problema e definir a soluo mais adequada.
Esse processo de anlise no trivial, uma vez que preciso entender o problema de tal forma que o sistema desenvolvido atenda a
necessidade do cliente.
A falta de anlise de sistemas pode comprometer futuras ampliaes no sistema, comprometer a tomada de decises, dificultar a
manuteno, tornar o sistema desconhecido de todos os usurios
fazendo que apenas uma pessoa conhea o sistema entre outros
pontos negativos [7].
Neste sentido percebemos a importncia em estudar a anlise de sistemas e para entendermos melhor sobre este tema falaremos na prxima
seo sobre o problema versus a soluo, uma vez que, o foco da anlise de sistemas gira em torno deles (autora).
20
1.7 Problema X Soluo

O processo de desenvolvimento de
software pode ser dividido, em geral,
em quatro grandes fases: anlise, projeto, implementao (codificao/
programao) e testes [7].
Na fase de anlise destaca-se a investigao do problema, onde o analista
de sistemas precisa identific-lo e entend-lo de maneira eficiente e clara.
Para que se possa definir o problema
Figura 3. Fonte: http://4.
preciso entender a situao atual. O
bp.blogspot.com/_TelWejOUjJ8/
resultado dessa anlise o enunciado
SxE5CLX8y4I/AAAAAAAAALo/oambNw9AffM/s320/
do problema e o projeto consideInterroga%C3%A7%C3%A3o.jpg
rado como a soluo. Sendo que, os
problemas mal elaborados podem, eventualmente, ser resolvidos, no entanto, a soluo no atender expectativa do cliente
[7].
Qual a melhor forma de entender o problema interagindo com
o usurio, questionando o mesmo, criando um canal de comunicao direto com ele, presencial
ou no [6].
muito importante que o processo de anlise tenha qualidade,
Figura 4. Fonte: http://www.rev.vagner- pois a correo dos problemas de
queiroz.nom.br/FigSemAE_NT_D.jpg
entendimento durante essa fase
implica em determinado custo.
Na fase de projeto os custos aumentam. Entretanto, bom destacar que na fase de implementao este cenrio piora, porque
os custos continuam a crescer, e ao final, na fase de implantao
os custos so ainda bem maiores.
Para entender o domnio do problema alguns questionamentos
devem ser feitos, so eles [8]:
Por que necessrio desenvolver um projeto?
Quais so os objetivos de negcio?
O que o cliente precisa resolver?
21
Anlise de Sistemas
O que incomoda o cliente?

Modelar o negcio proporciona uma viso geral do domnio do
problema.
Outro ponto importante! Neste processo necessrio identificar quem
so os usurios do sistema e os representantes dos grupos de usurios,
negociar as responsabilidades de cada representante, definir como
ser a comunicao com os fornecedores e os representantes dos usurios [8].
importante entender quais so as necessidades destes usurios, aquilo que realmente eles precisam para atender o real problema do cliente
[8].
A seguir, alguns exemplos de necessidade que os usurios costumam
descrever:
Eu preciso diminuir o tempo de atendimento do cliente no balco;
Eu necessito que as informaes pessoais do cadastro de clientes
sejam emitidas de forma rpida.
Este tipo de necessidade, descrita em alto nvel, representa o que o
usurio espera que o sistema faa [8].
Para traduzir as necessidades do usurio o analista de sistemas precisa realizar uma boa anlise, sem ter pressa de implementar o sistema.
De nada adianta um sistema ser eficiente, ter uma interface bonita se
no atende as expectativas do cliente.
O conjunto de necessidades que devem ser atendidas denominada
de requisitos do sistema [10].Este tema ser explorado no prximo
captulo.
Atividades de Aprendizagem
1) Com relao s metodologias de desenvolvimento de software, classifique as alternativas abaixo como:
A Anlise Estruturada;
B Anlise Essencial;
C Anlise Orientada a Objetos
( ) uma evoluo da anlise estruturada, ela preocupa-se com o
22

controle e utiliza ferramentas para representar os requisitos, bem
como, a elicitao dos requisitos.
( ) Sua anlise baseia-se na decomposio funcional e na utilizao de diagramas de fluxo de dados.
( ) Sua principal caracterstica a intercalao de mtodos e atributos em um nico plano, na especificao de encapsulamento, onde o banco de dados orientado visto como um modelo
de dados munido de inteligncia.
( ) Foi o limite para os estudos mais slidos dos mtodos orientados a objetos.
( ) Suas principais fases so: estudo inicial; estudo detalhado;
definio e projeto de solues alternativas; e o projeto fsico;
( ) As caractersticas principais deste metodologia abstrao de
dados, atributos e relacionamentos.
( ) Indica que um sistema deve ser modelado em trs (3) dimenses: dados; controle; e funes.
2) A partir da descrio abaixo de uma dada situao, analise a
lacuna da direita e identifique de afirmao pertence ao domnio
do problema ou da soluo.
Situao: Uma clnica mdica contratou a sua empresa para
desenvolver um sistema web para que seus pacientes possam
verificar a disponibilidade de datas e marcar consultas com seu
mdico. Voc foi selecionado como o analista de sistemas deste
projeto. Aps o levantamento inicial de requisitos desse sistema,
e voc obteve as seguintes informaes:
( P ) Domnio do Problema
( ) A secretria verifica na sua
agenda de papel a disponibilidade de data para uma consulta com um determinado
mdico.
( S ) Domnio da Soluo
( ) A secretria marca em sua

agenda de papel a consulta de
um paciente com um determinado mdico
( ) Um paciente entra em contato com a clnica, via telefone, para marcar uma consulta
com um determinado mdico.
23
Anlise de Sistemas
( ) Um paciente entra em contato com a clnica,
via telefone, para identificar quais so os especialidades mdicas que a clnica oferece. (exemplos: Pediatra, Cardiologista, Clnica Geral etc.)
( ) Um paciente deve verificar em um pgina
web a disponibilidade de data para uma consulta
com um determinado mdico.
( ) A secretria pode marcar a consulta para um
paciente acessando o sistema web da clnica.
( ) Um paciente pode marcar sua consulta com
um determinado mdico acessando o sistema
web da clnica.
( ) Um paciente pode acessar o sistema web da
clnica para identificar quais so os especialidades mdicas que a clnica oferece. (exemplos: Pediatra, Cardiologista, Clnica Geral etc.)

24
CAPTULO
2
Levantamento de Requisitos
Objetivo
Neste momento iniciaremos nossos estudos sobre requisitos do sistema. Veremos
formas de levantamento dos requisitos
junto aos clientes e estaremos estudando
tambm os processos de engenharia e gerncia de requisitos.
O levantamento de requisitos, tambm denominado de elicitao de requisitos, refere-se etapa de compreenso do problema voltada ao desenvolvimento do software, isto , sero identificadas as necessidades do usurio para resolver um problema
ou atingir um objeto [11].
Qual o foco desta etapa? alinhar a viso do problema entre
o usurio e os desenvolvedores. neste momento que o analista
de sistemas e o cliente, juntos, tentam levantar e definir as necessidades. Essas necessidades so chamadas de requisitos [11].
O resultado do levantamento de requisitos o documento de
requisitos. Ele contm todos os tipos de requisitos identificados,
normalmente, escritos em linguagem natural.
Os requisitos podem ser classificados como:

Requisito Funcional:

Requisito No-Funcional.
2.1 Requisitos Funcionais

O requisito funcional descreve as funcionalidades do sistema,
isto , ele representa o que o sistema deve fazer.
Exemplos:
Requisito Funcional 01 (REF.01): O sistema deve listar todos
os alunos cadastrados em uma turma.
Requisito Funcional 02 (REF.02): O sistema deve calcular a
mdia dos alunos de uma turma.
Requisito Funcional 03 (REF.03): O sistema deve permitir o
CRUD (Create, Read, Delete, Up date) de alunos.
Requisito Funcional 04 (REF.04): O sistema deve gerar um
relatrio com a mdia dos alunos de uma turma.
No entanto, aps a redao dos requisitos necessrio verificar
se realmente foi entendida a necessidade do cliente, ou seja, a
partir dos requisitos elicitados possvel modelar a soluo para
o problema.
A Tabela 1 apresenta alguns resultados onde, provavelmente,
houve falhas na identificao dos requisitos.
27
Anlise de Sistemas
Tabela 1. Resultado da falha na anlise de requisitos

Fonte: [19]
2.2 Requisitos no-funcionais

Requisitos No Funcionais (RNF) so requisitos que expressam restries que o software deve atender ou qualidades especficas que o
sistema deve possuir. Eles no associados diretamente com as funes
presentes no sistema.
Os requisitos no funcionais podem ser classificados sob os seguintes
aspectos:
Usabilidade;
Desempenho;
Robustez;
Critrios de Segurana;
Portabilidade;
Restries de Hardware e Software;
Questes sobre padronizao e normatizao;
Questes sobre a distribuio e instalao.
Alguns exemplos de RNF:
Requisito No Funcional 01 (RNF.01): O sistema deve emitir o relatrio da mdia dos alunos em 5 segundos (desempenho).
Requisito No Funcional 02 (RNF.02): O sistema deve ser executado no sistema operacional Windows Vista e Linus nas distribuies
Ubuntu e Famelix (restries de software).
Requisito No Funcional 03 (RNF.03): A especificao do servidor
de banco de dados SGBD MySql, com processador Core 2 Duo da
Intel, 4GB de memria RAM ... (restries de harware).
28
Requisito No Funcional 04 (RNF.04): A interface do mdulo
de relatrios deve ser orientada ao uso de atalhos do teclado
(usabilidade).
Requisito No Funcional 05 (RNF.05): O sistema deve estar
em conformidade com a norma XXXX (normatizao).
ATENO: H alguns requisitos que podem ser considerados
como hbridos, ou seja, eles apresentam caractersticas de requisitos funcionais e no funcionais. Um exemplo deste tipo de
requisito seria: O sistema deve emitir uma nota fiscal para um
cliente, em um tempo mximo de 5 segundos [9].
NOTE QUE: No exemplo acima, voc deve observar que alm
do requisito funcional (emitir uma nota fiscal), h tambm um
requisito no funcional, de desempenho, associado.
O que mais importante na elicitao de requisitos: encontr-los
ou classific-los corretamente? Com certeza o mais importante
encontr-los [9].
2.3 Rastreabilidade
Para garantir que todas as caractersticas foram endereadas por
requisitos de software e todas as necessidades foram endereadas por caractersticas tem-se a rastreabilidade que a base para
avaliao de impacto [12].
A Tabela 2 apresenta uma rastreabilidade bidirecional entre as
necessidades de caractersticas.
Caracterstica 1
Caracterstica 2
...
...
Necessidade 1
Necessidade 2
...
...
...
Necessidade N
...
...
...
...
Tabela 2. Rastreabilidade Bidirecional - Fonte: Adaptado de [12]
Requisito 1
Requisito 1
Requisito 2
...
...
Requisito N
Caracterstica M
Requisito 2
...
...
Requisito M
...
...
...
...
...
Tabela 3. Rastreabilidade entre Requisitos - Fonte: Adaptado de [12]
29
Anlise de Sistemas
A seguir so apresentadas 10 prticas para requisitos eficazes (Young,
1999):
Figura 5. Fonte: http://www.inf.ufes.br/~labes/resources/images/imgPalm.jpg
1.
2.
3.
4.
5.
Compromisso com abordagem.

Estabelecer e utilizar uma equipe responsvel para os requisitos.
Definir as necessidades reais do cliente.
Utilizar e melhorar continuamente o processo de requisitos.
Manter iteraes sobre os requisitos do sistema e os requisitos da
arquitetura.
6. Usar um mecanismo para manter a comunicao no projeto.
7. Selecionar mtodos familiares e manter um conjunto de produtos
de trabalho.
8. Executar verificao e validao de requisitos.
9. Fornecer um mecanismo efetivo para acomodar as mudanas nos
requisitos.
10. Executar o desenvolvimento com prticas bem conhecidas e provadas pela indstria, na organizao e no projeto.
2.4 Processo de Engenharia de Requisitos

Todo processo deve definir quem ir fazer o que, como e quando ser
atingido o objetivo. O processo de engenharia de requisitos possui as
seguintes fases: elicitao, anlise e modelagem, Verificao e Validao e gerncia [12].
Na elicitao (levantamento) de requisitos os requisitos so identificados e entendidos, aplicando tcnicas como: entrevistas, observao, anlise de documentos, questionrios, etc....
Na anlise e modelagem representado o entendimento do problema, aplicando tcnicas como: casos de uso (USC), diagrama de
30
fluxo de dados (DFD), Tabelas de deciso, modelo entidade
relacionamento (MER), etc...
A verificao e validao dos requisitos realizada utilizando as tcnicas de checklist, inspees, revises, etc...
Na gerncia so estabelecidos e mantidos um entendimento comum entre o cliente e a equipe de projeto relacionadas
s mudanas dos requisitos no sistema.
Na fase de elicitao de requisitos preciso identificar quais so
as fontes de informao para coletar os dados. As fontes de informao so os clientes, usurios, desenvolvedores, especialistas de domnio, documentos, os sistemas legados e a literatura
[12].
Para encontrar estas fontes preciso responder alguns questionamentos, tais como:

Quem utiliza ou utilizar o sistema?

Existe alguma soluo em uso?
Existem produtos similares?
Qual a documentao utilizada hoje?
H normas ou legislaes a serem seguidas?
Quais so os livros, teses, artigos relacionados com a aplicao que est sendo analisada?
2.5 Tcnicas para Levantamento de requisitos

Para levantar os requisitos funcionais e no funcionais h diversas tcnicas, dentre elas as mais aplicadas so as entrevistas, a
observao e a prototipao de telas.
A entrevista - uma das tcnicas
mais empregadas para identificar e
entender os requisitos definidos pelo
usurio. Pode ser utilizada em qualquer situao, pois uma tcnica
muito simples e direta. Para se ter sucesso com esta tcnica preciso que o
conhecimento do entrevistador no
Figura 6. Fonte: http://suachance. interfira na troca de informaes que
files.wordpress.com/2009/06/entre- se movimentam durante a etapa de
vsita.jpg
levantamento de requisitos.
31
Anlise de Sistemas
A observao - um mtodo cientfico,
aplicado no desenvolvimento de uma investigao. caracterizada por perceber,
visualizar e no interpretar, apenas observar. Seu resultado uma descrio do que
foi visualizado, sem que haja qualquer juzo de valor. O moderador desta observao dever acompanhar a realizao das
tarefas. O contato com um utilizador inexFigura 7. Fonte: http://3.bp.blogspot.
com/_Hrnl06uDEmE/SUA5RxV9qDI/ periente quando este interage com o sisteAAAAAAAAAEE/t1JhthJc0mc/s320/
ma, permite uma percepo facilitada do
observar.jpg
ponto de vista das dificuldades encontradas na navegao ou no uso de uma interface.
Prototipao de telas - Ela permite identificar as expectativas do
cliente principalmente nos aspectos
de usabilidade. De um modo geral
ela envolve programao. Neste
momento apresentando ao cliente um esboo da interface do sistema que ser desenvolvido [9].
Figura 8. Fonte: [9]
Dentre os requisitos levantados, esperam-se como atributos destes requisitos que eles sejam [12]:

Claros;
Bem escritos;
Sem ambigidades;
Implementveis;
Com baixa abstrao;
Verificvel; e
Rastreveis.
2.6 Anlise e Modelagem de Requisitos

Esta etapa consiste na documentao formal, por meio de uma determinada ferramenta, dos dados coletados na etapa de elicitao de
requisitos. Seu objetivo abstrair o requisito de tal forma que seja
possvel identificar todos os detalhes e suas dependncias com outros
32
requisitos. As tcnicas de Modelagem so:

Casos de uso;
Diagrama de Fluxo de Dados (DFD)
Tabelas de deciso:
Diagramas de Estado;
Dicionrio de dados;
Modelo Entidade-Relao (ER).
O caso de uso um meio para especificar as exigncias requeridas por um sistema, ou seja, ele representa um padro de comportamento do sistema.
O diagrama de fluxo de dados (DFD) uma notao grfica
utilizada para representar os fluxos de informao e as transformaes ocorridas pela passagem dos dados das entradas para
as sadas.
A Tabela de deciso uma forma organizada em Tabela para expressar qual o conjunto de condies que necessrio acontecer
para que um dado conjunto de aes seja realizado.
O diagrama de estados uma tcnica que descreve o comportamento do sistema, ela permite descrever todos estados possveis
que um objeto pode estar e como o seu estado comprometido
por eventos que o atingem.
O DFD especifica a informao por meio de rtulos, no entanto,
no descreve o seu significado. J o dicionrio de dados descreve o contedo dos itens de informao.
2.7 Gerncia de Requisitos
Figura 9. Fonte: http://www.pirelliclubtruck.com.br/

revistaclubtruck/revista/truck13/imagens/gestao_01.
jpg
Na etapa de desenvolvimento normal que novos requisitos sejam definidos e/ou que requisitos
j definidos sejam alterados. Estas mudanas so
consideradas na etapa de
desenvolvimento e devem ser acompanhadas
33
Anlise de Sistemas
para garantir que todos os artefatos afetados por uma alterao de requisitos sejam alterados.
2.8 Quais so as pricipais atividades da Gerncia de

Requisitos?
So elas: controle das solicitaes de mudanas, gerenciamento do
escopo, gerenciamento das inconsistncias entre requisitos e o projeto,
e manuteno da rastreabilidade entre os requisitos.
A solicitao da mudana inicia por meio de uma solicitao formal.
Em seguida avalia-se o seu impacto, para tal preciso ter uma rastreabilidade consistente. Logo aps, determina-se a viabilidade, aprovao, revisa-se o planejamento e executam-se as aes corretivas para
as inconsistncias (caso existam).
Para manter o escopo do projeto os requisitos devem ser mantidos
dentro do escopo que foi definido para o projeto, ou seja, no devem
ser realizadas atividade que vo alm do solicitado, uma vez que, este
tipo de ao pode impactar no prazo e custo do projeto.
2.9 Regras de Negcio (RNE)

Alm dos requisitos funcionais e no funcionais, existem as regras de
negcio que descrevem como uma dada funcionalidade deve ser realizada. Vejamos alguns exemplos de regras de negcio:
Regra de Negcio 01 (RNE. 01): A senha deve ter no mnimo 6 e

no mximo 10 caracteres, alfanumricos e no deve aparecer durante
a digitao.
Regra de Negcio 02 (RNE. 02): A mdia final deve ser calculada
atravs da somatrio das notas dos quatro bimestres e dividida por
quatro.
Regra de Negcio 03 (RNE. 03): A forma do registro no log de
operaes deve ser dd-mm-aaaa (exemplo: 01-01-2010), hora hh:mm
(exemplo: 12:12).
No prximo captulo vamos focalizar os casos de uso.
34
CAPTULO
3
Diagrama de casos de uso
Objetivo
Neste captulo estudaremos formas de
especificar sistemas orientados a objetos
com foco na viso do usurio. Veremos a
definio e documentao dos casos de
uso e seus tipos de relacionamentos.

Um diagrama de casos de uso visa permitir a compreenso do
comportamento de um sistema por qualquer pessoa, buscando
apresentar o sistema visto pela perspectiva do usurio.
Dentre todos os diagramas da UML (Unified Modeling Language) o mais abstrato e informal, sendo muito utilizado no incio
da modelagem do sistema, principalmente nas etapas de elicitao e anlise de requisitos. No entanto, nada impede que ele
possa ser consultado e modificado em outras fases [13].
Este tipo de diagrama muito til para o entendimento dos requisitos do sistema, facilitando a especificao, visualizao e
documentao das caractersticas, funes e servios do sistema
almejado pelo usurio [13].
A Tabela 4 apresenta os elementos bsicos, que compem um
caso de uso, e sua representao grfica.
Elemento
Descrio
Caso de uso
Representa um dilogo entre um ator e

sistema
uc use case model
Representa um papel
que pode ser assumido por um usurio
uc use case
model
Ator
Sintaxe
Nome
do caso de uso
Nome do ator
Sistema
Representa o limite
entre o sistema e os
atores do sistema
Associao
Representa a participao de um ator

em um caso de uso
Tabela 4. Sobre um Caso de Uso

Fonte: Adaptado de [12]
37
Anlise de Sistemas
A seguir, voc estudar em detalhes cada elemento do caso de uso.
3.1 Sistema
Entende-se como sistema todo e qualquer tipo sistema. Ele identifica a
funcionalidade bsica do escopo inicial, bem como, os termos e definies no incio do trabalho, tais como: glossrio e catlogo.
Sua notao uma caixa, como o nome do sistema exposto em cima
ou dentro da caixa.
3.2 Ator
O ator algum ou alguma coisa que interage, de alguma forma, com
o sistema. Ele representa um papel, no um usurio individual do sistema, onde uma pessoa pode assumir diferentes atores dentro de um
sistema [12].
A figura 10 representa alguns exemplos de atores.
Figura 10. Fonte Prpria
Ateno!! O ator uma classe e no uma instncia. Ele deve ter um

nome que represente o seu papel dentro do sistema e sua interao
com o sistema dada atravs da troca de mensagens.
Algumas dicas para identificar os atores [12]:
Quem utilizar a funcionalidade principal do sistema?
Quem necessita administrar e manter o sistema funcionando?
38

Quais dispositivos de hardware o sistema precisar manipular?
Com quais outros sistemas, o sistema precisar interagir?
Quem tem interesse nos resultados que o sistema produzir?
Assim como uma classe o ator pode ser generalizado/ especializado, ou seja, h herana entre atores. Exemplo: Um ator pessoa fsica pode herdar as caractersticas de um ator Pessoa.
3.3 Casos de uso

Os casos de usos referem-se s funcionalidades que podem ser
utilizadas pelos atores, eles descrevem e validam o que o sistema
ir fazer.
A Figura 11 apresenta um exemplo da notao de um caso de
uso.
Figura 11. Exemplo de Caso de Uso

Fonte: Prpria
Os casos de uso podem ser classificados como primrios ou secundrios. Um caso de uso primrio refere-se a um determinado
processo focalizado nos requisitos funcionais do software, como
por exemplo: cadastrar uma turma ou gerar um relatrio das
mdias dos alunos. Enquanto que um caso de uso secundrio
se refere a um processo perifrico, como a manuteno de um
cadastro [13].
Para identificar os casos de usos de um sistema preciso verificar
quais so as necessidades dos atores, como por exemplo:
Funcionrio: cadastra DVDs;
Cliente: loca DVDs; e
Sistema Financeiro: valida situao do cliente.
Outros questionamentos que podem ser realizados para encontrar os casos de uso de um sistema:
39
Anlise de Sistemas
Quais so as funes que os atores esperam do sistema?
O que cada ator precisa fazer?
O ator precisa realizar as operaes de cadastro, excluso, alterao e busca sobre alguma coisa no sistema?
Quais so as entradas e sadas do sistema? Qual a origem e destino
dos dados?
Assim como nos requisitos, nos casos de uso tambm dever haver
rastreabilidade bidirecional, conforme a Tabela 5.
Requisito 1
Requisito 2
...
...
Caso de Uso 1
Caso de Uso 2
...
...
Caso de Uso N
Requisito M
...
...
...
...
...
Tabela 5. Matriz de Rastreabilidade Bidirecional

Fonte: Adatpado [12]
Para cada requisito funcional deve haver, pelo menos, um caso de uso.
Assim como, para cada caso de uso, pelo menos, um requisito funcional. Em ambos os casos pode ser 1 para 1..n.
Os casos de uso devem ser documentados, eles fornecem instrues
em linhas gerais sobre o funcionamento do sistema, das atividades que
devero ser executadas, dos atores envolvidos, das possveis restries
entre outras [13].
A documentao produzida, alm de ser utilizada no momento da implementao do sistema, utilizada como base para a construo de
outros diagramas, como o de sequncia, por exemplo, e ela fornece
um relatrio ao cliente sobre o comportamento esperado de um dado
caso de uso [13].
3.4 Documentao de casos de uso

A documentao de um caso de uso descreve, por meio de uma linguagem simples, a funo do caso de uso, quais atores interagem com
ele, quais fases sero executadas pelo ator e pelo sistema para que o
caso de uso execute sua funo [13]. Um caso de uso deve, sempre,
ser iniciado por um ator [12].
No h um formato especfico, definido pela UML, para documentar
casos de uso de tal forma que represente as caractersticas do prprio
40

diagrama. Isto permite uma flexibilidade no formato da documentao que permite at pseudocdigo, no entanto, o objetivo
da documentao do caso de uso permitir que at mesmo os
usurios mais leigos entendam o que o caso de uso faz [13].
A seguir apresentada uma sugesto de documentao para um
caso de uso na Tabela 6.
Nome do Caso de Uso
Abrir Conta
Caso de Uso Geral

Ator Principal
Cliente
Atores Secundrios
Funcionrio
Resumo
Este caso de uso descreve as fases para

abrir uma conta corrente
Pr-Condies
1. A solicitao da abertura da conta

deve ter sido aprovada anteriormente
Ps-Condies
necessrio fazer um depsito inicial
Fluxo Principal
Aes do Ator
Aes do Sistema
1. Solicitar a abertura da conta

2. Consultar o cliente pelo CPF (Pessoa
Fsica) ou CNPJ (Pessoa Jurdica)
3. Informar a senha da conta
4. Abrir a conta
5. Informar o valor a ser depositado
6. Registrar o depsito
7. Emitir o carto da conta
Restries/Validaes
1. Para abrir uma conta a idade do

cliente deve ser maior ou igual a 18
anos
2. O valor mnimo de depsito R$
50,00
3. O cliente precisa fornecer um comprovante de residncia no seu nome
(conta de gua, luz ou telefone fixo)
41
Anlise de Sistemas
Fluxo Alternativo Manuteno do Castrado do Cliente
Aes do Ator
Aes do Sistema
1. Se for necessrio, Executar o
Caso de Uso Manter Cliente, para
gravar ou atualizar o cadastro do
cliente
Fluxo Exceo Cliente Menor de Idade

Aes do Ator
Aes do Sistema
1. Emitir uma mensagem para cliente informando que ele no possui
a idade mnima para abertura da
conta
2. Recusar a solicitao da abertura
da conta
Tabela 6. Documentao do Caso de Uso - Abertura de Conta

Comentrio:
De acordo com o modelo apresentado, primeiramente preciso
apresentar uma descrio sobre o caso de uso.
O campo Caso de Uso de Geral utilizado quando h casos de
usos especializados, como por exemplo uma conta especial, caso
estivssemos documentando o caso de uso de uma conta especial ele estaria derivando do caso de uso Abrir Conta. Como no
exemplo da Tabela 6 trata-se do caso de uso geral, o campo Caso
de Uso Geral ficou em branco [13].
J o campo ator principal identifica o ator que mais interage com
o caso de uso, onde os atores secundrios so aqueles que menos
interagem com o caso de uso.
No exemplo foram identificados dois atores: o Cliente e o Funcionrio. O cliente considerado como ator principal porque ele
quem solicita o servio. No entanto, quem interage realmente com
o servio a funcionalidade de abertura da conta o ator Funcionrio, e na documentao deste caso de uso, as aes tomadas pelo
Funcionrio so representadas pelas aes do sistema.
Em seguida tem-se o campo Resumo que apresenta o objetivo do caso de uso. Logo aps, vem as pr e ps-condies que
representam determinadas condies que precisam ser satisfeitas
para que o caso de uso seja executado (pr-condies) e concludo
(ps-condies).
O fluxo principal representa a sequncia das aes que devem ser
realizadas. Onde o fluxo alternativo representa uma situao que
42

no est compreendida no fluxo principal, ou seja, uma
situao que foge da situao ideal do caso de uso.
J o fluxo de exceo trata as situaes que precisam ser tratadas para dar continuidade ao fluxo da execuo da tarefa
quando uma determinada regra de negcio no foi atendida, como neste exemplo, esperado que a idade mnima do
cliente seja igual ou superior a 18 anos.
Por fim, tm-se as restries e validaes do sistema a fim de
torn-lo mais robusto, elas representam as regras de negcio
da empresa.
3.5 Associaes
Uma associao representa a participao de um ator em um
caso de uso, ela o nico relacionamento entre atores e casos
de uso [12]. Tambm podem ocorrer associaes entre casos de
usos, neste caso, este tipo de relacionamento recebe os seguintes
nomes: incluso, excluso ou generalizao [13].
A associao entre um ator e o caso de uso representa que este
ator se relaciona com a funo que est sendo representada pelo
caso de uso, conforme apresentado na Figura 12.
Figura 12. Associao entre Ator e Caso de Uso

Fonte: Adatpado [13]
3.6 Relacionamentos
Generalizao /Especializao
Quando um caso de uso uma especializao de outro caso de
uso [12], ou seja, uma forma de associao entre os casos de
uso que possuem caractersticas semelhantes e algumas particularidades exclusivas [13].
43
Anlise de Sistemas
O exemplo da Figura 13 representa o relacionamento entre a funo
de abertura de conta que difere em umas caractersticas quando se
classifica como conta especial e poupana. No entanto, elas possuem
algumas caractersticas que so comuns a elas, enquanto contas bancrias, independentes de seu tipo.
Figura 13. Exemplo de Generalizao

Quando um caso de uso uma especializao de outro caso de uso

[12], ou seja, uma forma de associao entre os casos de uso que
possuem caractersticas semelhantes e algumas particularidades exclusivas [13].
Este tipo de relacionamento tambm pode ocorrer entre atores, conforme apresentado na Figura 14.
Figura 14. Exemplo de Generalizao entre Atores - Fonte: Adaptado de [13]
44

Include (Incluso)
A associao de incluso utilizada quando h uma situao
comum entre dois ou mais casos de uso. Este tipo de relacionamento indica obrigatoriedade, isto , quando um dado caso
de uso possui uma incluso com outro, a execuo do primeiro
implica tambm na execuo do segundo [13].
Figura 15. Exemplo de Incluso

No exemplo apresentado na Figura 15 nota-se que, toda vez que

for realizado um saque ou um depsito, obrigatoriamente, devese registrar essas operaes.
Extend (Extenso)
Este tipo de relacionamento permite adicionar novos comportamentos ao caso de uso sem prejudicar o seu entendimento [12].
Esta associao de extenso utilizada para descrever situaes
opcionais de um dado caso de uso, ou seja, ela representa cenrios que somente ocorrero em situaes especficas.
Para facilitar o entendimento, ser apresentado um exemplo de
login onde necessrio o usurio de registrar quando no possui
cadastro, conforme a Figura 16.
Figura 16. Formulrio de Login - Fonte: Desenvolvido a partir do exemplo de [13]
45
Anlise de Sistemas
A Figura 17 representa um exemplo onde h uma associao por extenso.
Figura 17. Exemplo de Extenso

Este exemplo representa uma situao do formulrio de login apresentado na Figura 17 onde um usurio precisa logar-se para acess-lo.
No caso do usurio no possuir login/senha ele pode clicar na opo
Auto-registrar, para se cadastrar no sistema, sendo que essa situao
ocorrer apenas uma vez, depois, o usurio ter acesso ao sistema e
no passar novamente por esta situao [13].
No prximo captulo apresentaremos os diagramas de sequncia e
classe.
46
CAPTULO
4
Diagrama de Sequncia
Objetivo
Neste captulo estudaremos outras formas
de especificar sistemas orientados a objetos, entretanto neste momento o foco a
viso do desenvolvedor. Sendo assim, veremos a definio e a documentao dos diagramas de sequencia e de classe.
Diagrama de sequncia
O diagrama de sequncia um diagrama de comportamento
que preocupa-se com a ordem temporal em que as mensagens
so trocadas entre os objetos envolvidos em dado processo [13],
isto , ele apresenta a interao dos objetos organizados no tempo.
A utilizao deste tipo de diagrama pode ser empregada para
detalhar a colaborao na realizao de um caso de uso [18].
Um diagrama de sequncia identifica o evento gerador do processo modelado e o ator envolvido, bem como ele determina
como o processo deve ser implementado.
A Figura 18 apresenta um diagrama de sequncia para a funo
Buscar Imvel.
Figura 18. Diagrama de Sequncia da Funo Buscar Imvel

Fonte: Prpria
49
Anlise de Sistemas
4.1 Alguns elementos de um diagrama de sequncia

Atores: so os mesmos descritos nos diagramas de casos de uso
Linha de Vida: representa o tempo de vida em que o objeto existe
durante um processo.
Mensagem Sncrona: demonstra a ocorrncia de eventos, envolvendo mtodos.
Retorno: um tipo de mensagem que indica a resposta para o
objeto ou ator que a chamou.
Figura 19. Elementos do Diagrama de Sequncia

Fonte: [18]
50
Diagrama de sequncia
4.2 Diagrama de Classe

O diagrama de classe um dos mais utilizados da UML. Ele
serve de apoio para a maioria dos demais diagramas. Ele define
a estrutura das classes que sero utilizadas no sistema, determinando os seus mtodos e atributos de cada classe, bem como, o
relacionamento entre as classes [13].
A Figura 20 apresenta um exemplo de diagrama de classes.
Figura 20. Diagrama de Classes

Fonte: Prpria
51
Anlise de Sistemas
Atividades de Aprendizagem
1) Com relao aos diagramas de sequncia leia as afirmativas e assinale V para as alternativas Verdadeiras e F para as alternativas Falsas.
( ) O diagrama de sequncia um diagrama comportamental que se
preocupa em demonstrar a ordem espacial em que as mensagens so
trocadas entre os objetos envolvidos em um determinado processo.
( ) A construo do diagrama de sequncia geralmente considera um
nico caso de uso.
( ) Um diagrama de sequncia costuma identificar o ator responsvel
pelo evento gerador do processo que est sendo modelado.
( ) Em um diagrama de sequncia as mensagens enviadas por cada
objeto so representadas por setas entre os objetos que se relacionam.
( ) Diagramas de sequncia possuem dois eixos: o eixo vertical, que
mostra o tempo e o eixo horizontal, que mostra os objetos envolvidos
na sequncia de uma certa atividade.
( ) Os diagramas de sequncia mostram apenas os objetos que so
criados como parte do cenrio documentado pelo diagrama.
52
CAPTULO
5
Diagrama de Fluxo de dados - DFD
Objetivo
Neste captulo estudaremos formas de
especificar sistemas estruturados. Estudaremos tambm a definio e a documentao dos diagramas de fluxo de dados
(DFD).

Um Diagrama de Fluxo de Dados (DFD) uma das mais utilizadas ferramentas que, em forma de notao grfica, nos auxilia
na modelagem de sistemas operativos mais complexos do que
apenas a manipulao dos dados. Ele apresenta uma viso estruturada dos dados, ou seja, um fluxo de dados que nos permite representar vrias vises do sistema, analisado assim em
diferentes nveis de detalhamento [12]
Estes nveis de detalhamento variam de acordo com a clareza
dos processos do projeto, onde o Diagrama de Contexto representa uma viso macro do sistema, e em seguida temos os diagramas de nveis. O nvel mais alto conhecido como DFD de
nvel 0, que est logo abaixo do diagrama de contexto, onde
neste nvel sero mostradas as funes mais importantes do sistema. Caso no esteja claro o processo, o mesmo aperfeioado
a cada nvel [12].
Este ponto de vista do projeto, visando o fluxo de dados nos permite uma viso mais ampla do sistema, pois no ponto vista das
pessoas, mquinas e da empresa, s possvel visualizar apenas
partes do que acontece com o sistema. Isto significa uma grande
mudana em relao s formas clssicas de analise de sistemas,
que costumavam primeiramente abordar a viso do usurio em
relao ao sistema [12].
De forma resumida um DFD representa (como acontece com a
transformao dos dados que se movimentam pelo sistema) e
apresenta as funes e sub-funes que modificam o fluxo de
dados.
55
Anlise de Sistemas
Elementos que compe um Diagrama de Fluxo de Dados:
Notao Gane e
Sarson
Processo
Um processo mostra
uma parte do sistema
que altera as entradas
e sadas, e tem no
mnimo eu fluxo de
dados de entrada e
outro de sada.
Repositrio
de Dados
utilizado para
representar os dados
armazenados de alguma forma.
Entidade
Externa
Ilustra um agente
esterno ao sistema que
est sendo modelado,
e interage com ele.
Fluxo de
Dados
Mostra um dado ou
uma coleo deles, e
sempre inicia ou termina em um processo.
Notao
DeMarco e
Yourdan
Nome
Nome
Nome
Nome
Nome
Nome
Nome
Nome
Tabela 7. Elementos de um DFD

Fonte:Adaptado de [12]
5.1 Como elaborar um DFD

1) Eleger nome expressivos:
Evitar nomes de pessoas ou grupos;
Nomear o processo a fim de identificar as suas funes;
Os nomes devem ser familiares ao usurio.
2) Numerar os processos:
A numerao no depende da ordenao entre os processos, ele
apenas ajuda a identific-los.
56

Exemplo:
Figura 21. Numerao de Processos

Fonte: [12]
3) Redesenhar o DFD quantas vezes forem precisas para

ter uma aparncia legvel:

No mnimo 3 e no mximo 7 bolhas. Exceto no caso do
diagrama de contexto:
Figura 22 - Diagrama de contexto

Fonte: [12]
4) Assegure-se de que o DFD possua uma relao lgica:

Cuide para que no desenhe um processo com entradas e
sem sadas;
Tenha cuidado tambm para que o processo no tenha gerao espontnea de dados, processo com sada, mas sem
entrada. Com exceo da gerao de nmeros aleatrios.
57
Anlise de Sistemas
5) Verifique se todos os processos e fluxos tenham rtulos:
Falta de Ateno, erros, ou no soube nomear?
Fluxo: itens importantes de dados no foram relacionados ou foram reunidos;
Processo: desordem do analista. Desenhou em fluxograma disfarado.
6) Cuidado com o armazenamento de apenas leitura ou de apenas escrita:

Equivalente a diretriz de processos com apenas entradas ou apenas sadas;
Um bom armazenamento deve ter entradas e sadas.
5.2 Nveis do DFD

Em uma modelagem de diagramas mais complexos, aconselhvel
que eles sejam criados em nveis, e que cada um apresente de forma
sucessiva, os detalhes de uma parte do nvel anterior.
O DFD do mais alto nvel consiste numa viso do sistema inteiro; os fluxos de dados representam as interfaces entre o sistema e as entidades
externas. Ele conhecido como Diagrama de Contexto e opcional.
E1
Sistema
E2
Diagrama de Contexto
Figura 23
Fonte: [12]
58
E1

O diagrama que vem logo em seguida do Diagrama de contexto
conhecido como FIGURA 0, ou de nvel 0. Esta a verso de
mais alto nvel que representa as principais funes do sistema e
tambm as principais interfaces entre as funes.
5.3 Vantagem do uso de DFDs em nveis

Com DFDs em nveis possvel adotar a abordagem TOPDOWN. Com isso possvel que o gerente faa a leitura dos
nveis mais altos, para um melhor entendimento, ou ainda
ter uma viso geral do sistema. Programadores e usurios
podem ler do mais resumido ao mais detalhado, limitandose as reas do seu interesse.
No existem ligaes entre a continuao em outra pgina.
Fluxos de Dados que antecedem somem da prxima pgina,
ele fica no contexto do pai, ou seja, cada pgina referente
a uma rea de trabalho destinada a ele, voc nunca ter que
procurar em outra pgina e continuar sua leitura para ter
uma descrio total.
Todos os diagramas devem ocupar apenas uma pgina.
Exemplo de um Diagrama de Fluxo de Dados (DFD):
Figura 24. Exemplo de DFD

Fonte: [12]
59
Anlise de Sistemas
Atividades de aprendizagem
1) Correlacione os termos apresentados com as definies descritas
abaixo:
( A ) Processo
( B ) Repositrio de Dados
( C ) Entidade Externa
( D ) Fluxo de Dados
( ) Mostra um agente externo ao sistema que est sendo modelado, e
interage com ele.
( ) Mostra um dado ou uma coleo deles, e sempre inicia ou termina
em um processo.
( ) utilizado para representar os dados armazenados de alguma forma.
( ) Mostra uma parte do sistema que altera as entradas e sadas, e tem
no mnimo eu fluxo de dados de entrada e outro de sada.
60
CAPTULO
6
Ciclo de vida
Objetivo
Inicialmente, vamos descobrir juntos que
existem diferentes ciclos de vida de software, Isto , formas distintas de se desenvolver um software. Em seguida, iremos
estudar os modelos de ciclo de vida de
software mais tradicionais na literatura e
no mercado.
Ciclo de vida
Um processo de software utilizado para construir sistemas de
qualquer natureza com o objetivo de favorecer a produo de
sistemas com qualidade, que atenda as necessidades dos usurios, dentro do cronograma e oramento planejado [15].
Ele no pode ser definido de forma universal, para que seja
eficaz e produza um produto de qualidade, necessrio que o
processo esteja alinhado com as especificaes do projeto, ou
seja, os processos devem ser definidos caso a caso, levando em
considerao o domnio do problema, complexidade, tecnologia
a ser adotada etc [15].
Dentro deste contexto, a escolha do modelo de ciclo de vida, ou
modelo de processo, o ponto de partida para definir o processo de desenvolvimento do software.
De um modo geral, o modelo de ciclo de vida organiza as atividades do processo, definindo a sequncia e as dependncias
das mesmas.
6.1 Algumas definies de ciclo de vida de software

Um framework que contm os processos, atividades e
tarefas envolvidas na implementao, operao e manuteno de um produto de software, levando em considerao toda a vida do software, desde a definio de seus
requisitos at o encerramento de seu uso (apud [16],
ISO/IEC 12207);
dividir a vida de um produto ou projeto em fases (apud
[16], SEI, Glossrio do CMMI);
uma passagem completa por quatro fases: concepo, elaborao, construo e transio. o intervalo de
tempo entre o incio de concepo e o final da fase de
transio (apud [16], IBM/ Rational, Glossrio do RUP).
63
Anlise de Sistemas
6.2 Os componentes do desenvolvimento de um ciclo

de vida
Fases: indicam o progresso do projeto;
Atividades: requerem aes para criar e entregar o projeto;
Artefatos: so produtos palpveis elaborados durante o projeto; e
Marcos: so eventos importantes no projeto.
Em geral, os modelos de processos possuem as fases de Anlise e Especificao de Requisitos, Projeto, Implementao, Testes e Entrega e
Implantao [15].
H uma variedade de modelos com componentes diversos que podem
ser aplicados a diferentes projetos. No h um modelo mais correto
que outro. de responsabilidade do gerente de projeto definir o modelo mais indicado para o seu projeto [16].
6.3 Modelos de ciclo de vida

Os principais modelos de ciclo de vida so classificados como [15]:
Modelos Seqenciais, Modelos Incrementais e Modelos Evolutivos.
6.3.1 MODELO SEQUENCIAL

Este modelo organiza o processo em uma sequncia de fases. O modelo cascata considerado o principal modelo desta categoria e ele
serviu como base para outros modelos, como os modelos incrementais
e evolutivos [15].
6.3.2 MODELO CASCATA

O modelo cascata, tambm conhecido como modelo clssico, organiza as atividades do processo de desenvolvimento de uma maneira
seqencial, conforme apresentado na Figura 25 [15].
Figura 25. Modelo Clssico/Cascata

Fonte: Adatptado [16]
64
Ciclo de vida
O Modelo Cascata baseado nos processos convencionais de
outras engenharias; possui uma abordagem sistemtica e seqencial cujos marcos e entregveis so de fceis de identificar;
fortemente documental e pouco iterativo; implica em uma especificao completa e difcil introduzir mudanas depois de
ter iniciado o processo [16].
As fases deste modelo so [16]:
1. Especificao (Requisitos): identificao e anlise dos
requisitos do sistema de acordo com as necessidades dos
usurios;
2. Projeto (Design): o detalhamento da soluo para o
sistema ser construdo, ele incluiu padres de projetos,
algoritmos, definio da arquitetura etc.
3. Implementao: a programao da soluo na fase
de projeto. Ela inclui os testes realizados sobre os mdulos implementados (os testes de unidade).
4. Verificao e Validao: verificar se o que foi implementado est conforme a especificao e validar se o
que foi implementado atende as necessidades do usurio. Esta fase tambm inclui os testes de integrao.
5. Manuteno: evoluo contnua do sistema trata os erros e as adaptaes do sistema.
A manuteno deve ser considerada em todos os ciclos de
vida, ela no deve ser encarada como uma fase isolada e sim
como uma aplicao contnua das atividades envolvidas nas
fases anteriores [16].
H quatro tipos de manuteno:
Manuteno Corretiva: corrigir os erros encontrados;
Manuteno Adaptativa: adaptar o software em relao
a uma mudana externa. Exemplo: Atualizao do sistema
operacional;
Manuteno Evolutiva: melhoria contnua do software.
Exemplo: Incluso de uma nova funcionalidade.
Manuteno Preventiva: uma melhoria interna do sistema para otimizar um recurso. Exemplo: Otimizar um determinado algoritmo no cdigo.
65
Anlise de Sistemas
O modelo Cascata possui algumas crticas relacionadas sua eficincia, sendo destacados, a seguir, alguns dos problemas identificados:
Projetos reais no seguem o fluxo na sequncia definida pelo
modelo;
Os requisitos precisam ser definidos claramente j no incio do
projeto, o que na prtica difcil ocorrer.
O usurio ter uma verso operacional do sistema apenas no
final do projeto;
O atraso em uma fase impacta na outra na fase.
6.3.2 MODELO V
Este modelo uma variao do modelo em cascata, que destaca a
relao entre as atividades de teste e as demais fases do processo, conforma apresentado na Figura 26 [15].
Figura 26. Modelo V

Fonte: [15]
Este modelo sugere que os testes de unidade

so utilizados para verificar a implementao e o projeto detalhado. A conexo entre
os lados direito e esquerda do modelo implica que, para os problemas identificados em
uma atividade de teste, na fase correspondente do lado esquerdo e as fases subseqentes podem ser executadas novamente
para corrigir os problemas.
6.3.4 MODELOS INCREMENTAIS

Nos casos onde possvel utilizar o modelo seqencial em funo do
tamanho do sistema e/ou quando preciso disponibilizar uma verso
de forma mais rpida para o cliente, indica-se o modelo incremental
[15].
66
Ciclo de vida
No modelo incremental o sistema dividido em mdulos ou
subsistemas, cujas verses so definidas, inicialmente com um
pequeno subsistema funcional, que a cada ciclo insere novas
funes [15].
O princpio do modelo que, a cada iterao, liberada uma
verso operacional do sistema para o cliente utilizar e validar
[15].
Destacam-se como as principais vantagens do modelo incremental [15]:
Economia no tempo e custo para se entregar a primeira
verso;
Reduo dos riscos no desenvolvimento de cada iterao em funo do tamanho;
O nmero de mudanas nos requisitos pode diminuir
devido ao curto tempo de desenvolvimento de um incremento.
Com relao as desvantagens [15]:
Quando os requisitos so instveis ou incompletos, alguns incrementos podem ter de ser muito alterados;
A gerncia do projeto complexa;
6.3.5 RUP (Rational Unified Process)

O RUP um framework de processo de desenvolvimento de
software que fornece uma abordagem disciplinada para associar tarefas e responsabilidades dentro de uma organizao de
desenvolvimento [16]. Ele foi criado pela Rational e hoje um
produto da IBM.
O RUP foi um projeto criado para suportar a implementao
de melhores prticas que adotam o ciclo de vida iterativo incremental.
67
Anlise de Sistemas
Os princpios do RUP so [16]:

Tratar os riscos desde o comeo e continuamente;

Garantir que algo de valor vai ser entregue ao cliente;
focado no executvel do software;
Tratar das mudanas desde o comeo do projeto;
Definir uma linha de base da arquitetura desde o comeo do
projeto;
Trabalhar em equipe;
Qualidade inerente a tudo;
As 6 melhores prticas [16]:

Desenvolvimento realizado de modo iterativo;

Gerenciar requisitos;
Utilizar arquitetura de componentes;
Modelagem visual (utilizando UML);
Verificar a qualidade continuamente;
Gerenciar configurao e mudanas.
A Figura 27 ilustra o modelo iterativo.
Figura 27. Modelo Iterativo: Tempo e Contedo

Fonte: [16]
No modelo iterativo uma iterao uma sequncia distinta com durao fixa de atividades, cujo resultado uma release do produto executvel.
Onde um release refere-se ao software que j foi testado e ele baseado em um build (ou em vrios deles). J um build refere-se ao software
68
Ciclo de vida
que ainda est em teste, ele gerado com maior frequncia que
o release. A Figura 28 ilustra o ciclo de vida iterativo.
Figura 28. Ciclo de Vida Iterativo

Fonte: [16]
As fases fornecem marcos bem definidos, cujos objetivos de

cada fase so atingidos com a execuo de uma ou mais iteraes dentro de cada fase.
Fase de Concepo - o foco est voltado no conceito, viso, identificao dos riscos, oramento e requisitos, bem
como, o objetivo do projeto de software precisa ser definido.
Fase de Elaborao - o foco est em prover a arquitetura
do software.
Fase de Construo - o foco est voltado na construo
do software.
Fase de Transio - o foco est na implementao e na
liberao do produto final [16].
Exemplos de objetivos e critrios da Fase de Concepo [16]:
Objetivos Primrios
Critrio de Avaliao do Marco
Estabelecer o escopo do projeto
Os stakeholders concordam
sobre o escopo
Estabelecer os critrios de aceita- Os stakeholders concordam

o do projeto
sobre os critrios
Identificar as funcionalidades do Os stakeholders concordam com
sistema e selecionar aquelas que os requisitos elicitados e que
so crticas
h um entendimento sobre os
mesmos
69
Anlise de Sistemas
Estimar o custo e cronograma
total do projeto
Os stakeholders concordam que

as estimativas de custo/cronograma, prioridades, riscos e processo so apropriadas.
Estimar riscos em potencial
Todos os riscos foram registrados

e avaliados e uma estratgia de
mitigao foi definida
Configurar o ambiente de supor- O ambiente de suporte est

te para o projeto
pronto.
Tabela 8. Fonte: Adaptado de [16]
Exemplos de objetivos e critrios da Fase de Elaborao [16]:

Objetivos Primrios
Garantir que a arquitetura, requisitos e planos so estveis; estabelecer uma arquitetura controlada por
baselines
A viso do produto, requisitos e

arquitetura so estveis.
Assegurar que os riscos so mitigados de forma eficiente para atender

o custo/cronograma
Os riscos mais significantes foram

destinados e esto sendo resolvidos
de uma forma adequada
Demonstram que a arquitetura

suportar os requisitos do sistema
dentro do custo/ cronograma
Todos os aspectos de arquitetura

do sistema e algumas funes esto
sendo avaliadas em um prottipo.
Exemplos de objetivos e critrios da Fase de Construo [16]:

Objetivos Primrios
Alcanar verses teis
O sistema foi desenvolvido conforme as expectativas especificadas
Completar a anlise, design, implementao e teste de toda a funcionalidade requerida
Toda funcionalidade requerida foi

incorporada no sistema.
Certificar que o sistema est pronto

para ser posto no ambiente do
cliente.
O sistema atendeu todos os critrios

de aceitao quando testado no
ambiente do cliente.
70
Ciclo de vida
Exemplos de objetivos e critrios da Fase de Transio [16]:
Objetivos Primrios
Repassar o sistema para os canais adequados de liberao
O sistema passou nos critrios

formais de aceitao no ambiente do usurio final
A figura abaixo representa o percentual de tempo gasto por fase.

nota-se que a fase de construo consome mais tempo.
Figura 30. Distribuio do Tempo
6.3.6 MODELO EVOLUTIVO

H alguns sistemas em que difcil estabelecer os seus requisitos, dada complexidade do mesmo, assim como estes requisitos
so bastante instveis. Dentro deste contexto importante haver
ciclos de vida que atendam este perfil de sistema, no entanto, de
um modo geral, nem todo modelo incremental pode ser aplicado neste tipo de cenrio. Para tal existem os modelos evolucionrios ou evolutivos que buscam preencher esse espao [16].
71
Anlise de Sistemas
6.3.7 MODELO ESPIRAL
O modelo espiral, apresentado na Figura 31, um dos modelos evolutivos mais difundidos [15].
Figura 31. Modelo Espiral

Fonte: [15]
Principais aspectos deste modelo [16]:

Melhorias do modelo em cascata;
Ele permite o envolvimento com o usurio;
iterativo com releases incrementais e extremamente focado
na anlise de riscos;
Sua adoo no trivial e envolve elevados custos;
Pode no convergir para uma soluo; e
No muito utilizado.
Atividades de aprendizagem
Selecione a opo que representa a sequncia correta das fases do
ciclo de vida iterativo e incremental:
(
(
(
(
72
) Concepo, Elaborao, Construo, Transio

) Transio, Concepo, Elaborao, Construo
) Concepo, Transio, Construo, Elaborao
) Transio, Concepo, Elaborao, Construo
REFERNCIA BIBLIOGRFICA
[1] http://www.csgnet.org/informatica/conteudo.aspx?id_area=1&id_tema=13
Apostila: Introduo Anlise de Sistemas (2003)
[2]http://www.lcs.poli.usp.br/~jra/PROMINP/disciplina_OO_pdf/aula_I_Historia_
Abordagens_EstxOO.pdf
[3] Nascimento, Luciano Prado Reis. O usurio e o Desenvolvimento de Sistemas, Visual Books, Florianpolis, 2003.
[5] Falbo, Ricardo de Almeida. Anlise de Sistemas Notas de Aula, UFPES, 2002.
Disponvel em < http://www.ceunes.ufes.br/downloads/2/mariateixeira-Notas%20
de%20Aula.An%C3%A1lise%20de%20Sistemas.Prof%20Falbo.UFES.pdf>
[6] Pessoa, Andr. Projetos de Sistemas de Informao, Book Express , 2000.
[7] http://www.eteavare.com.br/arquivos/43_38.pdf
[8] Wazlawick, Raul Sidnei. Anlise e Projeto se Sistemas de Informao Orientados a Objetos. Rio de Janeiro: Elsevier, 2004.
[9] Thiry, Marcello. Gerncia de Requisitos (GRE), Incremental Tecnologia, 2009.
[10] Professor Luis Angelo. SISTEMAS DE INFORMAO Componente Curricular Anlise e Projeto de Sistemas I. Cidade de Avar, 2008. Disponvel em:
<http://www.eteavare.com.br/arquivos/43_38.pdf>
[11] Bezerra, Eduardo. Princpios de Anlise e Projetos de Sistemas com UML.
Rio de Janeiro: Elsevier, 2007.
[12] Thiry, Marcello. Engenharia de Software: Requisitos, UNIVALI, 2007.
[13] Guedes, Gilleanes T. A. UML 2: uma abordagem prtica. So Paulo: Novatec
Editora, 2009.
[14] Professor Luis Angelo. Ciclo de Vida de Sistemas de Informao Componente Curricular Anlise e Projeto de Sistemas I. Cidade de Avar, 2009. Disponvel em: <http://www.eteavare.com.br/arquivos/43_37.pdf>
[15] Falbo, Ricardo de Almeida. Engenharia de Software Notas de Aula. Esprito
Santo, 2005.Disponvel em: < http://www.inf.ufes.br/~falbo/download/aulas/esg/2005-1/NotasDeAula.pdf >

[16] Thiry, Marcello. Engenharia de Software: Introduo, UNIVALI, 2007.
[17] Thiry, Marcello. Engenharia de Software: Modelagem de Negcio, UNIVALI, 2007.
[18] Thiry, Marcello. Engenharia de Software: Projeto (Design), UNIVALI,
2007.
[19]
http://www.google.com.br/imgres?imgurl=http://1.bp.blogspot.com/_gib0rD3V3Gg/SP5LdGVEw_I/AAAAAAAAAFU/mTuh0eAwmRU/s320/mictorio.
jpg&imgrefurl=http://armariodearquivos.blogspot.com/2008_10_01_archive.
html&usg=__FlpAuBDqkrkGY5nKBmSWQtmmMNY=&h=240&w=320&sz=
13&hl=pt-BR&start=14&um=1&itbs=1&tbnid=h9vKPZu3hIVT1M:&tbnh=8
9&tbnw=118&prev=/images%3Fq%3Dfalha%2Bno%2Bmict%25C3%25B3rio
%26um%3D1%26hl%3Dpt-BR%26tbs%3Disch:1

Análise de Sistemas

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Análise de Sistemas

Caricato da

Copyright:

Formati disponibili

Anlise de Sistemas

Alessandra Casses Zoucas

Zoucas, Alessandra Casses

Catalogado por: Augiza Karla Boso CRB 14/1092

Produo e design instrucional:

Captulo 2 - Levantamento de Requisitos

Captulo 3 - Diagrama de casos de uso

Captulo 4 - Diagrama de Sequncia

Captulo 5 - Diagrama de Fluxo de Dados - DFD

Captulo 6 - Ciclo de Vida

Introduo a Anlise de Sistemas

Anlise de Sistemas: representa o estudo detalhado de uma

Necessidades: est ligada diretamente com o real problema

Produto de Software: a entidade de software disponvel para

Qualidade de Software: a totalidade das caractersticas de

Sistema: conjunto de elementos (subsistemas) independentes entre si,

1.2 Linha do Tempo

Introduo a Anlise de Sistemas

1970 - Crise do Software

tnuos erros de execuo, tempo da coleta de dados, descumprimento

1.3 Metodologias de desenvolvimento de Softwares

1.3.1 Anlise Estruturada

Fase 1- Estudo Inicial

Introduo a Anlise de Sistemas

Fase 3 Definio e Projeto de Solues Alternativas

Fase 4 Projeto Fsico

1.4 Revendo a histria

Figura 2. Fonte: http://www.exkola.com.br/site/files/carreira/carreira-818.jpg

Neste sentido buscou-se aplicar os conceitos de projeto estruturado

1.5 Anlise Essencial

Introduo a Anlise de Sistemas

1.6 Anlise Orientada a objeto

Introduo a Anlise de Sistemas

1.6.1 Abstrao de Dados:

Introduo a Anlise de Sistemas

1.7 Problema X Soluo

O que incomoda o cliente?

Introduo a Anlise de Sistemas

( ) A secretria marca em sua

2.1 Requisitos Funcionais

Tabela 1. Resultado da falha na anlise de requisitos

2.2 Requisitos no-funcionais

Tabela 2. Rastreabilidade Bidirecional - Fonte: Adaptado de [12]

Tabela 3. Rastreabilidade entre Requisitos - Fonte: Adaptado de [12]

Figura 5. Fonte: http://www.inf.ufes.br/~labes/resources/images/imgPalm.jpg

Compromisso com abordagem.

2.4 Processo de Engenharia de Requisitos

Quem utiliza ou utilizar o sistema?

2.5 Tcnicas para Levantamento de requisitos

2.6 Anlise e Modelagem de Requisitos

2.7 Gerncia de Requisitos

Figura 9. Fonte: http://www.pirelliclubtruck.com.br/

2.8 Quais so as pricipais atividades da Gerncia de

2.9 Regras de Negcio (RNE)

Regra de Negcio 01 (RNE. 01): A senha deve ter no mnimo 6 e

Diagrama de casos de uso

Representa um dilogo entre um ator e

uc use case model

Representa a participao de um ator

Tabela 4. Sobre um Caso de Uso

Figura 10. Fonte Prpria

Ateno!! O ator uma classe e no uma instncia. Ele deve ter um

Diagrama de casos de uso

3.3 Casos de uso