Engenharia

Inserir TítulodeAqui
Inserir Título Aqui
Requisitos
Tipos de Requisitos e sua Elicitação

Responsável pelo Conteúdo:

Prof. Me. Afonso Maria Luiz Rodrigues Pavão

Revisão Textual:
Prof. Esp. Claudio Pereira do Nascimento
 Tipos de Requisitos e sua Elicitação

Nesta unidade, trabalharemos os seguintes tópicos:

• Tipos de Requisitos e sua Elicitação.

Fonte: iStock/Getty Images

Objetivos
• Descrever métodos para a identificação e a determinação dos tipos de requisitos de
software a serem explorados pelo processo de software.

Caro Aluno(a)!

Normalmente, com a correria do dia a dia, não nos organizamos e deixamos para o
último momento o acesso ao estudo, o que implicará o não aprofundamento no material
trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.

Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você
poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns
dias e determinar como o seu “momento do estudo”.

No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões

de materiais complementares, elementos didáticos que ampliarão sua interpretação e
auxiliarão o pleno entendimento dos temas abordados.

Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de
discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de
propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de
troca de ideias e aprendizagem.

Bons Estudos!
UNIDADE
Tipos de Requisitos e sua Elicitação

Contextualização
O processo de desenvolvimento de software por si só exige grande atenção e res-
ponsabilidade dos engenheiros e arquitetos, pois envolve diversas técnicas e conceitos,
alguns bastante genéricos e outros muito específicos.

Além disso, as necessidades dos usuários (e suas diversas especializações)

são distintas, o que dificulta mais o trabalho do desenvolvedor. Obviamente, não
podemos nem pensar que um desenvolvedor irá conhecer todos os processos em
detalhes em sua empresa e, menos ainda, qualquer processo que requeira seu
trabalho. Ainda que sua experiência seja alta, isso não é possível.
É claro que seu conhecimento anterior sempre irá colaborar caso se envolva em um
novo projeto, mas sempre será necessário conhecer o processo novo para se
pensar em desenvolver um novo projeto.

Quanto aos usuários, estes podem ter vasto conhecimento e experiência nos
processos em que são especialistas. Podem inclusive ter participado por experi-
ências em desenvolvimento de projeto de software – e mais – na mesma empresa
onde atuam e com os mesmos profissionais desenvolvedores. Mas, isso não é
sinônimo nem garantia de que terá sucesso em um novo projeto.

Isso acontece principalmente devido ao fato de que no momento o cenário

e os objetivos organizacionais – e até mesmo das equipes de trabalho ou desen-
volvedores - também são mutáveis, assim como seu desempenho, empenho,
motivação e determinação.

Igualmente, não se pode pensar que a tecnologia já utilizada com sucesso também
seja garantia de bons resultados. Pode ser um sinalizador, não uma garantia de fato.

E é exatamente essa tecnologia que acaba interferindo diretamente nos an-

seios da comunidade usuária, não só porque seu perfil já passou por grandes
mudanças, como também, porque seu envolvimento com a tecnologia aumentou
drasticamente, assim como suas exigências com relação a ela.

As técnicas existentes para se especificar os requisitos de um software aumen-

tam a chance de sucesso em um projeto de desenvolvimento, pois têm como ob-
jetivo facilitar o trabalho dos envolvidos em um projeto de software, minimizando
os efeitos das diferenças de perfil, experiência ou envolvimento das partes.
Estas também contribuem para reduzir os custos do desenvolvimento do projeto de
um software e também para evitar custos adicionais na correção de erros ou falhas na
execução do software, decorrentes de enganos no início da fase de seu projeto.

Para isso, nesta unidade, vamos conhecer e explorar os diversos tipos de requisitos e
as técnicas para sua obtenção.

6
Tipos de Requisitos e sua Elicitação
A engenharia de requisitos se destaca pelas técnicas de fazer uma coleta de dados
visando conhecer as necessidades dos usuários e pelas atividades relacionadas com sua
especificação e gestão.

Como está relacionada com a definição do que o sistema deverá fazer e suas
propriedades essenciais e desejáveis, as restrições para a sua operação e também com
o processo de desenvolvimento do software podem até ser confundidas como sendo um
processo de comunicação. Mas isso é apenas a base para a coleta de dados.

Acima de tudo, antes de se iniciar a coleta de dados, devemos nos preocupar em

