Tecnologia da Informação – Engenharia de

Requisitos

Engenharia de
Requisitos

[Ano]
Conteúdo
Conteúdo.................................................................................................................................. 2
Engenharia de Requisitos......................................................................................................... 3
Técnicas de elicitação de requisitos......................................................................................3
[editar] Os princípios.......................................................................................................... 8
[editar] Directrizes.................................................................................................................9
[editar] Preparação............................................................................................................9
[editar] Estudo.................................................................................................................... 9
[editar] Análise................................................................................................................... 9
[editar] Especificação......................................................................................................... 9
Técnicas de validação de requisitos....................................................................................12
Prototipação........................................................................................................................ 13
 Engenharia de Requisitos
A engenharia de requisitos é a primeira etapa dentro de todo o processo da engenharia de
software, a qual estuda como coletar, entender, armazenar, verificar e gerenciar os requisitos. A
principal preocupação na engenharia de requisitos é entender quais são os reais requisitos do
sistema, bem como a documentação dos mesmos.
As fases da Engenharia de Requisitos são: elicitação, análise, especificação, verificação e
gerenciamento. Elicitação: é o processo através do qual clientes e usuários são questionados por um
desenvolvedor para falarem “o quê” o software deve fazer (ou seja, os requisitos). Análise: é o
processo onde são analisadas as necessidades dos clientes e usuários para se chegar na definição dos
requisitos de software. Especificação: é o processo de criação de um documento no qual estão
definidos todos os requisitos analisados. Verificação: é o processo que busca assegurar que a
especificação de requisitos de software está em concordância com os requisitos elicitados e
analisados nas fases anteriores, ou seja, estão de acordo com o desejo do cliente. Gerenciamento: é o
planejamento e controle da atividade de elicitação, especificação, análise e verificação dos
requisitos.

Técnicas de elicitação de requisitos

O sucesso de um sistema de informação depende da qualidade da definição dos requisitos. No
processo de desenvolvimento, a etapa mais importante, e que serve de base as outras é a etapa de
elicitação de requisitos. Ou seja, a etapa onde são extraídos e analisados dados do projeto, suas
especificações, características, propriedades e funcionalidades.
Descobrir o que o usuário realmente necessita é uma das tarefas mais difíceis do processo de
desenvolvimento de software. Isso porque requer uma análise criteriosa da organização,
compreendendo: a definição do alvo e da abrangência do domínio da aplicação, o entendimento do
foco no problema a resolver (o quê, para quê e para quem), a identificação de processos do negócio e,
principalmente o conhecimento da informação do cliente relativa às suas necessidades ou desejos e
exigências.
Apesar da extração dos requisitos ser a primeira etapa em engenharia de requisitos, ela não
acontece só uma vez, pois é um processo iterativo, onde todas as outras etapas podem conter
extração e analise dos requisitos, podendo acontecer sempre que o analista julgar necessário.
O levantamento de requisitos é a fase que compreende o período em que o engenheiro de
requisitos procura entender o problema e a necessidade do usuário. Um grande contingente de
problemas em projetos de desenvolvimento de software está relacionado à obtenção de requisitos,
entre esses podemos citar: (a) usuário não possui o conhecimento suficiente sobre o sistema
requerido, ou não sabe como se expressar; (b) conflito entre usuário e desenvolvedor sobre
diferentes pontos de vista; (c) falta de comunicação usuário/desenvolvedor; (d) problemas
comportamentais; entre outros.
É comum que o processo de elicitação continue mesmo depois do inicio do desenvolvimento do
sistema, e sofra mudanças a qualquer momento. Porém, uma mutação constante de requisitos, durante
o processo de elicitação ou depois de iniciado o desenvolvimento do sistema, causam complicações,
obrigando o desenvolvedor a fazer alterações no sistema, chegando a atrasar a conclusão do projeto.
Para extinguir ou, ao menos, reduzir os problemas no processo de extração de requisitos, foram
desenvolvidas técnicas auxiliares, essas técnicas servem como base para a elicitação dos requisitos,
tornando-a mais completa e confiável.
 As técnicas de elicitação de requisitos são divididas em formais e informais, onde as
