as-apostila-v1parte11

Prévia do material em texto

Análise de Sistemas 2014
 
Prof. Gunther Graf Jr. Página 1 
 
ANÁLISE DE SISTEMAS 
CURSO TÉCNICO EM INFORMÁTICA
Sumário 
1. Conceitos de Engenharia de Sistemas.............................................................................................................. 2 
2. Conceitos de Análise de Sistema Estruturado ............................................................................................... 5 
3. Estudo de viabilidade ........................................................................................................................................... 8 
4. Especificação de Requisitos ............................................................................................................................... 9 
 
Análise de Sistemas 2014
 
Prof. Gunther Graf Jr. Página 2 
 
1. Conceitos de Engenharia de Sistemas 
De acordo com o INCOSE - International Council of Systems Engineering1 - a Engenharia de Sistemas é uma 
abordagem interdisciplinar que torna possível a concretização de "Sistemas" de elevada complexidade. O seu foco 
encontra-se em definir, de maneira precoce no ciclo de desenvolvimento de um sistema, as necessidades do usuário, 
bem como as funcionalidades requeridas, realizando a documentação sistemática dos requisitos, e abordando a 
síntese de projeto e a etapa de validação de forma a considerar o problema completo: 
 Operação; 
 Custos e cronogramas; 
 Performance; 
 Treinamento e suporte; 
 Teste; 
 Instalação; 
 Fabricação. 
A Engenharia de Sistemas integra diferentes disciplinas e especialidades em uma equipe de projeto, formando 
um processo de desenvolvimento estruturado que se estende do conceito ao projeto, e deste à operação. A 
Engenharia de Sistemas considera tanto as questões de ordem econômica quanto técnica, com o objetivo de gerar 
produtos de qualidade que atendam às necessidades dos consumidores. 
Engenharia de Software X Engenharia de Sistema 
A Engenharia de Software preocupa-se principalmente com o software (o programa). A engenharia de sistemas 
está interessada em todos os aspectos de um sistema baseado em computador, incluindo hardware software, 
fatores humanos, informação e o processo. 
A economia de todos os países desenvolvidos depende de software. Mais e mais sistemas são controlados por 
software. 
Engenharia de software se preocupa com teorias, métodos e ferramentas para desenvolvimento de software 
profissional. 
Despesas de engenharia de software representa uma fração significativa do PIB em todos os países 
desenvolvidos. 
Custos de Software 
 Custos de software em geral dominam os custos do sistema. 
 Os custos de software em um PC são muitas vezes superiores ao custo do hardware. 
 O custo de manutenção do Software é maior do que o custo para desenvolver. 
 Para sistemas de longa duração, os custos de manutenção podem ser várias vezes os custos de 
desenvolvimento. 
Engenharia de software se preocupa com os custos efetivos de desenvolvimento. 
 
1
 http://www.incose.org/ 
Análise de Sistemas 2014
 
Prof. Gunther Graf Jr. Página 3 
 
O que é software? 
 Os programas de computador e documentação associada. 
 Os produtos de software podem ser desenvolvidos para um determinado cliente ou podem ser desenvolvidos 
para um mercado geral. 
O que é Engenharia de software? 
 Engenharia de software é uma disciplina de engenharia que se preocupa com todos os aspectos da produção de 
software, desde os estágios iniciais de especificação até a manutenção desse sistema, depois de sua implantação. 
 Os engenheiros de software devem adotar uma abordagem sistemática e organizada em seu trabalho e usar 
ferramentas e técnicas apropriadas, dependendo do problema a ser resolvido, as limitações de desenvolvimento e 
os recursos disponíveis 
O que é um processo de Software? 
Um conjunto de atividades cujo objetivo é o desenvolvimento ou a evolução do software 
 As atividades genéricas em todos os processos de software são: 
o Especificação 
 O que o sistema deve fazer e suas limitações de desenvolvimento 
o Desenvolvimento 
 Produção do sistema de software 
o Validação 
 Verificar se o software é que o cliente quer 
o Evolução 
 Responder às mudanças em resposta às novas exigências 
Quais são os atributos de um bom software? 
O software deve oferecer a funcionalidade e desempenho para o usuário e deve ser: 
 Manutenibilidade 
O software deve evoluir às alterações para atender às necessidades 
 Confiabilidade 