entender a terminologia utilizada e em qual contexto ela será aplicada. Somente assim
será possível compreendermos a extensão e a amplitude desta unidade.

Um dos aspectos requeridos para a compreensão dos requisitos é podermos avaliar

sua amplitude, aplicabilidade, características e tipos.

Sommerville (2011) afirma que requisitos de sistema são descrições do que o sistema
irá fazer, quais serviços serão oferecidos a seus usuários e qual será seu funcionamento.
Desta forma, o autor define que requisitos de sistema é um conjunto de necessidades
que devem ser atendidas.

Essas descrições refletem as necessidades dos clientes em resolver um determinado

problema ou facilitar a aplicação de soluções já estudadas e conhecidas.

O autor divide os requisitos em dois. Um deles são os requisitos de usuários e os iden-

tifica como sendo declarações feitas com diagramas relativos a quais serviços são espera-
dos pelo sistema e quais são as restrições para a sua operação. Entende-se, assim, que
os requisitos de usuários são mais abstratos e genéricos. Seus principais usuários são os
gerentes dos clientes ou dos fornecedores, os usuários finais de sistemas, os engenheiros
dos clientes e os arquitetos de sistemas.

Os outros são os requisitos de sistemas que contêm definições detalhadas das

funções, serviços, suas restrições operacionais e estão direcionados aos usuários finais de
sistemas, aos engenheiros dos clientes ou aos arquitetos de sistemas ou desenvolvedores
de software.

Esta separação, proposta pelo autor, objetiva tentar facilitar o entendimento de qual
especificação é mais aplicável a um software ou a uma de suas rotinas. Em outras pa-
lavras, os diferentes níveis de especificação de um sistema contribuem para que seja
fornecido o máximo de informações sobre o sistema e sob as diferentes óticas de leitores
e usuários.

Conceitua-se, por fim, que os requisitos de um software referem-se a uma caracte-

rística do sistema ou a descrição de algo que o sistema é capaz de realizar para atingir
seus objetivos.

7
7
UNIDADE
Tipos de Requisitos e sua Elicitação

Pressman (2011) salienta que é a engenharia de requisitos a responsável por fornecer

mecanismos que visem ao entendimento do que o cliente de fato necessita, pois além de
analisar suas necessidades, avalia a viabilidade de sua aplicação, dentre outras tarefas.

Zultner (1992) apud Pressman (2011), em seu texto sobre quality function
deployment – QFD (técnica de gestão de qualidade que transforma as necessidades do
cliente em requisitos técnicos do software), cita a existência de três tipos de requisitos:
os normais, os esperados e os fascinantes.

Para ele, os normais refletem objetivos e metas determinados para um produto durante
as reuniões com o cliente. Se estiverem presentes no software o cliente ficará satisfeito.

Os esperados são aqueles considerados implícitos no produto – são tão fundamentais

e óbvios que o cliente nem os cita. Porém, caso não estejam presentes no produto, a
insatisfação do cliente será enorme.

Já os requisitos fascinantes são aqueles que trazem consigo outras facilidades que
sequer haviam sido pensadas e, portanto, não são esperadas.

Conforme Pleeger (2004), há 3 categorias de requisitos: aqueles que devem ser total-
mente satisfeitos, os que são altamente desejáveis - mas não necessários e aqueles que
são possíveis, mas que poderiam ser eliminados.

Mas Sommerville (2011), assim como Pressman (2011), ainda os classifica como
sendo funcionais ou não funcionais. Aquele ainda acrescenta os requisitos de domínio.

Requisitos funcionais são aqueles diretamente ligados às funcionalidades do software

e descrevem o que o software deve executar. Estes se preocupam com as funções e os
serviços do sistema, ou seja, o que o sistema deve fornecer para o cliente e como irá se
comportar em determinadas situações.

Eles descrevem uma interação entre o sistema e o ambiente, como o sistema deve
funcionar conforme determinada situação, declara quais serviços o sistema deve forne-
cer, como deve reagir a entradas específicas e como deve se comportar em alguns casos.
Descrevem, assim, as interações entre o sistema e seu ambiente.

Estes requisitos funcionais podem ainda ser evidentes, caso efetuados com
o conhecimento do usuário, ou serem ocultos, se efetuados pelo sistema sem o
conhecimento explícito do usuário.

Se o processo de produção de software depende da definição clara de qual produto

será construído, a identificação dos requisitos funcionais é de extrema importância para
essa produção com qualidade.