técnicas que pressupõe a construção de um modelo formal, conceitual do problema que está
sendo analisado ou de um protótipo do produto a ser construído são consideradas formais, e as
técnicas que se baseiam em interações com o usuário e comunicação estruturada são
consideradas informais. Dentre as principais técnicas temos:
Entrevista: É a técnica mais comum e mais utilizada na coleta de fatos, pois nada
mais é do que a comunicação entre entrevistado (cliente) e entrevistador (engenheiro de
requisitos). O engenheiro de requisitos ou analista discute o sistema com diferentes
stakeholders e obtêm um entendimento dos requisitos. Entrevistadores devem estar cientes
da política organizacional - muitos requisitos reais podem não serem discutidos devido as
implicações políticas.
A vantagem dessa técnica é que têm-se o contato direto com o usuário e validação
imediata do requisito a ser especificado. A desvantagem encontrada é a barreira encontrada
no desenvolvimento da entrevista devido ao conhecimento tácito e diferenças de cultura.
Dica: Conhecimento tácito é aquele que o indivíduo adquiriu ao longo da vida, que está
na cabeça das pessoas. Geralmente é difícil de ser formalizado ou explicado a outra
pessoa, pois é subjetivo e inerente às habilidades de uma pessoa.
Há basicamente três tipos de entrevista: a) entrevistas fechadas onde o engenheiro de
requisitos procura as perguntas para um conjunto pré-definido de questões; b) entrevistas
abertas onde não há agenda pré definida e o engenheiro de requisitos discute, de modo
aberto, o que os usuários querem do sistema; c) tutorial: onde o cliente está no comando e
apresenta o conteúdo como se estivesse dando uma aula.
Brainstorming: Brainstorming são as reuniões na qual participam todos os envolvidos na
idealização do produto, como os analistas, clientes e usuários finais. O formato dessa reunião
é um pouco diferente das demais. Pois todos os envolvidos devem expor suas idéias e
necessidades em relação ao produto/serviço, da maneira que vier em sua cabeça, sem a
necessidade de formar a idéia toda. Após todos exporem suas idéias de maneira bagunçada, é
hora de organizá-las e verificar o que é realmente importante para o momento, ou o que ficará
para futuras reuniões. Há muitas situações que em que muitas idéias iguais são vistas de
maneiras diferentes, fornecendo mais informações para o analista e consequentemente,
oferecendo uma documentação mais completa. Ocorrem em um grupo de 6 a 12 pessoas, com a
presença de um moderador, que é quem gerencia toda a discussão. Uma das desvantagens
dessa técnica é que pode demorar para se conseguir um idéia, ou um conjunto delas, que
resolva o problema.
JAD: (Joint Application Design): Muitas vezes, quando um grupo de informática entrega um
sistema de informação aos seus clientes escuta a frase: “não era isso que eu queria!” Isto
acontece porque os desenvolvedores não conseguiram levantar com os usuários suas
verdadeiras necessidades.
Para enfrentar os problemas de comunicação entre desenvolvedores e usuários, foram
desenvolvidos, ao final da década de 1970, vários métodos onde o desenvolvimento de
sistemas é baseado na dinâmica de grupo.
Na forma tradicional de desenvolver sistemas os analistas entrevistam os usuários, um
após outro, tomando notas que são mais tarde consolidadas e então validadas com o usuário,
finalmente se transformando em um documento de análise.
O JAD, Joint Application Design, ou Método de Projeto Interativo, substitui as
entrevistas individuais por reuniões de grupo, onde participam representantes dos usuários e
os representantes dos desenvolvedores.
 Essa técnica é utilizada para promover cooperação, entendimento e trabalho em grupo