O software deve ser confiável 
 Eficiência 
O software não deve fazer uso exagerado de recursos do sistema 
 Usabilidade 
O software deve ser usado pelos usuários para o qual foi projetado 
 Segurança 
O software de estar livre dos problemas conhecidos de segurança 
 
Análise de Sistemas 2014
 
Prof. Gunther Graf Jr. Página 4 
 
Questões de responsabilidade profissional 
Confidencialidade 
 Engenheiros devem respeitar a confidencialidade de seus empregadores ou clientes, independentemente de 
terem ou não um acordo de confidencialidade formal assinado. 
Competência 
 Os engenheiros não devem deturpar o seu nível de competência. Eles não devem aceitar o trabalho que está 
fora da sua competência. 
Direitos de propriedade intelectual 
 Engenheiros devem estar cientes das leis locais que regulam o uso da propriedade intelectual, como patentes, 
direitos autorais, etc. Eles devem ser cuidadosos para assegurar que a propriedade intelectual de empregadores e 
clientes sejam protegidas. 
Uso indevido de computador 
Os engenheiros de software não devem usar suas habilidades técnicas para uso indevido de computadores de 
outras pessoas. Uma gama de uso indevido do computador vai do uso de um simples jogo de computador até uma 
gravíssima como disseminação de vírus. 
Questionário: 
1. Engenharia de Sistemas é igual à Engenharia de Software? 
2. Assinale a alternativa abaixo que não é considerada no ciclo de desenvolvimento de um sistema. 
a. Operação, custos e cronogramas; 
b. Performance, treinamento e suporte; 
c. Treinamento, vendas e entrega; 
d. Teste, instalação e fabricação; 
3. Defina processo de software. 
4. Quais são os atributos de um bom software? 
5. Explique duas questões de responsabilidade profissional. 
 
 
Análise de Sistemas 2014
 
Prof. Gunther Graf Jr. Página 5 
 
2. Conceitos de Análise de Sistema Estruturado 
A etapa de análise e especificação de requisitos, geralmente chamada de análise de sistemas, é um processo de 
comunicação entre engenheiros de software (analistas de sistemas) e clientes/usuários do sistema, com o objetivo 
de definir detalhadamente o propósito e os requisitos de um software. Os requisitos de um sistema compreendem o 
conjunto de características que o sistema deve possuir para atingir seu propósito. 
A análise de sistemas é um processo de transmissão de conhecimento e, assim sendo, envolve três etapas: 
 Aprendizado: aprender sobre o domínio do problema onde o sistema será inserido; 
 Estruturação e representação dos requisitos: consiste na modelagem do sistema propriamente dita; 
 Validação dos requisitos com o usuário. 
Ao longo do processo, o analista enfrenta o desafio de “lidar com a complexidade”, isto é, situações complexas 
do mundo real devem ser entendidas e representadas de forma simples, para facilitar a compreensão e validação. 
Para tal, é preciso delimitar a área de estudo, subdividir o todo complexo em partes inteligíveis e gerenciáveis, 
extrair as características essenciais da realidade e modelar essas características para mostrar o relacionamento entre 
seus componentes. 
A análise de sistemas é, em última instância, uma atividade de construção de modelos. Um modelo é uma 
representação de alguma coisa do mundo real, uma abstração da realidade, ou seja, representa uma seleção de 
características do mundo real, que são relevantes para opropósito com o qual o modelo foi construído. 
Modelos são ferramentas fundamentais no desenvolvimento de sistemas. Sistemas são modelados para: 
 Possibilitar o estudo do comportamento do sistema; 
 Facilitar a comunicação entre os componentes da equipe de desenvolvimento (e clientes e usuários); 
 Possibilitar a discussão de correções e modificações com o usuário; 
 Formar uma documentação do sistema. 
Um modelo enfatiza um conjunto de características da realidade, que corresponde à dimensão do modelo. Além 
disso, modelos possuem níveis de abstração. O nível de abstração de um modelo diz respeito ao grau de 
detalhamento com que as características do sistema são representadas. Em cada nível há uma ênfase seletiva nos 
detalhes representados. No caso dos sistemas de informação, geralmente, são considerados três níveis: 
 Conceitual: considera características do sistema independentes do ambiente computacional (hardware e 
software) no qual o sistema será implementado. Essas características são dependentes unicamente das 
necessidades do usuário. 
 Lógico: características dependentes de um determinado tipo de sistema computacional. Essas características 