Entretanto, quando se fala em requisitos, não podemos deixar de explicar que são os
requisitos não funcionais aqueles que acabam por trazer muitas dúvidas aos desenvolvedores.

Aliás, a clara definição sobre requisitos de software ainda não está adequadamente
assimilada entre os autores, principalmente, quando o cenário apresentado pode trazer
ainda mais dúvidas.

8
 Mas se analisarmos friamente e pontualmente, veremos que requisitos não funcio-
nais, em vez de informar o que o sistema fará, colocam restrições sobre os serviços ou
funções oferecidas pelo sistema, tais como restrições de timing sobre o processo de
desenvolvimento, sobre padrões, dentre outras, e limitam nossas opções para criar uma
solução para o problema. Estão vinculados à ISO - The International Organization for
Standardizatized e à IEC - The International Electrotechnical Commition.

Temos, então, a separação dos requisitos não funcionais em nove tipos distintos:
ambiente físico, interfaces, dados, usuários e fatores humanos, funcionalidade,
documentação, recursos, segurança e garantia de qualidade.

Os requisitos não funcionais carregam consigo, ainda, as características da ISO/IEC

9126 quanto a funcionalidade, usabilidade, confiabilidade, eficiência, manutenibilidade
e portabilidade.

Os requisitos não funcionais podem afetar a estrutura do sistema, assim como, pode
gerar inúmeros outros requisitos funcionais, como é o caso de um requisito de proteção
que definirá, por exemplo, os serviços necessários ao sistema (SOMMERVILLE, 2011).

São esses requisitos que expressam as condições que o software deve atender
ou as qualidades específicas que este deve ter, como por exemplo, propriedades,
comportamento, restrição etc.

Impõem restrições no sistema, como tempo, espaço, linguagens de programação, versões

do compilador, SGBD, sistema operacional, método de desenvolvimento, dentre outras.

A tabela 1 demonstra as propriedades esperadas pelo software e algumas das formas

de sua medição. A obtenção dos valores relativos a cada uma delas depende de cada
instalação e de seus mecanismos de controle e gerenciamento de hardware.

Tabela 1 – Requisitos Não Funcionais

Propriedade Métrica
Confiabilidade Tempo médio de ocorrência de falhas.
Probabilidade de indisponibilidade por falha.
Taxa de ocorrência de falhas.
Disponibilidade.
Facilidade de uso Tempo requerido para treinamento.
Número de telas para ajuda.
Manutenibilidade Número de alterações realizadas por período.
Número de retrabalho em modificações.
Portabilidade Porcentagem de declarações dependentes do sistema-alvo.
Número de sistemas-alvo.
Robustez Tempo de reinício após falha.
Porcentagem de eventos geradores de falhas.
Probabilidade de dados se corromperem devido a falhas.
Tamanho Kbytes.
Número de chips de RAM.
Velocidade Número de transações processadas por segundo.
Tempo de resposta ao usuário.
Tempo para atualização de tela.
Fonte: Sommerville, 2011

9
9
UNIDADE
Tipos de Requisitos e sua Elicitação

Sommerville (2011), ainda, classifica os requisitos não funcionais em requisitos do

produto final, organizacionais e externos.

Entende que os requisitos de produto final estão relacionados em como o produto de

software deverá se comportar. Ou seja, qual será sua eficiência quanto a desempenho ou
espaço, confiabilidade, facilidade de uso e portabilidade.

Com relação aos requisitos organizacionais, estes estão vinculados à consequência de

políticas e procedimentos organizacionais que devem ser seguidos, tais como entrega,
padrões ou implementação.

Já os requisitos externos referem-se a fatores externos ao sistema e ao processo de

desenvolvimento, como, por exemplo, a legislação, privacidade, segurança, princípios
éticos e interoperabilidade.
Requisitos Não Funcionais

Requisitos do Produto Requisitos Organizacionais Requisitos Externos

Requisitos de Requisitos de Requisitos de Requisitos de

Requisitos Éticos
Eficiência Confiabilidade Portabilidade Interoperabilidade

Requisitos de Requisitos de Requisitos de Requisitos de Requisitos

Facilidade de Uso Entrega Implementação Padrões Legais

Requisitos de Requisitos de Requisitos de Requisitos de

Desempenho Espaço Privacidade Segurança

Figura 1 – Requisitos Não Funcionais

Fonte: Sommerville, 2011

As informações dos usuários demonstram, genericamente, quais podem ser as restri-