entre os usuários desenvolvedores. O JAD facilita a criação de uma visão compartilhada do
que o produto de software deve ser. Através da sua utilização os desenvolvedores ajudam os
usuários a formular problemas e explorar soluções. Dessa forma, os usuários ganham um
sentimento de envolvimento, posse e responsabilidade com o sucesso do produto.
A técnica JAD é composta de duas etapas principais: planejamento, que tem por
objetivo elicitar e especificar os requisitos; e projeto, em que se lida com o projeto de
software. - Cada etapa consiste em três fases: adaptação, sessão e finalização. A fase de
adaptação consiste na preparação para a sessão, ou seja, organizar a equipe, adaptar o
processo JAD ao produto a ser construído e preparar o material. Na fase de sessão é
realizado um ou mais encontros estruturados, envolvendo desenvolvedores e usuários onde os
requisitos são desenvolvidos e documentados. A fase de finalização tem por objetivo
converter a informação da fase de sessão em sua forma final (um documento de especificação
de requisitos).
Há seis tipos de participantes, embora nem todos participem de todas as fases:
• Líder da sessão: é responsável pelo sucesso do esforço, sendo o facilitador dos
encontros. Deve ser competente, com bom relacionamento pessoal e qualidades
gerenciais de liderança;
• Engenheiro de requisitos: é o participante diretamente responsável pela produção
dos documentos de saída das sessões JAD. Deve ser um desenvolvedor experiente
para entender as questões técnicas e detalhes que são discutidos durante as
sessões e ter habilidade de organizar idéias e expressá-las com clareza;
• Executor: é o responsável pelo produto sendo construído. Tem que fornecer aos
participantes uma visão geral dos pontos estratégicos do produto de software a ser
construído e tomar as decisões executivas, tais como alocação de recursos, que
podem afetar os requisitos e o projeto do novo produto;
• Representantes dos usuários: são as pessoas na empresa que irão utilizar o produto
de software. Durante a extração de requisitos, os representantes são
frequentemente gerentes ou pessoas-chave dentro da empresa que tem uma visão
melhor do todo e de como ele será usado;
• Representantes de produtos de software: são pessoas que estão bastante
familiarizadas com as capacidades dos produtos de software. Seu papel é ajudar os
usuários a entender o que é razoável ou possível que o novo produto faça;
• Especialista: é a pessoa que pode fornecer informações detalhadas sobre um tópico
específico.
QFD (Quality Function Deployment): A definição mais genérica e tradicional do QFD é um
método de sistemático de projetar a qualidade de um produto ou serviço. Ele traduz as
necessidades do cliente em características do produto ou serviço. Porém sua aplicação pode
ser muito mais ampla do que essa definição tradicional indica. Seus princípios são tão gerais,
que ele pode ter vários tipos de aplicações.
Sua origem remonta no movimento da gestão da qualidade total (TQM), que evolui da
garantia da qualidade pela inspeção, para a garantia da qualidade pelo controle do processo e
cada vez mais a ênfase atual é na garantia da qualidade no desenvolvimento de produtos. E
considera-se essa prática um avanço do desenvolvimento de produtos.
No início era somente uma técnica para desdobrar por meio de matrizes as
necessidades dos clientes em características técnicas de produto. Hoje o conceito de QFD é
bem mais amplo e se divide em dois grupos o QFDr (quality function deployment in a
restricted sense) e o QD (quality deployment). O QFDr, também conhecido em português
como o processo gerencial de desenvolvimento do produto orientado para cliente, é um modelo
de referência para gestão do desenvolvimento de produtos. Ou seja, o QFDr define as
atividades e padrões para se realizar o processo de desenvolvimento de produtos (PDP). O
QD, desdobramento da qualidade, corresponde à técnica original.
Os elementos principais do QD são as tabelas, matrizes e modelo conceitual.
A tabela é o elemento que pode representar de forma hierárquica diversas características
envolvidas no QD, que podem ser tanto entradas como saídas, por exemplo: requisitos dos
clientes, do produto, do processo etc.
As matrizes relacionam duas tabelas. Por meio de um conjunto de matrizes parte-se dos
requisitos expostos pelos clientes e realiza-se um processo de desdobramento
transformando-os em especificações técnicas do produto. As matrizes servem de apoio para o
grupo orientando o trabalho, registrando as discussões, permitindo a avaliação e priorização
de requisitos e características e, ao final, será uma importante fonte de informações para a
execução de todo o projeto.
Neste trabalho com as matrizes realizam-se algumas operações básicas de extração, relação e
conversão, em que:
• a extração é o processo de criar uma tabela a partir de outra, ou seja, de utilizar os
elementos de uma tabela como referência para se obter os elementos de outra tabela.
• a relação é o processo de identificar a intensidade do relacionamento entre os dados
das duas tabelas que compõem a matriz.
• a conversão é o processo de quantificar a importância relativa dos dados de uma tabela
em função da intensidade da relação destes com os dados da outra tabela. Nesse
processo é também considerada a importância relativa dos dados que compõem a tabela
que será convertida.
O modelo conceitual relaciona as tabelas e matrizes. Define a sequência de desdobramentos.
Pode-se realizar desdobramentos relacionados com a qualidade do produto (característica de
qualidade ou qualidade projetada), com a tecnologia (processo de fabricação), com o custo e
com a confiabilidade.
Na definição de uma aplicação específica do QD, o primeiro passo é definir o modelo
conceitual, ou seja, quais desdobramentos serão realizados.
A força do QFD está em tornar explícitas as relações entre necessidades dos clientes,
características do produto e parâmetros do processo produtivo, custos, confiabilidade
permitindo a harmonização e priorização das várias decisões tomadas durante o processo de
desenvolvimento do produto, bem como em potencializar o trabalho de equipe.
Outro aspecto importante a considerar é que, por ser um método que se baseia no trabalho
coletivo, os membros da equipe desenvolvem uma compreensão comum sobre as decisões, suas
razões e suas implicações, e se tornam comprometidos com iniciativas de implementar as
decisões que são tomadas coletivamente.
QFD é baseada em sessões nas quais os grupos de interesse trabalham em torno de uma
matriz (“casa da qualidade”) que relaciona requisitos de usuários com os atributos desejados
para o projeto. Isso permite a identificação das relações entre requisitos e os atributos da
qualidade necessários ao processo de maximização da satisfação do cliente com um projeto de
engenharia. A similaridade dos procedimentos da fase de planejamento do QFD com as
atividades de Elicitação de Requisitos justifica a afirmação contida em Christel [92] sobre a
facilidade de adaptação dos passos daquela em procedimento para essa. Como características
importantes dessa abordagem Macaulay [96] cita, entre outras, o apoio às atividades de
identificação e especificação de atributos de qualidade, às descrições de usuários e grupos de
usuários típicos e à identificação de requisitos de produtos genéricos. O QFD é usado em
Brynjolfsson [96] para construir a “Matriz de Mudanças”, ferramenta proposta para
identificar as interações - e o grau de estabilidade existente nessas interações - entre os
processos que ocorrem durante a mudança e assim detectar interferências, pontos sensíveis e
otimizar o planejamento das atividades de transição. Adiano [xx] propõe um QFD Dinâmico
que vem ao encontro de uma das necessidades mais importantes de um plano de implantação
de TQM: a incorporação ao processo – em tempo real - da evolução das expectativas e
necessidades dos usuários. A proposta implementa o QFD Dinâmico como um sistema de apoio
à decisão, onde laços de realimentação e sistemas de monitoração combinam dados sobre
satisfação dos usuários, controle estatístico de processo e atributos de qualidade.
Parâmetros do processo são atualizados, dinamicamente, em função de medidas realizadas
continuamente sobre indicadores relacionados a atributos de qualidade quantificados sob o
ponto de vista dos usuários.
Workshop de Requisitos: Conduzir um workshop de requisitos implica reunir todos os
envolvidos durante um período intensivo, concentrado. Um Analista de Sistemas atua como um
facilitador da reunião. Todos os participantes deverão contribuir ativamente e os resultados
da sessão deverão ser disponibilizados imediatamente para eles.
O workshop de requisitos fornece um framework para aplicar as outras técnicas de
identificação como, por exemplo, brainstorming, encenação, interpretação de papéis e revisão
dos requisitos existentes. Essas técnicas poderão ser usadas isoladamente ou combinadas.
Todas poderão ser combinadas ao método de caso de uso. Por exemplo, você poderá criar uma
ou algumas encenações para cada caso de uso previsto para o sistema. Você poderá usar a
interpretação de papéis como uma maneira de compreender como os atores usarão o sistema e
para ajudá-lo a definir os casos de uso.
O facilitador de um workshop de requisitos precisará estar preparado para as seguintes
dificuldades:
• É possível que os envolvidos saibam o que desejam mas não consigam expressar isso.
• É possível que os envolvidos não saibam o que desejam.
• Os envolvidos poderão achar que sabem o que desejam até que você lhes dê o que eles
disseram que desejavam.
• Os analistas poderão achar que compreendem os problemas dos usuários melhor do que
eles próprios.
• As pessoas poderão achar que as demais pessoas estão politicamente motivadas.
Os resultados dos workshops de requisitos serão documentados em um ou mais artefatos de
Solicitações dos Principais Envolvidos. Desde que você tenha boas ferramentas de suporte,
geralmente é aconselhável permitir que os envolvidos relatem informações desse tipo. Se tiver
optado por discutir o sistema em termos de atores e casos de uso, você também poderá ter
um esquema de modelo de casos de uso.
Antes do workshop ocorrer o facilitador precisará "vender" o workshop para os envolvidos que
deverão estar presentes e estabelecer o grupo que participará dele. Os futuros participantes
deverão receber material de estudo de "aquecimento" antes do workshop. O facilitador é o
responsável pelas atividades logísticas relacionadas ao workshop como, por exemplo, enviar
convites, encontrar um local adequado com o equipamento necessário para a sessão, assim
como distribuir uma agenda referente ao workshop.
O facilitador presidirá a sessão, o que inclui:
• Dar a todos a oportunidade de falar.
• Manter a sessão sob controle.
• Reunir informações para Atributos de Requisitos aplicáveis.
• Registrar as descobertas.
• Resumir a sessão e elaborar conclusões.
 Após o workshop de requisitos, o facilitador (juntamente com os colegas analistas de
sistemas) precisarão dedicar um tempo à síntese das descobertas e ao resumo das
informações em um formato apresentável.