são, contudo, independentes de produtos específicos. 
 Físico: características dependentes de um sistema computacional específico, isto é, uma linguagem e um 
compilador específico, um sistema gerenciador de bancos de dados específico, o hardware de um 
determinado fabricante, etc. 
Nas primeiras etapas do processo de desenvolvimento (levantamento de requisitos e análise), o engenheiro de 
software representa o sistema através de modelos conceituais. Nas etapas posteriores, as características lógicas e 
físicas são representadas em novos modelos. 
 
 
Análise de Sistemas 2014
 
Prof. Gunther Graf Jr. Página 6 
 
Modelos 
A Análise Estruturada sugere a construção de dois modelos principais: 
 Modelo Ambiental: define a fronteira entre o sistema e o resto do mundo. 
 Modelo Comportamental: define o comportamento das partes internas do sistema necessário para interagir 
com o ambiente. 
O Modelo Ambiental 
Representa o que o sistema deve fazer para atender ao ambiente. É composto dos seguintes produtos: 
 Propósito do Sistema: enuncia a finalidade do sistema. Pode ser acompanhado de uma breve descrição do 
contexto do sistema (minimundo). 
 Lista de Eventos: lista de eventos aos quais os sistemas devem responder. Deve conter, pelo menos, o nome 
do evento, o estímulo e a resposta externa do sistema. 
 Diagrama de Contexto: representa o sistema como um único processo e suas interações com o ambiente. 
Pode ser acompanhado de um dicionário de dados. 
A declaração de propósito (objetivos) do sistema deve ser elaborada em poucas frases simples e precisas, em 
linguagem destituída de vocabulário técnico, de modo a ser entendida pelos usuários do sistema e pela 
administração da empresa, em geral. Não deve fornecer detalhes sobre como o sistema deverá operar. 
A elaboração da lista de eventos é o passo principal desta etapa do desenvolvimento, uma vez que os eventos 
constituem a parte fundamental de um sistema. De fato, o primeiro passo na especificação de um sistema é 
identificar aos quais eventos do mundo exterior ele deverá ocorrer. 
Uma vez definidos os eventos, é possível construir o Diagrama de Contexto do sistema, mostrando como ele 
responde a todos os eventos externos relevantes. Finalmente, pode ser útil elaborar uma descrição de como o 
sistema responderá a cada um dos eventos identificados na Lista de Eventos. 
 
O Modelo Comportamental 
Representa o que o interior do sistema deve fazer para atender ao ambiente. Deve conter os seguintes 
produtos: 
 Diagrama de Fluxo de Dados (DFD): representação gráfica do "fluxo" de dados; 
 Dicionário de Dados (DD): descreve os dados representados no MER, nos DFDs e nos DTEs; 
 Diagrama de Entidades e Relacionamentos (DER): modelo diagramático que descreve o modelo de dados de 
um sistema com alto nível de abstração. 
 Modelo de Entidade Relacionamento (MER): a finalidade é descrever, de maneira conceitual, os dados a 
serem utilizados; 
 Especificação da Lógica dos Processos (EP): descreve a lógica dos processos do DFD que não foram 
detalhados em diagramas de nível inferior (lógica dos processos primitivos). 
 Diagrama de transição de Estados (DTE): representação do estado ou situação em que um objeto pode se 
encontrar no decorrer da execução de processos de um sistema 
 
Análise essencial 
A análise essencial é uma evolução da análise estruturada. A principal diferença entre a Análise Essencial e a 
Análise Estruturada está na estratégia para atacar o problema: a primeira defende uma abordagem baseada em 
eventos, onde a Análise de Eventos passa a ser um passo fundamental, a segunda é baseada apenas na 
decomposição top-down da funcionalidade do sistema. 
http://pt.wikipedia.org/wiki/Diagrama
http://pt.wikipedia.org/wiki/Modelagem_de_dados
http://pt.wikipedia.org/wiki/Abstra%C3%A7%C3%A3o
Análise de Sistemas 2014
 
Prof. Gunther Graf Jr. Página 7 
 