ções de um software. Entretanto, pode ser necessário seu detalhamento e classificação.

Uma das formas para essa classificação é conhecida como FURPS+, um acrônimo
de Functionality, Usability, Reliability, Performance e Supportability. O Plus (+) se
refere a outras circunstâncias, como design, implementação, interface, aspectos físicos,
dentre outros.

Detalhando um pouco mais: a functionality (funcionalidade) envolve o aspecto fun-

cional do sistema a desenvolver, enquanto que a usability (usabilidade) está relacionada
com o tempo requerido para treinar um usuário e este ser produtivo. Mas, também,
refere-se ao tempo de duração desejado para uma operação do sistema, ajuda on-line,
documentação do usuário ou material de treinamento.

A reliability (confiabilidade) trata-se da disponibilidade, do tempo decorrido para

uma correção. É o máximo de tempo admitido para uma indisponibilidade no caso de
ocorrência de uma falha. Refere-se, ainda, a precisão, ao número máximo de defeitos,
ou, ainda, categorias de bugs, que devem preferencialmente ser categorizados por nível
de impacto que podem causar, caso ocorram.

10
 A categoria performance (desempenho) refere-se ao tempo de resposta requerido
para uma transação, em segundos (o troughput). Pode ser também a medição de tran-
sações por segundo ou a capacidade das transações concorrentes, uma operação parcial
(exceção) ou, ainda, o uso de recursos como memória, espaço em disco ou comunica-
ção, dentre outros.

A supportability (suportabilidade) que indica os padrões de uma codificação, a con-

venção de sua nomenclatura, as bibliotecas de classes ou os utilitários de manutenção.

O plus (+) se refere a outras circunstâncias, como design, implementação, interface

ou aspectos físicos, dentre outros.

Os requisitos não funcionais ainda podem ser obrigatórios - caso necessitem existir de
fato ou desejáveis - caso possam estar presentes na aplicação.

Podem, também, ser permanentes, quando são relativamente estáveis ou derivam-se

da atividade central da organização e se relacionam diretamente ao domínio do sistema.
Estes ainda podem ser transitórios ou, conforme Sommerville (2011), voláteis.

Consideram-se voláteis aqueles que provavelmente irão mudar durante o processo de

desenvolvimento do sistema ou depois que o sistema estiver em operação.

Os requisitos não funcionais são tão importantes quanto os requisitos funcionais. Estes
restringem as possíveis soluções dos engenheiros de software e ajudam na determinação
da qualidade do software.

Outro tipo de requisito que existe é o de domínio.

Esses são requisitos derivados do domínio da aplicação do sistema e descrevem as

características do sistema e qualidades que refletem o domínio. Podem ser requisitos
funcionais novos, restrições sobre requisitos existentes ou, ainda, computações específi-
cas ou especificidades computacionais de um algoritmo ou do processo em si.

Conforme Wazlawick (2015), a análise de domínio está relacionada à descoberta das

informações que serão gerenciadas pelo sistema. Ou seja, à representação e transforma-
ção dos dados ou da informação com o sistema.

Um termo que vem sendo bastante discutido ultimamente entre os desenvolvedores e

stakeholders é o termo regra de negócio. Porém, nem sempre se dá a devida atenção
a seu verdadeiro significado, o que acaba por levar à incompreensão algumas funciona-
lidades do software.

As regras de negócio estão intimamente relacionadas à organização, sua visão e mis-

são, e vinculadas aos objetivos que a organização pretende alcançar.

Apresento, na tabela 2, alguns exemplos de regras de negócio que não irão interfe-
rir na identificação de requisitos funcionais, como as RN 01 a 04. Note que estas são
pontuais e caso não se vinculem a um software muito específico, em nada irão afetar a
especificação de requisitos.

11
11
UNIDADE
Tipos de Requisitos e sua Elicitação

Entretanto, as demais regras de negócio podem se tornar requisitos funcionais, con-

forme seu contexto – observe as diferenças entre elas e suas replicações “a” e “b”.

Tabela 2 – Regras de Negócios vs Requisitos Funcionais