Etnografia
Os estudos etnográficos são uma técnica, proveniente das disciplinas de Antropologia Social, que consiste
no estudo de um objecto por vivência directa da realidade onde este se insere. Permitindo analisar a
componente social das tarefas desempenhadas numa dada organização tornam-se, no âmbito da Engenharia
de Requisitos, extremamente uteis para ultrapassar a dificuldade que existe na recolha dos requisitos
derivados de formas rotineiras e tácitas de trabalhar:

• modo como realmente as pessoas executam as suas funções que muitas vezes difere
da forma como as definições dos processos sugerem que elas devem fazer;
• cooperação e conhecimento das actividades de outras pessoas

A abordagem etnográfica e a identificação de requisitos têm muito em comum. Ambas têm o objectivo de
entender uma cultura não familiar, todo o conhecimento, técnicas e práticas que a constituem, de forma a
traduzi-las de maneira a que possa ser entendida e usada por outros. Tal como o etnógrafo, o engenheiro de
requisitos tem a necessidade de documentar o domínio do sistema e a sua relação com a actividade de cada
pessoa envolvida no seu funcionamento. Para que se consiga extrair o máximo de conhecimento possível
das pessoas, deve-se comunicar com estas utilizando a sua própria linguagem e não uma linguagem técnica
de engenharia de software que é incompreensível e intimadora para a maioria delas. Posteriormente, a
equipa de desenvolvimento deve ser capaz de usar todos os dados obtidos para que possa desenvolver o
produto realmente apropriado, correspondente com a informação recolhida, que se adapte completamente
às necessidades dos utilizadores e seja perfeitamente integrado no seu ambiente.