Questionário: 
1. Cite os modelos da análise estruturada. 
2. O que significa DFD? Para que serve? 
3. Quais os níveis de abstração dos sistemas de informação? 
4. Quais as etapas da Análise de Sistemas? Explique. 
5. Explique a diferença entre Análise Essencial x Análise Estruturada. 
 
Análise de Sistemas 2014
 
Prof. Gunther Graf Jr. Página 8 
 
3. Estudo de viabilidade 
ntes de se avançar com uma análise mais detalhada dos requisitos de um projeto, deve ser feito um estudo 
de viabilidade. 
Tal como o nome sugere, pretende-se com este estudo avaliar se, de um ponto de vista tecnológico e 
organizacional, o projeto é viável. 
Uma forma de avaliar a viabilidade de um projeto é obter, através da interação com "as partes interessadas" 
(ou stakeholder em inglês) do projeto (em reuniões ou entrevistas, por exemplo), a resposta às seguintes questões: 
 Será que o sistema contribui para os objetivos da organização? 
 Dadas as restrições tecnológicas, organizacionais (econômicas, políticas, ambientais, recursos disponíveis) e 
temporais associadas ao projeto, será que o sistema pode ser implementado? 
 Caso haja necessidade de integração entre diferentes sistemas, será que esta é possível? 
A questão mais crítica é a primeira, já que um sistema que não contribua para os objetivos da organização não lhe 
traz qualquer valor acrescentado e como tal a sua existência não se justifica. Apesar de parecer óbvia, são 
frequentemente desenvolvidos sistemas que não contribuem para os objetivos das respectivas organizações, quer 
seja por interesses externos (políticos ou organizacionais) ou por falta de clareza na definição dos objetivos da 
organização. 
Deve, portanto identificar-se que informação é necessária para responder a estas questões e quem possui esta 
informação, procedendo-se de seguida à recolha de todos os dados disponíveis para clarificar ao máximo o âmbito 
do projeto e avaliar a sua viabilidade. 
Tipicamente, quem poderá fornecer esta informação serão os usuários dos sistemas atuais e do sistema a 
implementar, os responsáveis pelos departamentos nos quais o sistema será usado, técnicos que estejam 
familiarizados com as tecnologias envolvidas (do novo sistema e dos sistemas existentes), responsáveis pela 
manutenção futura do sistema a implementar e, de um modo geral, todos aqueles que terão qualquer tipo de 
interação com o novo sistema (ou que sejam por ele afetados). 
Algumas das questões que podem ser postas nesta coleta de informações são, por exemplo: 
 Se o novo sistema não fosse implementado, quais seriam as alternativas para a organização? 
 Quais são os problemas que os sistemas atuais apresentam e como é que um sistema novo irá resolver estas 
falhas? 
 De que forma é que o sistema irá contribuir diretamente para os objetivos da organização? 
 É possível a integração com os outros sistemas da organização (de umponto de vista tecnológico)? Com que 
facilidade é que se consegue partilhar informação entre estes sistemas? 
O estudo de viabilidade deverá culminar com a produção de um relatório e deverá determinar a continuação do 
desenvolvimento do projeto, tornando mais claras as restrições (econômicas, temporais e organizacionais) do 
projeto e definindo mesmo alguns requisitos de alto nível. 
 
 
A 
http://pt.wikipedia.org/wiki/Stakeholder
Análise de Sistemas 2014
 
Prof. Gunther Graf Jr. Página 9 
 