RN RF Descrição
01 O horário de atendimento do trabalho é das 8h às 18h de 2ª a 6ª-feira.
02 Os funcionários devem portar crachá durante sua permanência na empresa.
03 O site deverá ser atualizado pelo responsável toda 6ª-feira.
04 A dedetização deverá ser feita trimestralmente e poderá ser feita até o 5º dia do primeiro mês do trimestre fiscal.
05 As contas devem ser pagas até o vencimento.
05a 01 As contas devem ser pagas até o vencimento (o sistema deve exibi-las em tela).
06 A ordem de compra somente poderá ser emitida após a escolha da melhor cotação.
06a 02 A ordem de compra somente poderá ser emitida após a escolha da melhor cotação (escolha automática pelo
sistema).
07 Os recebimentos podem ser por cartão de débito ou crédito.
07a 03 Os recebimentos podem ser por cartão de débito ou crédito (deve existir uma interface com o banco).
08 Para cada venda realizada, deverá ser emitida eletronicamente a nota fiscal.
08a 04 Para cada venda realizada deverá ser emitida eletronicamente a nota fiscal (deve existir link automático para isto).
09 Somente o coordenador poderá autorizar (assinar) compras acima de R$ 5000,00.
09a 05 Somente o coordenador poderá autorizar (assinar pelo sistema) compras acima de R$ 5000,00.
10 Cada cotação deverá ser feita com no mínimo 5 fornecedores diferentes.
10a 06 Cada cotação deverá ser feita com no mínimo 5 fornecedores diferentes (o sistema deve exibi-los).
10b 07 Cada cotação deverá ser feita com no mínimo 5 fornecedores diferentes (o sistema deve exibi-los, aceitar as
escolhas do comprador e enviar pedido de cotação por e-mail).

Os requisitos funcionais, derivados ou não de uma regra de negócio, podem gerar um

ou mais requisitos não funcionais, também de acordo com o contexto ou situação apre-
sentada, que provocará seu desmembramento conforme se apresentem suas restrições.

Um outro aspecto que gera confusão quanto aos requisitos não funcionais é o fato
de que às vezes estes não são derivados de requisitos funcionais, mas originam-se dire-
tamente das regras de negócio.

Observe bem isso na tabela 3.

Tabela 3 – Regras de Negócios vs Requisitos Funcionais vs Requisitos Não Funcionais

RN RF RNF Descrição
11 O atendimento por telefone não deverá exceder 5 minutos.
11 08 Se o atendimento por telefone atingir 5 minutos, o sistema deverá emitir um sinal
para o operador.
11 09 09.01 Se o atendimento por telefone atingir 5 minutos, o sistema deverá emitir um sinal
para o operador e deverá gravar um registro de atraso no LogSer.
12 12x01 O tempo de resposta no acesso pela internet deve ser menor que 10 segundos.
13 13x01 O sistema deve ser executado em qualquer browser.
14 14x01 O número de abas no sistema não pode exceder a 7.

12
 Uma das formas de se representar os requisitos funcionais e os requisitos não funcio-
nais deles derivados é apresentada na Tabela 4.

Tabela 4 – Regras de Negócios vs Requisitos Funcionais vs Requisitos Não Funcionais

F1 Registrar empréstimos Oculto ( )

Descrição: O sistema deve registrar emprestimos de fitas, indicando o cliente e as fitas que foram
emprestadas, bem como a data de empréstimo e valor previsto para pagamento na devolução.

Requisitos Não Funcionais

Nome Restrição Categoria Desejável Permanente
A função só pode ser acessada
NF 1.1 Controle
por usuario com perfil de Segurança ( ) (X)
de Acesso
operador ou superior.
NF 1.2
As fitas devem ser identificadas
Identificação Interface ( ) (X)
por um código de barras
de Fitas
NF 1.3
O cliente deverá ser identificado
Identificação Interface ( ) ( )
a partir de seu nome
do Cliente
O tempo para registro de casa
NF 1.4 Tempo
fita deve ser inferior a um Performance (X) ( )
de Registro
segundo.
Todas as funções relacionadas
NF 1.5 Janela
a empréstimos devem ser Interface (X) (X)
única
efetuadas em uma única janela.
… … … … …

F2 Calcular Descontos Oculto (X)

Descrição: O sistema deve calcular descontos nos empréstimos em função da política da empresa.
Requisitos Não Funcionais
Nome Restrição Categoria Desejável Permanente
NF 2.1 Descoto
Nos fins de semana, usuários que
de Fim de Especificação ( ) ( )
levam 4 fitas pagam apenas 3.
Semana
… … … … …
Fonte: Wazlawick (2015).

Como vimos, há regras de negócio que se tornam ou não requisitos funcionais,