As pesquisas que se efectuam com o objectivo de realizar estes estudos resultam numa grande quantidade
de informação, através de apontamentos, gravações de áudio e vídeo e um conjunto de objectos que fazem
parte das culturas, que deverá ser gerida com toda a atenção para que a sua análise e processamento não se
prolongue excessivamente. Um estudo etnográfico requer muito mais tempo do que as técnicas de
identificação de requisitos mais comuns, como as entrevistas, logo todos os recursos financeiros e
temporais, muitas vezes difíceis de obter, que o suportam devem ser utilizados da forma mais optimizada
possível.

[editar] Os princípios

Em 1993, Blomberg argumentou que os engenheiros de software:

• criam ferramentas para processos de trabalho dos quais pouco conhecem;

• devem adquirir uma visão adequada do mundo e não apenas confiar nas suas
próprias experiências e imaginação;
• extrair um conhecimento completo das práticas de trabalho para explorar e consolidar
a relação as tarefas e a tecnologia

Desta forma, para orientar a actividade etnográfica apresentou os seguintes quatro princípios:

• Encontro inicial – passar algumas horas no ambiente onde os processos ocorrem

para estudar as pessoas nas suas actividades diárias;
• Holismo – crença que os comportamentos apenas podem ser entendidos no contexto
em que ocorrem;
• Descrição e não prescrição – descrever como as pessoas se comportam realmente
e não como se deveriam comportar;
 • Ponto de vista dos participantes - descrever os comportamentos de forma
relevante para os participantes do estudo.

Estes princípios implicam que os engenheiros de requisitos devem capturar toda a estrutura social que
constitui a actividade e não devem predefinir qualquer estrutura conceptual. O trabalho é uma actividade
socialmente organizada, onde muitas vezes o comportamento real difere da forma como é descrito por
quem o faz, e dessa forma é importante confiar tanto nas entrevistas quanto nas observações diárias das
pessoas no próprio local de trabalho onde a tecnologia deverá ser inserida.

[editar] Directrizes

Em 1995, um grupo de autores publicaram um conjunto de directrizes com o objectivo de orientar as

equipas de desenvolvimento a realizar, de forma correcta e completa, todo o processo de identificação de
requisitos através de estudos etnográficos. Estas directrizes estão divididas em quatro conjuntos cada um
deles respeitante a uma das fases deste processo (preparação, estudo, análise e especificação) que são
descritos de seguida.

[editar] Preparação

Uma preparação adequada do processo é fundamental para o sucesso do mesmo. Assim sendo, a directriz
para esta fase inclui os seguintes pontos:

• Entender a política organizacional e a cultura de trabalho;

• Familiarizar-se com o sistema e a sua história;
• Estabelecer objectivos iniciais e elaborar questões;
• Obter acesso e permissão para realizar entrevistas e observações.

[editar] Estudo

É a principal fase do processo, onde se realiza o contacto directo com os stakeholders do sistema a
desenvolver. Esta directriz é constituída por:

• Estabelecer empatias com administradores e utilizadores do sistema;

• Realizar observações e entrevistas aos utilizadores do sistema no seu ambiente de
trabalho;
• Recolher dados objectivos e subjectivos de modo quantitativo e qualitativo;
• Seguir todas as pistas que surjam durante as visitas;
• Registar todas as visitas.

[editar] Análise

Esta fase permite extrair conclusões do estudo já efectuado e, dessa forma, realizar melhoramentos durante
todo o processo. Aqui pode incluir-se:

