Análise de Sistemas · PDF fileEstudo 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

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



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/



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



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.



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 o propó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.



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



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.



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 um ponto 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



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



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



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



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/necessidade a 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.


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.



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.


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.


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;



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



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?

Documents

Análise de Sistemas · PDF fileEstudo 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