assim como há regras de negócio que se tornam requisitos não funcionais e requisitos
funcionais que contém ou não requisitos não funcionais.

A segurança na identificação das regras de negócio e dos requisitos funcionais e

não funcionais está diretamente relacionada com a fase de obtenção de requisitos. E
esta com as técnicas disponíveis para essa finalidade e, claro, com as habilidades do
desenvolvedor.

Uma das técnicas é o Brainstorm, realizado em sessões sucessivas ou programadas

especificamente, com a reunião de (poucas) pessoas com diferentes perfis e que, na
presença de um facilitador, apresentam e aceitam todos os tipos de sugestão para
posteriormente filtrá-las após discussão.

13
13
UNIDADE
Tipos de Requisitos e sua Elicitação

Outra técnica utilizada é a de Casos de Uso (ou Cenários), onde a elaboração deste
diagrama da UML facilita o trabalho de identificação das necessidades dos usuários, com
respectivos processos e subprocessos.

São situações descritas que explicam como um sistema poderá ser usado. Nas sessões
de interação é demonstrado como o usuário irá interagir. O termo caso de uso ou use
case pode ser usado nessas reuniões. Pode-se, inclusive, descrever o caso de uso em
detalhes, identificando os atores envolvidos, as principais funcionalidades e a interação
entre atores.

Detalhando-se o caso de uso, podem-se incluir informações diversas, tais como nome
do cenário, ator(es), pré-condição, fluxo normal, fluxos alternativos e pós-condição.

Uma técnica que muitos desenvolvedores esquecem que existe e acabam por não
utilizar é a de documentos. As comunicações internas das empresas são uma fonte
fantástica de informação sobre um processo que será automatizado, assim como os
documentos gerados ou utilizados, como gráficos, listas, tabelas ou relatórios.

As normas e procedimentos são outras importantes fontes de informação, pois muitas

das regras de negócio estão lá registradas e sempre irão contribuir com o desenvolvedor
em algum momento do projeto. O mesmo raciocínio quanto a livros ou revistas técnicas
ou outras fontes de informação, no mínimo, irão contribuir com o desenvolvedor para
entender a base do negócio ou do processo – até para se situar ou se preparar para
conversar com os usuários. Uma fonte que requer maiores comentários é a legislação ou
normas regulatórias de órgãos, entidades ou clientes e fornecedores.

A entrevista, por outro lado, é uma das técnicas mais utilizadas e permite o contato
visual e maior envolvimento dos usuários. Essa técnica faz o questionamento dos
stakeholders sobre o funcionamento do processo e podem ser fechadas, caso já se tenha
perguntas pré-definidas ou abertas quando as respostas às perguntas básicas geram
novas perguntas, visando assim, explorar ao máximo o conhecimento do stakeholder.

A técnica conhecida como etnografia deve ser utilizada quando se quer ter uma
visão qualitativa ou quantitativa sobre o funcionamento de um processo. É a técnica
de observação direta ou indireta utilizada para a compreensão do funcionamento do
processo na prática e melhor entendimento sobre os requisitos sociais e organizacionais.
Visa observar suas atividades, entender os conceitos envolvidos, escrevê-los e analisá-los
para novas proposições ou complementos da coleta de dados.

A técnica de JAD - Joint Application Design promove cooperação, entendimento e

trabalho em grupo entre as partes interessadas, aplicando-se dinâmica de grupo, técnicas
visuais, documentação padrão e mantendo o processo organizado e racional, isso facilita
a criação e a visão compartilhada do que o produto de software deve ser. As sessões
de JAD devem ser programadas periodicamente, ter um grupo fechado (que poderá
convidar algum outro stakeholder) e manter as pautas e atas devidamente elaboradas e
cumpridas.

14
 AGENDA
Overview Flip Chart Janela de
Lousa Magnética Despesas
Gerais
Scanner
Impressora

Flip Chart
(Gráficos)

Projetor

Name Tents

Figura 3 – Reunião de JAD

A técnica do ponto de vista visa conhecer, entender e especificar os vários entendimentos

de cada um dos stakeholders envolvidos em um processo. Para o desenvolvedor, esta
técnica é muito rica, pois permite conhecer uma situação ou um fato sob perspectivas
diferentes, pois cada indivíduo tem uma percepção (ou entendimento) de um processo,
cada qual com suas atividades, dificuldades e necessidades.