• Compilar todos os dados recolhidos numa base de dados;

• Quantificar os dados e realizar estatísticas;
• Filtrar e interpretar os dados;
• Redefinir os objectivos e o processo utilizado.

[editar] Especificação

Por fim, há que documentar a informação recolhida e para esta directriz podemos considerar os seguintes
dois itens:
 • Ter em conta os diversos públicos alvo e objectivos existentes;
• Elaborar um relatório e apresentar as conclusões do estudo.

Por fim, apesar de não ter sido mencionada pelos autores, é uma boa prática realizar, ao longo de todo o
processo, sessões de crítica por parte de elementos externos ao projecto.

Levantamento
Orientado
a
Ponto de Vista

Análise da
Tarefa
Cenários

CRC (Cooperative Requirements Capture), Semelhante à técnica JAD, a CRC é

constituída por uma série de reuniões em que o papel do facilitador e

dos participantes é claramente definido. A diferença é que além de
usuários e projetistas, as reuniões incluem a participação dos outros
agentes interessados. Além disso, diferentemente da JAD e da QFD,
a CRC focaliza principalmente o contexto do usuário e trata com
relevância a identificação da motivação para o negócio. Entre as
características ressaltadas pela autora, destacam-se neste contexto:
existência de recursos para identificação e documentação de
requisitos, descrições genéricas de usuários e grupos de usuários
típicos, identificação e descrição das práticas correntes do trabalho,
identificação de restrições como custo, tempo e segurança,
identificação e descrição de critérios de aceitação, identificação e
descrição de atributos de qualidade.

gerenciamento de requisitos

Especificação de requisitos
Os requisitos de um sistema são descrições dos serviços fornecidos pelo sistema e as suas restrições
operacionais. Esses requisitos refletem as necessidades dos clientes de um sistema.
o Requisitos de usuário: são declarações, em uma linguagem natural com diagramas, de quais serviços são
esperados do sistema e as restrições sob as quais ele deve operar.
o Requisitos de sistema: define detalhadamente as funções, os serviços e as restrições operacionais do
sistema. O documento de requisitos do sistema deve ser preciso. Ele deve definir exatamente o que
será implementado.

Pontos importantes:
° Um requisito de usuário pode ser dividido em vários requisitos de sistema;
° O requisito de usuário é mais abstrato e os requisitos de sistema acrescentam
detalhes, explicando os serviços e as funções que devem ser fornecidos pelo
sistema;
° Os leitores dos requisitos de usuário geralmente não estão preocupados como o
sistema será implementado;
° Os leitores dos requisitos de sistema necessitam conhecer mais precisamente o
que o sistema fará.
° Os requisitos de sistema são uma especificação completa e consistente de todo
o sistema
° Requisitos de sistema são versões expandidas dos requisitos de usuário.

Há ainda uma subclassificação dos requisitos de sistema, que se dividem em três tipos:
o Requisitos Funcionais: São as declarações de serviços que o sistema deve fornecer, como o sistema
deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações.
Pontos importantes:
° Depende do tipo de software que está sendo desenvolvido, dos usuários a que o
software se destina e da abordagem geral considerada pela organização ao
redigir os requisitos.
° Podem ser expressos de várias formas e em níveis diferentes de detalhes
° Deve ser completo e consistente. Completeza significa que todos os serviços
exigidos pelos usuários devem ser definidos. Consistência significa que os
requisitos não devem ter definições contraditórias.

o Requisitos Não-Funcionais: São restrições sobre os serviços ou as funções oferecidos pelo sistema.
Os requisitos não funcionais estão raramente associados às características individuais do sistema. Pelo
contrário, esses requisitos especificam ou restringe as propriedades emergentes de sistema, como
confiabilidade, tempo de resposta e espaço de armazenamento.
Pontos importantes:
° Geralmente são mais importantes que os requisitos funcionais. Pois a falha em
um requisito não-funcional pode inutilizar todo o sistema.
° Os requisitos não-funcionais podem vir de características necessárias do
software(requisitos de produto), da organização que desenvolve o
software(requisitos organizacionais) ou de fontes externas:
o Requisitos de produto: Requisitos que especificam o comportamento do
produto. Ex: velocidade de execução, confiabilidade, portabilidade,
facilidade de uso, etc..
o Requisitos organizacionais: Requisitos que são conseqüência de políticas
de procedimentos nas organizações do cliente e do desenvolvedor. Ex:
padrões de processos que devem ser utilizados, requisitos de
implementação, etc.
o Requisitos externos: Requisitos procedentes de fatores externos ao
sistema e a seu processo de desenvolvimento. Ex: requisitos de
interoperabilidade, requisitos legais e os requisitos éticos.
 o Requisitos de Domínio: São derivados do domínio da aplicação do sistema, em vez das necessidades