4. Especificação de Requisitos 
Princípios 
imos que o software é parte de um sistema computacional mais abrangente e que a Análise de Sistemas é a 
atividade de identificar os problemas do domínio, apresentar alternativas de soluções e o estudo da 
viabilidade de cada uma delas. Uma vez que se tenha feito a análise do sistema computacional, e delimitado 
o escopo do software, os requisitos do software devem ser analisados e especificados. 
A análise e especificação de requisitos de software envolve as atividades de determinar os objetivos de um 
software e as restrições associadas a ele. Ela deve também estabelecer o relacionamento entre estes objetivos e 
restrições e a especificação precisa do software. 
A análise e especificação dos requisitos de software deve ser vista como uma sub-atividade da análise de sistemas. 
Normalmente ela é iniciada juntamente com a análise do sistema, podendo se estender após a elaboração do 
documento de especificação do sistema e do planejamento do desenvolvimento, quando serão refinados os 
requisitos do software. 
Análise e especificação são atividades inter dependentes e devem ser realizadas conjuntamente. A análise é o 
processo de observação e levantamento dos elementos do domínio no qual o sistema será introduzido. Deve-se 
identificar as pessoas, atividades, informações do domínio para que se possa decidir o que deverá ser informatizado 
ou não. Pessoas e as atividades que não serão informatizadas deverão ser consideradas entidades externas ao 
software. 
A especificação é a descrição sistemática e abstrata do que o software deve fazer, a partir daquilo que foi analisado. 
Ela apresenta a solução de como os problemas levantados na análise serão resolvidos pelo software do sistema 
computacional. Visa descrever de maneira sistemática quais as propriedades funcionais são necessárias para 
resolver o problema do domínio. A especificação é também a forma de comunicação sistemática entre analistas e 
projetistas do software. 
O objetivo da definição dos requisitos é especificar o que o sistema deverá fazer e determinar os critérios de 
validação que serão utilizados para que se possa avaliar se o sistema cumpre o que foi definido. 
 
V 
Análise de Sistemas 2014
 
Prof. Gunther Graf Jr. Página 10 
 
Requisitos funcionais e não funcionais 
omo sistemas computacionais são construídos para terem utilidade no mundo real. Modelar uma parte do 
mundo real, o domínio de aplicação é uma atividade extremamente importante para se compreender a 
necessidade e a importância do sistema a ser construído e definir os requisitos que tornam o sistema útil. 
Requisitos são objetivos ou restrições estabelecidas por clientes e usuários do sistema que definem as diversas 
propriedades do sistema. Os requisitos de software são, obviamente, aqueles dentre os requisitos de sistema que 
dizem respeito a propriedades do software. 
Um conjunto de requisitos pode ser definido como uma condição ou capacidade necessária que o software deve 
possuir (1) para que o usuário possa resolver um problema ou atingir um objetivo ou (2) para atender as 
necessidades ou restrições da organização ou dos outros componentes do sistema. 
Tradicionalmente, os requisitos de software são separados em requisitos funcionais e não-funcionais. Os requisitos 
funcionais são a descrição das diversas funções que clientes e usuários querem ou precisam que o software ofereça. 
Eles definem a funcionalidade desejada do software. O termo função é usado no sentido genérico de operação que 
pode ser realizada pelo sistema, seja através comandos dos usuários ou seja pela ocorrência de eventos internos ou 
externos ao sistema. 
São exemplos de requisitos funcionais: 
 "o software deve possibilitar o cálculo dos gastos diários, semanais, mensais e anuais com pessoal". 
 "o software deve emitir relatórios de compras a cada quinze dias". 
 "os usuários devem poder obter o número de aprovações, reprovações e trancamentos em todas as 
disciplinas por um determinado período de tempo”. 
A especificação de um requisito funcional deve determinar o que se espera que o software faça, sem a preocupação 
de como ele faz. É importante diferenciar a atividade de especificar requisitos da atividade de especificação que 
ocorre durante o design do software. No design do software deve-se tomar a decisão de quais a funções o sistema 
efetivamente terá para satisfazer àquilo que os usuários querem. 
Requisitos não-funcionais são as qualidades globais de um software, como manutenibilidade, usabilidade, 
desempenho, custos e várias outras. Normalmente estes requisitos são descritos de maneira informal, de maneira 
controversa (por exemplo, o gerente quer segurança, mas os usuários querem facilidade de uso) e são difíceis de 
validar. 
São exemplos de requisitos não-funcionais: 
 "a base de dados deve ser protegida para acesso apenas de usuários autorizados". 
 "o tempo de resposta do sistema não deve ultrapassar 30 segundo". 
 "o software deve ser operacionalizado no sistema Linux" 
 "o tempo de desenvolvimento não deve ultrapassar seis meses". 
A necessidade de se estabelecer os requisitos de forma precisa é crítica na medida em que o tamanho e a 
complexidade do software aumentam. Os requisitos exercem influência uns sobre os outros. Por exemplo, o 
requisito de que o software deve ter grande portabilidade (por exemplo, ser implementado em Java) pode implicar 
em que o requisito desempenho não seja satisfeito (programas em Java são, em geral, mais lentos). 
C 
Análise de Sistemas 2014
 