Outra técnica que vem sendo utilizada e bastante comum nos processos ágeis é a
técnica de prototipação, onde as situações são apresentadas, discutidas e representadas
em diagramas que permitem rápido e fácil entendimento. Os diagramas mais utilizados
são o diagrama de classe da UML ou de caso de uso e, nas aplicações mais antigas, os
(ainda) usados diagramas de fluxo de dados e de contexto.

O questionário é uma boa técnica a ser aplicada para economia de tempo e de

orçamento, sendo adequado para projetos piloto que envolvem mais de uma unidade
federativa, exige muito tempo para ser elaborado de forma adequada, pois deve ser
preparado levando em conta também as dificuldades de tempo que o respondente
fatalmente terá. Deve ser objetivo, tal qual uma questão de múltipla escolha, e com
resultados esperados e já previamente identificados.

As técnicas de especificação de requisitos auxiliam a reduzir o custo do desenvolvimento

e das manutenções em software e colaboram substancialmente para a qualidade na
implementação de uma solução que atenda às reais necessidades dos usuários.

15
15
UNIDADE
Tipos de Requisitos e sua Elicitação

Para Pfleeger (2004), “É importante que, ao definirmos os requisitos, possamos

identificar se: estes estão corretos, são consistentes, estão completos, são realistas, se
cada requisito descreve algo necessário ao cliente, se estes podem ser verificados ou
rastreados etc.”

O mesmo autor sugere que o documento de definição de requisitos contenha o que

o desenvolvedor precisa saber e o que o cliente gostaria de ver: o propósito geral do
software, os fundamentos e objetivos de desenvolvimento do sistema, a descrição da
abordagem que será utilizada, as características detalhadas do produto e seu ambiente
operacional.

O documento de especificação de requisitos será o resultado obtido com as técnicas

e conceitos que apresentamos nesta unidade.

16
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:

Sites
Introduction – wath is UML
Introduction – wath is UML. Acesso em: 06/04/2018.
https://goo.gl/s8TT6V
Quality Function Deployment
Quality Function Deployment. Acesso em: 06/04/2018.
https://goo.gl/rQgrWh

Livros
Gerenciamento de requisitos
KERR, Eduardo Santos. Gerenciamento de requisitos. São Paulo, Pearson, 2015.
(e-book)

Leitura
Especificação de Requisitos no Domínio de Sistemas de Informação com o Uso de Padrões
BARCELOS, Leonardo e PENTEADO, Rosângela Penteado. Especificação de Requi-
sitos no Domínio de Sistemas de Informação com o Uso de Padrões. Acesso em:
06/04/2018.
https://goo.gl/ejviJ4
Requirements Engineering Practices in Global Software Engineering Organizations
REZA, Ahmad Yandriansyah. Requirements Engineering Practices in Global Softwa-
re Engineering Organizations. Acesso em: 06/04/2018.
https://goo.gl/XLkDu1
A contribuição do JAD para o levantamento de Requisitos
A contribuição do JAD para o levantamento de Requisitos. Acesso em: 06/04/2018.
https://goo.gl/md3a99
Fundamentos básicos de UML
Fundamentos básicos de UML. Acesso em: 06/04/2018.
https://goo.gl/WGwC6X

17
17
UNIDADE
Tipos de Requisitos e sua Elicitação

Referências
FOGGETTI Cristiano, ORG. Gestão ágil de projetos. São Paulo, Pearson, 2015. (e-book).

PAGE-JONES, Meilir. Fundamentos do desenho orientado a objetos com

UML. São Paulo: Makron Books, 2001. (e-book).

PFLEEGER, S. L. Engenharia de software - teoria e prática. 2.ed. São Paulo: Pear-

son/Prentice Hall, 2004. (e-book).

PRESSMAN, R. S. Engenharia de software. 7.ed. Rio de Janeiro: McGraw-Hill do

Brasil, 2011. (e-book).

SCHACH, S. R. Engenharia de software: os paradigmas clássico & orientado a obje-

tos. 7. ed. São Paulo: Bookman, 2009.

SOMMERVILLE, I. Engenharia de software. 9.ed. São Paulo: Pearson, 2001. (e-book).

VAZQUEZ, Carlos E; SIMÕES, Guilherme S. Engenharia de requisitos. São Paulo:

Brasport, 2016.

WAZLAWICK, Raul Sidnei. Análise e design orientados a objetos para sistemas de

informação: modelagem com UML, OCL e IFML. 3.ed. Rio de Janeiro: Campus, 2015.

18