específicas dos usuários do sistema. Geralmente incluem terminologia específica do domínio ou fazem
referência a conceitos do domínio. Podem ser novos requisitos funcionais em si mesmos, podem
restringir os requisitos funcionais existentes ou estabelecer como cálculos específicos devem ser
realizados.
Pontos importantes:
• São importantes porque com freqüência, refletem os fundamentos do domínio
da aplicação. Se esses requisitos não forem satisfeitos, pode ser impossível
fazer o sistema funcionar satisfatoriamente.
• Geralmente os engenheiros de software tem dificuldade em compreendê-los.
• Os especialistas de domínio podem deixar informações fora de um requisitos,
simplesmente por serem muito obvia para eles.

o Requisitos de Usuário: Os requisitos de usuário devem descrever os requisitos funcionais e não

funcionais de modo compreensível pelos usuários do sistema, que não tem conhecimentos técnicos
detalhados. Os Requisitos do usuário são definidos usando linguagem natural, tabelas e diagramas. Ele
deve especificar apenas o comportamento externo do sistema e evitar, sempre que possível,
características de projeto de sistemas.
Pontos importantes:
• Problemas que podem surgir ao usar liguagem natural:
• Falta de clareza: Difícil usar a linguagem de maneira precisa e sem ambigüidade,
sem produzir um documento de difícil leitura.
• Confusão de requisitos: Os requisitos funcionais e os não funcionais, os
objetivos do sistema e as informações sobre o projeto podem não estar
claramente definidos.
• Fusão de requisitos: Vários requisitos diferentes podem ser expressos juntos.

Técnicas de validação de requisitos

A validação de requisitos é um processo que trata, tal como o seu nome indica, da validação
quanto à consistência, precisão, contextualização de requisitos levantados no processo de
identificação e descoberta e de análise e negociação de requisitos. Este processo envolve uma
revisão de todos os requisitos levantados e negociados, assim como uma prototipagem e validação de
modelos e teste de requisitos. As atividades de validação dedicam-se a mostrar que os requisitos
realmente definem o sistema que o usuário deseja. Está relacionada à descoberta de problemas com
os requisitos. Durante o processo de validação devem ser realizadas verificações nos requisitos:
o Verificações de qualidade:
o Verificações de consistência:
o Verificações de completeza
o Verificações de realismo
o Facilidade de verificação
Os produtos de trabalho criados como conseqüência da engenharia de requisitos (uma
especificação dos requisitos do sistema e informações relacionadas) devem ser validados quanto à
qualidade durante o passo de validação de requisitos. Esta validação examina a especificação para
garantir que todos os requisitos do sistema foram estruturados de maneira não ambígua, que as
inconsistências, omissões e erros foram apagados e corrigidos, e que os produtos de trabalho estão
em conformidade com os padrões estabelecidos para o processo, para o projeto e para o produto.
Existem técnicas de validação que podem ser usadas em conjunto ou individualmente:
o Revisões de Requisitos: análise sistemática dos requisitos por uma equipe
o Prototipação: um modelo executável do sistema é apresentado aos usuários finais
o Geração de Casos de Teste: verificação da testabilidade dos requisitos
 O mecanismo primário de validação de requisitos é a revisão técnica formal. O time de revisão
inclui os engenheiros de sistema, clientes, usuários e outros stakeholders que examinam a
especificação do sistema à procura de erros de conteúdo ou interpretação, pontos onde pode ser
necessário esclarecimento, perda de informações, inconsistências (um dos maiores problemas da
engenharia de grandes produtos), requisitos conflitantes, ou requisitos irreais (de desenvolvimento
impossível).

Prototipação

A técnica de prototipação é indicada para estudar as alternativas de interface do

usuário problemas de comunicação com outros produtos . A prototipação
pode ser utilizada para elicitar requisitos quando há um alto grau de incerteza
ou quando é necessário um rápido feedback dos usuários.

• a viabilidade de atendimento dos requisitos

de desempenho.

Prototipação - benefícios
• reduções dos riscos
na construção do sistema;

• O uso de protótipo
auxilia na elicitação e validação dos
requisitos de sistema;
Protótipo é a primeira versão desenvolvida do software, a qual tem a finalidade de abordar a questão de
interface com o usuário, validar requisitos e apresentar a viabilidade do sistema.

Durante a criação do protótipo, clientes e desenvolvedores ficam em constante interação, facilitando assim
o levantamento de requisitos e funcionalidades do sistema.
Alguns desenvolvedores utilizam prototipações que são descartadas, ou seja, o desenvolvimento do sistema
somente será iniciado após o término do desenvolvimento do protótipo. Esses métodos de prototipações
geralmente elevam o custo do sistema, pois são feitos dois projetos separados, um do protótipo e outro do
sistema final.