Prof. Gunther Graf Jr. Página 11 
 
Requisitos de usuário e sistema 
equisitos de usuário são declarações em linguagem natural acompanhadas de diagramas intuitivos de quais 
serviços são esperados do sistema e das restrições sob as quais ele deve operar. Devem estar em um nível de 
abstração mais alto, de modo que sejam compreensíveis pelos usuários do sistema que não possuem 
conhecimento técnico Requisitos de Sistema: definem detalhadamente as funções, serviços e restrições do 
sistema. São versões expandidas dos requisitos de usuário usados pelos desenvolvedores para projetar, implementar 
e testar o sistema. Como requisitos de sistema são mais detalhados, as especificações em linguagem natural são 
insuficientes e para especificá-los, notações mais especializadas devem ser utilizadas. 
Exemplos: 
 Requisitos de Usuário 
o Será exigido do usuário uma senha e login para acessar o sistema do banco. 
 Requisitos do Sistema 
o Para logar no sistema o usuário deverá introduzir seu cartão do banco no leitor magnético, onde o 
sistema validará o mesmo e permitindo que o usuário digite o número de sua conta bancária e a 
senha de 6 dígitos fornecida pelo banco. 
o Caso a senha e número de conta estejam em ordem o sistema deverá pedir as 3 letras de segurança 
também fornecida pelo banco. 
o Caso o usuário erre a senha ou as letras por mais de 3 tentativas, o sistema bloqueia a conta do 
mesmo, onde será desbloqueada somente com seu gerente de contas. 
o Cada vez que o usuário entrar no sistema deverá ficar registrado tal evento. 
 
 
R 
Análise de Sistemas 2014
 
Prof. Gunther Graf Jr. Página 12 
 
Técnicas para levantamento de requisitos: 
BrainStorming: É utilizado normalmente em workshops. Após os workshops serão produzidas documentações que 
refletem os requisitos e decisões tomadas sobre o sistema a ser desenvolvido. Seu objetivo é uma apresentação do 
problema/necessidadea um grupo específico, requerendo assim soluções. 
Principais Vantagens Principais Desvantagens 
1) Várias pessoas pensam melhor do que uma 
(grupo pensante); 
2) Rompe a inibição de ideias; 
3) Generaliza a participação do membros do 
grupo. 
1) Disponibilidade de todos pode inviabilizar o 
levantamento de dados. 
 
Entrevista é uma das técnicas tradicionais mais simples de utilizar e que produz bons resultados na fase inicial de 
obtenção de dados. Convém que o entrevistador dê espaço ao entrevistado para esclarecer as suas necessidades. É 
uma discussão do projeto desejado com diferentes grupos de pessoas. 
Principais Vantagens Principais Desvantagens 
1) Com um plano geral bem elaborado, o 
analista terá facilidade em descobrir que 
informação o usuário está mais interessado e 
usar um estilo adequado ao entrevistar; 
2) Poder alterar o curso da entrevista de forma a 
obter informações sobre aspectos importantes 
que não tinham sido previstos no planejamento 
da entrevista; 
3) Poder alterar a ordem sequencial das 
perguntas; 
4) Poder eliminar perguntas anteriormente 
planejadas; 
5) Poder incluir perguntas que não estavam na 
programação da entrevista; 
6) Poder motivar o entrevistado no decorrer do 
processo; 
1) Podem ocorrer desvios de curso, no decorrer 
da entrevista; 
2) Consumir mais tempo e recursos com sua 
realização; 
3) Tratamento diferenciado para os 
entrevistados; 
4) É necessário ter um plano de entrevista para 
que não haja dispersão do assunto principal e a 
entrevista fique longa, deixando o entrevistado 
cansado e não produzindo bons resultados; 
5) O usuário tem dificuldade de concentração 
em reuniões muito longas; 
6) O entrevistado pode não saber expressar 
corretamente suas necessidades ao analista. 
 
 
Análise de Sistemas 2014
 
Prof. Gunther Graf Jr. Página 13 
 
Questionários diferentemente da entrevista, essa técnica é interessante quando temos uma quantidade grande de 
pessoas para extrair as mesma informações. As questões são dirigidas por escrito aos participantes com o objetivo 
de ter conhecimento sobre opiniões das mesmas questões. São autoaplicáveis, pois o próprio informante responde. 
Principais Vantagens Principais Desvantagens 
1) Atinge um grande número de pessoas; 
Menores custos; 
2) Permite que os participantes respondam no 
momento em que acharem conveniente; 
1. 3) Questões padronizadas garantem 
uniformidade. 
1) Não há garantia de que a maioria dos 
participantes respondam o questionário; 
2) Os resultados são bastante críticos em relação 
ao objetivo, pois as perguntas podem ter 
significados diferentes a cada participante 
questionado. 
 
Observação (Observation): A técnica resume-se em visitar o local em foco com a finalidade de observação do 
mesmo. Permitindo assim, coletar informações de acordo com o cotidiano das operações e execução dos processos 
diários do local. 
Principais Vantagens Principais Desvantagens 
1) Capaz de captar o comportamento natural das 
pessoas; 
2) Nível de intromissão relativamente baixo; 
3) Confiável para observações com baixo nível de 
inferência. 
1) Polarizada pelo observador; 
2) Requer treinamento especializado; 
3) Efeitos do observador nas pessoas; 
4) Não comprova/esclarece o observado; 
5) Número restrito de variáveis. 
 
 
Análise de texto é o estudo e reutilização de documentação de diferentes naturezas, para a identificação de 
requisitos a serem implementados no sistema que se está modelando. Uma grande variedade de documentação 
pode ser analisada incluindo estrutura organizacional da empresa, padrões de mercado, leis, manuais de usuário, 
relatório de pesquisas de mercado, glossário de termos de negócio, etc. 
Principais Desvantagens 
Documentos com problemas podem levar a uma falha na 
definição dos requisitos; 
 
 
Reutilização de requisitos é o estudo e reutilização de especificações e glossários referente a projetos de sistemas 
legados ou sistemas de mesma família (com funcionalidades de negócio similares). 
Principais Vantagens 
1) Economia de tempo e dinheiro: Estudos tem mostrado que sistemas similares podem reutilizar 
acima de 80% de seus requisitos; Pode levar a uma reutilização adicional de outros itens em outras 
atividades do ciclo de vida de desenvolvimento (ex.: reuso do design de componentes já existentes, 
testes e código fonte); 
2) Redução de risco: Requerimentos reutilizados tem uma chance maior de serem compreendidos 
pelos stakeholders visto que já são conhecidos de certa forma; 
Análise de Sistemas 2014
 
Prof. Gunther Graf Jr. Página 14 
 
 
Prototipação 
O uso de prototipagem é feito em diversas fases do processo de engenharia de requisitos (por exemplo na 
identificação, análise e validação). Trata-se de uma versão inicial do sistema, baseada em requisitos ainda pouco 
definidos, mas que pode ajudar a encontrar desde cedo falhas que através da comunicação verbal não são tão 
facilmente identificáveis. Neste tipo de abordagem apenas são desenvolvidas algumas funcionalidades sendo 
normalmente desenvolvidas primeiro, aquelas que são mais fáceis de compreender por parte do utilizador e que lhe 
podem trazer maior valor acrescentado (principalmente na prototipagem evolutiva, isto é, aquela que mais tarde é 
evoluída para a fase de desenvolvimento). O uso de protótipos deve ser considerado apenas mediante uma análise 
custo-benefício, já que os custos de desenvolvimento de um protótipo podem facilmente crescer, sendo 
particularmente úteis em situações em que a interface com os usuários é, para eles, um aspecto crítico. 
 
 
http://pt.wikipedia.org/w/index.php?title=Prototipagem&action=edit&redlink=1
Análise de Sistemas 2014
 
Prof. Gunther Graf Jr. Página 15 
 
Questionário 
1. Defina estudo de viabilidade. 
2. Compare análise x especificação (de requisitos). 
3. Existem algumas técnicas padrão para fazer o levantamento de requisitos de um sistema. Assinale a opção 
abaixo que contém uma técnica incorreta: 
a. Brainstorming. 
b. Brainraining. 
c. Observação. 
d. Análise de texto. 
e. Reutilização de requisitos. 
4. Cite e explique as técnicas de levantamento de requisitos entrevista e questionário. 
5. O que é prototipação?