Essa separação entre o desenvolvimento do protótipo e do sistema final vem diminuindo a cada dia, com o
uso da prototipação evolutiva, a qual será o objeto de estudo deste artigo que terá como objetivo mostrar as
vantagens e desvantagens da utilização deste método no desenvolvimento de sistemas de informação.

2. PROTOTIPAÇÃO DE ALTA FIDELIDADE

Protótipos de alta fidelidade são semelhantes ao produto final. Este tipo de prototipação utiliza à mesma
técnica que o sistema final e é indicado quando o objetivo é a venda do sistema ou o teste de problemas
técnicos.

Há algumas vantagens em usar a prototipação de alta fidelidade, como: funcionalidades semelhantes as do

sistema final, a definição completa do esquema navegacional, um elevado grau de interação com os
usuários e a exploração de testes com muito realismo.

No entanto, háalgumas desvantagens como, por exemplo: elevado custo e tempo de desenvolvimento,
ineficiente para testes de opções de design e levantamento de requisitos.

A prototipação de alta fidelidade poderá ser implementada seguindo um dos métodos: (Figura 1)

Prototipação Throw-Away, na qual, seu objetivo é identificar e validar requisitos. E Prototipação

Evolutiva, que tem o objetivo de minimizar o tempo de desenvolvimento do sistema.

Figura 1 - Prototipações Evolutiva e Throw-Away. [1]

3. PROTOTIPAÇÃO THROW-AWAY

Este método de prototipação é utilizado para encontrar problemas de requisitos em protótipos, e tem como
objetivo consistir uma maior qualidade, por meio da validação e definição no documento de requisitos do
software.

Ele tem como base os requisitos que não estão bem definidos, e os que já estão bem definidos dificilmente
são utilizados no protótipo. Ao construir um protótipo pelo método Throw-Away, os seguintes passos são
seguidos: desenvolve-se um documento de requisitos provisório, obtêm-se opiniões dos usuários e
reformula-se o documento de requisitos, repetem-se estes passos, até a obtenção de satisfação dos usuários
e, consequentemente, a finalização do documento de requisitos.

Depois da finalização do documento de requisitos, o protótipo já não é mais necessário e então é

abandonado, para que se inicie o processo de desenvolvimento do software, o que acarreta em um gasto de
tempo um pouco maior e na elevação do custo.

4. PROTOTIPAÇÃO EVOLUTIVA

A prototipação evolutiva é utilizada em protótipos que evoluirão até tornarem-se sistemas finais.

Neste método, rapidamente é desenvolvido um protótipo que será modificado até que se obtenha o sistema
final. Para que sejam feitas as modificações e o protótipo transforme-se em software, começa-se a
construção deste protótipo com os requisitos fundamentais e que estejam bem definidos e é necessário o
acompanhamento do usuário, para que juntamente com ele o desenvolvedor possa definir os requisitos do
sistema.
Contrastando com a prototipação Throw-Away, um documento de requisitos detalhado não é elaborado,
visto que a prototipação evolutiva é um método redutor de custo e de tempo.

Há algumas vantagens e desvantagem ao usar a prototipação evolutiva, que precisam ser conhecidas pelos
desenvolvedores antes de adotar este método.

·Vantagens: Rápida entrega do sistema; compromisso do usuário com o sistema; especificação, desenho e
implementação interligados; sistema desenvolvido como uma série de incrementos ao usuário;

·Desvantagens: Alguns requisitos não aparecem na especificação; requisitos não funcionais não são
testados de forma adequada; documento de requisitos inexistente ou não detalhado; difícil manutenção; em
alguns casos difícil gestão;

A longo prazo, podem ocorrer problemas de manutenção e evolução do sistema, por falta de uma estrutura
sólida no seu desenvolvimento, isto pode causar o curto tempo de vida do sistema, visto que só os
especialistas que o desenvolveram poderão efetuar a manutenção ou a evolução com facilidade.

Quando se utiliza a prototipação evolutiva se torna difícil a elaboração de um contrato entre

desenvolvedores e clientes, pois estes contratos geralmente têm por base o documento de requisitos.

Para a obtenção de um bom sistema não se deve basear em protótipos feitos para responder questões
especificas, mas desenvolver um protótipo com a finalidade de futuramente transformá-lo em um sistema.

O protótipo evolutivo pode se transformar em um sistema robusto, desde que, seja elaborado um
planejamento e um desenvolvimento bem estruturado, com muito cuidado desde o início do projeto.