Análise e Especificação de Requisitos

9/24/2017 4.
Anlise e Especificao de Requisitos
Notas de aula de Engenharia de Software (C) Jair C Leite, 2000
Anterior | ndice | Prximo
4. Anlise e Especificao de Requisitos

Os objetivos deste captulo so:
Definir o que so requisitos de software

Introduzir os objetivos da Engenharia de Requisitos
Apresentar tcnicas de comunicao para obter informaes dos clientes e usurios
Apresentar tcnicas para descrever o domnio, usurios e tarefas.
Especificar requisitos funcionais utilizando Casos de Uso
Especificar requisitos no funcionais
4.1 Engenharia de Requisitos

Vimos que o software parte de um sistema computacional mais abrangente e que a Anlise de Sistemas a
atividade de identificar os problemas do domnio, apresentar alternativas de solues e o estudo da
viabilidade de cada uma delas. Uma vez que se tenha feito a anlise do sistema computacional, e delimitado
o escopo do software, os requisitos do software devem ser analisados e especificados.
A anlise e especificao de requisitos de software envolve as atividades de determinar os objetivos de um

software e as restries associadas a ele. Ela deve tambm estabelecer o relacionamento entre estes objetivos
e restries e a especificao precisa do software.
A anlise e especificao dos requisitos de software deve ser vista como uma sub-atividade da anlise de
sistemas. Normalmente ela iniciada juntamente com a anlise do sistema, podendo se estender aps a
elaborao do documento de especificao do sistema e do planejamento do desenvolvimento, quando sero
refinados os requisitos do software.
Anlise e especificao so atividades inter-dependentes e devem ser realizadas conjuntamente. A anlise

o processo de observao e levantamento dos elementos do domnio no qual o sistema ser introduzido.
Deve-se identificar as pessoas, atividades, informaes do domnio para que se possa decidir o que dever
ser informatizado ou no. Pessoas e as atividades que no sero informatizadas devero ser consideradas
entidades externas ao software.
A especificao a descrio sistemtica e abstrata do que o software deve fazer, a partir daquilo que foi
analisado. Ela apresenta a soluo de como os problemas levantados na anlise sero resolvidos pelo
software do sistema computacional. Visa descrever de maneira sistemtica quais as propriedades funcionais
so necessrias para resolver o problema do domnio. A especificao tambm a forma de comunicao
sistemtica entre analistas e projetistas do software.
O objetivo da definio dos requisitos especificar o que o sistema dever fazer e determinar os critrios de
validao que sero utilizados para que se possa avaliar se o sistema cumpre o que foi definido.
4.1.1 O que so requisitos?
Como sistemas computacionais so construdos para terem utilidade no mundo real. Modelar uma parte do
mundo real, o domnio de aplicao uma atividade extremamente importante para se compreender a
necessidade e a importncia do sistema a ser construdo e definir os requisitos que tornam o sistema til.
Requisitos so objetivos ou restries estabelecidas por clientes e usurios do sistema que definem as
diversas propriedades do sistema. Os requisitos de software so, obviamente, aqueles dentre os requisitos de
sistema que dizem respeito a propriedades do software.
https://www.dimap.ufrn.br/~jair/ES/c4.html 1/19
9/24/2017 4. Anlise e Especificao de Requisitos
Um conjunto de requisitos pode ser definido como uma condio ou capacidade necessria que o software
deve possuir (1) para que o usurio possa resolver um problema ou atingir um objetivo ou (2) para atender as
necessidades ou restries da organizao ou dos outros componentes do sistema.
Tradicionalmente, os requisitos de software so separados em requisitos funcionais e no-funcionais. Os

requisitos funcionais so a descrio das diversas funes que clientes e usurios querem ou precisam que o
software oferea. Eles definem a funcionalidade desejada do software. O termo funo usado no sentido
genrico de operao que pode ser realizada pelo sistema, seja atravs comandos dos usurios ou seja pela
ocorrncia de eventos internos ou externos ao sistema.
So exemplos de requisitos funcionais:
"o software deve possibilitar o clculo dos gastos dirios, semanais, mensais e anuais com pessoal".
"o software deve emitir relatrios de compras a cada quinze dias"
"os usurios devem poder obter o nmero de aprovaes, reprovaes e trancamentos em todas as
disciplinas por um determinado perodo de tempo.
A especificao de um requisito funcional deve determinar o que se espera que o software faa, sem a
preocupao de como ele faz. importante diferenciar a atividade de especificar requisitos da atividade de
especificao que ocorre durante o design do software. No design do software deve-se tomar a deciso de
quais a funes o sistema efetivamente ter para satisfazer quilo que os usurios querem.
Requisitos no-funcionais so as qualidades globais de um software, como manutenibilidade, usabilidade,

desempenho, custos e vrias outras. Normalmente estes requisitos so descritos de maneira informal, de
maneira controversa (por exemplo, o gerente quer segurana mas os usurios querem facilidade de uso) e so
difceis de validar.
So exemplos de requisitos no-funcionais:
"a base de dados deve ser protegida para acesso apenas de usurios autorizados".
"o tempo de resposta do sistema no deve ultrapassar 30 segundo".
"o software deve ser operacionalizado no sistema Linux"
"o tempo de desenvolvimento no deve ultrapassar seis meses".
A necessidade de se estabelecer os requisitos de forma precisa crtica na medida que o tamanho e a

complexidade do software aumentam. Os requisitos exercem influncia 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 no seja satisfeito (programas em Java so, em geral, mais lentos).
4.1.2 A Engenharia de Requisitos

Os diversos relacionamento e restries que os requisitos exercem uns sobre os outros so muito difceis de
ser controlados. Principalmente se considerarmos que algumas decises de design que afetam um ou mais
requisitos s sero tomadas mais adiante do desenvolvimento. Por exemplo, a deciso de implementar em
Java pode ser decidida apenas aps o design da arquitetura. Desta forma, os requisitos precisam ser
gerenciados durante todo o desenvolvimento.
A importncia e complexidade desta atividade levou ao surgimento, no incio dos anos 90, da Engenharia
de Requisitos. O objetivo desta denominao ressaltar que o processo de definir os requisitos de software
uma atividade extremamente importante e independente das outras atividades da engenharia de software. Ela
requer fundamentao e processos prprios, e que devem ser planejados e gerenciados ao longo de todo o
ciclo de vida.
Os objetivos da Engenharia de Requisitos podem ser categorizados em trs grupos principais [Zave]:
Investigao de objetivos, funes e restries de uma aplicao de software

Ultrapassar as barreiras de comunicao
Gerar estratgias para converter objetivos vagos em propriedades ou restries especficas
Compreender prioridades e graus de satisfao
Associar requisitos com os vrios agentes do domnio

Estimar custos, riscos e cronogramas
Assegurar completude
Especificao do software
Integrar representaes e vises mltiplas
Avaliar estratgias de solues alternativas que satisfaam os requisitos
Obter uma especificao completa, consistente e no ambgua
Validar a especificao - verificar que ela satisfaz aos requisitos
Obter especificaes que sejam apropriadas para as atividades de design e implementao
Gerenciamento da evoluo e das famlias do software
Reutilizao de requisitos durante o processo de evoluo
Reutilizao de requisitos no desenvolvimento de software similares
Reconstruo de requisitos
A Engenharia de Requisitos deve envolver a documentao das funes, do desempenho, interfaces externas
e internas e atributos de qualidade do Software.
Esta rea inerentemente abrangente, interdisciplinar e aberta. Ela lida com a descrio de observaes do
mundo real atravs de notaes apropriadas.
Os benefcios da Engenharia de Requisitos so:
Concordncia entre desenvolvedores, clientes e usurio sobre o trabalho a ser feito e quais os critrios
de aceitao do sistema.
Uma base precisa para a estimativa dos recursos (custo, pessoal, prazos, ferramentas e equipamentos)
Melhoria na usabilidade, manutenibilidade e outras qualidades do sistema.
Atingir os objetivos com o mnimo de desperdcio
Uma boa especificao de requisitos deve ser:
Clara e no-ambgua
Completa
Correta
Compreensvel
Consistente
Concisa
Confivel
(Veja mais em Dorfman, Merlin - Requirements Engineering)
4.1.3 Tcnicas de levantamento de requisitos

Um dos objetivos da Engenharia de Requisitos ultrapassar barreiras de comunicao entre os clientes e
usurios e os analistas para que os requisitos possam capturados e modelados corretamente
Dentre as tcnicas mais importantes para a comunicao podemos citar trs:
Entrevistas
Observao in loco
Encontros
Estas trs tcnicas so complementares e podem todas ser usadas numa mesma anlise de requisitos. A
entrevista normalmente a primeira tcnica utilizada. Analistas entrevistam clientes para definir os
objetivos gerais e restries que o software dever ter. A entrevista deve ser feita de forma objetiva visando
obter o mximo de informaes do cliente. Diversas sees de entrevistas podem ser marcadas.
Na observao in loco os analista devem estar inseridos na rotina de trabalho da organizao tentando
entender e descrever as principais atividades que so realizadas. Na observao devem ser identificadas quais
as atividades podem ser automatizadas, quem so os potenciais usurios, quais tarefas eles querem realizar
com a ajuda do novo sistema, etc. A observao deve ser complementada com entrevistas especficas com os
futuros usurios.
Os encontros so reunies envolvendo analistas, clientes e usurios destinadas exclusivamente ao

levantamento de informaes, descrio dos problemas atuais e de metas futuras. Os encontros devem ser
realizados em um local neutro (fora da organizao) e normalmente duram poucos alguns dias. Nos
encontros as informaes que vo sendo levantadas vo sendo afixadas em paineis na sala de encontro para
que possam ser analisadas e validadas pelos clientes e usurios. Ao final do encontro os analistas devem
elaborar um relatrio descrevendo os requisitos analisados.
4.1.4 Modelos de documentos de especificao de requisitos

O resultado final da anlise e especificao de requisitos e das outras atividades da fase de defino devem
ser apresentados aos clientes para que eles possam valid-lo. Este documento oferece a concordncia entre
clientes, analistas e desenvolvedores sobre o que deve ser desenvolvido. utilizando este documento que as
atividades da fase de desenvolvimento (design e programao) sero validadas.
Cada desenvolvedor utiliza um modelo especfico para elaborar este documento. A sua estrutura muitas
vezes depende do mtodo que est sendo utilizado. Em linhas gerais este modelo deve ser basicamente
textual, utilizando o mnimo de termos tcnicos, e ilustrados como modelos grficos que demonstrem mais
claramente a viso que os analistas tiveram dos problemas e dos requisitos para o futuro sistema.
Vamos apresentar a seguir dois modelos de documentos encontrados na literatura. Estes modelos descrevem
no apenas a especificao dos requisitos, mas os resultados do estudo de viabilidade e o processo de
desenvolvimento.
Pressman apresenta o seguinte documento de especificao de requisitos de software:

I. Introduo
1. Referncias do Sistema
2. Descrio Geral
3. Restries de projeto do software
II. Descrio da Informao
1. Representao do fluxo de informao

a. Fluxo de Dados
b. Fluxo de Controle
2. Representao do contedo de informao
3. Descrio da interface com o sistema
III Descrio Funcional
1. Diviso funcional em parties

2. Descrio funcional
a. Narativas
b. Restries/limitaes
c. Exigncias de desempenho
d. Restries de projeto
e. Diagramas de apoio
3. Descrio do controle
a. Especificao do controle
b. Restries de projeto
IV. Descrio Comportamental
1. Estados do Sistema
2. Eventos e aes
V. Critrios de Validao
1. Limites de desempenho
2. Classes de testes
3. Reao esperada do software
4. Consideraes especiais
VI. Bibliografia
VII Apndice
Uma proposta alternativa a de Farley. De acordo com ele, um documento de especificao de requisitos
deve possui as seguintes sees:
Viso geral do produto e Sumrio

Ambientes de desenvolvimento, operao e manuteno
Interfaces Externas e Fluxo de Dados
Requisitos Funcionais
Requisitos de Desempenho
Tratamento de Excees
Prioridades de Implementao
Antecipao de mudanas e extenses
Dicas e diretrizes de Design
Critrios de aceitao
ndice Remissivo
Glossrio
4.2 Especificando Requisitos utilizando Casos de Uso

Aps saber quais as tarefas associadas a cada papel de usurio, hora de elaborar os casos de uso (use
cases) que permitem definir as funes de aplicao que o sistema dever oferecer para o usurio. Os casos
de uso podem ser utilizadas durante a anlise e especificao dos requisitos para descrever a funcionalidade
do sistema.
Os casos de uso foram definidos como parte da metodologia de Jacobson: Object-oriented Analysis and
Design - The User Case Driven Approach. A linguagem de modelagem UML (Unified Modeling Language)
apresenta notaes para a representao de casos de uso.
Um caso de uso especifica o comportamento do sistema a ser desenvolvido sem, no entanto, especificar com
este comportamento ser implementado. Os comportamentos descrevem as funes da aplicao que
caracterizam a funcionalidade do sistema. Um caso de uso representa o que o sistema faz e no como o
sistema faz, proporcionando uma viso externa e no interna do sistema.
Cada caso de uso define um requisito funcional do sistema. Por exemplo, num sistema bancrio, consulta de
saldo, emprstimos e saques de dinheiro so exemplos de casos de uso.
O caso de uso descreve um conjunto de seqncias de aes que o sistema desempenha para produzir um
resultado esperado pelo usurio. Cada seqncia representa a interao de entidades externas e o sistema.
Estas entidades so chamadas de atores e que podem ser usurios ou outros sistemas. No caso de usurios,
um ator representa na verdade uma funo de usurios.
Os casos de uso podem ser compostos por outros casos de uso mais especficos. Esta estrutura deve estar em
conformidade com o particionamento do sistema em sub-sistemas. Desta forma tanto possvel descrever
casos de uso que aplicam-se ao sistema global, quanto casos que so especficos para cada uma das partes do
sistema.
Casos de uso tambm podem ser especializados, por exemplo uma consulta pode ser especializada em
consulta de saldo e consulta de extrato, que por sua vez podem ser especializados, cada um , em consultas a
conta-corrente ou a conta-poupana.
Ao definir os requisitos funcionais, o caso de uso define o comportamento, as respostas esperadas e os casos
de testes que devem validar a implementao do sistema.
4.2.1 A representao de casos de uso usando UML

A notao UML ser utilizada neste curso como linguagem de especificao para a maioria das atividades do
ciclo de vida do sistema. A partir de agora vamos introduzir esta notao necessria para representar casos de
uso. Ao longo do curso outros aspectos da linguagem sero introduzidos.
Um caso de uso representado por uma elipse. Cada caso de uso disntigue-se de um outro por um nome que
normalmente um verbo seguido do seu objeto.
Um ator que pode ser uma ou mais funo de usurio representado por uma figura simples de um
indivduo (um boneco-de-palitos).
Os atores so conectados a casos de uso por uma associao representadas por uma linha.
O comportamento associado a cada caso de uso pode ser descrito como um cenrio. Cada cenrio descreve
textualmente o fluxo de eventos ou seqncia que caracteriza o comportamento do ator e as respostas do
sistema. Um cenrio uma instncia do caso de uso.
Por exemplo num caixa eletrnico bancrio, o caso de uso validar cliente pode ser descrito pelo seguinte
cenrio:
Fluxo de eventos principal: O casos de uso inicia quando o sistema solicita ao cliente (do banco)
a sua senha. O cliente fornece os nmeros atravs do teclado. O cliente confirma a senha
pressionando a tecla entre. O sistema checa este nmero e verifica se ele vlido.
Fluxo de evento excepcional: O cliente pode cancelar a transao a qualquer momento

pressionando o boto cancele, reiniciando o caso de uso. No feita nenhuma mudana na conta
do usurio.
Fluxo de evento excepcional: O cliente pode corrigir a senha a qualquer momento antes de
confirmar com a tecla entre.
Fluxo de evento excepcional: Se o cliente fornece um nmero de senha invlido o caso de uso
reiniciado. Se isto acontecer trs vezes seguidas, o sistema cancela o caso de uso e bloqueia por
at uma hora.
Os casos de uso tambm podem ser descritos de maneira mais estruturada e formal, por exemplo, usando
pr- e ps-condies. Diversas tcnicas e notaes para especificaes formais permitem descrever o
comportamento da funes da aplicao em termos de pr- e ps-condies. As pr-condies estabelecem
as condies que devem estar satisfeita antes que a funo seja executada pelo sistema, enquanto que as ps-
condies determinam o que deve ser vlido ao final da execuo. Estes estados iniciais e finais do sistema
descrevem o comportamento independente de como ser implementado, isto , quais os algoritmos, estrutura
de dados e linguagem de programao a serem utilizados. As especificaes formais no so abordadas neste
curso.
Os casos de uso podem ainda ser descritos atravs de outros diagramas UML. Os diagramas de atividades
descrevem os diversos estados e as transies entre cada um deles. Os diagramas de interao permitem
descrever as interaes entre o ator e o componente do sistema que implementa o caso de uso. Estes
diagramas sero estudados mais adiante no captulo 5.
Veja o exemplo acima especificado atravs de diagramas de estados e de atividades na seo 5.2.7.
4.2.3 Diagrama de Casos de Uso em UML
A UML permite elaborar diversos diagramas para visualizao, especificao, construo e documentao de
diversas partes do sistema em diversas etapas do ciclo de vida. Existem cinco tipos de diagramas que
permitem modelar aspectos dinmicos do sistema atravs da UML. O diagrama de casos de uso um
destes diagramas e pode ser utilizado para visualizao, especificao e documentao de requisitos do
sistema.
A especificao dos requisitos visa descrever o que o sistema deve fazer para satisfazer as metas dos usurios
(requisitos funcionais) e quais outras propriedades desejvel que o sistema possua (requisitos no-
funcionais). Vimos que casos de usos, individualmente, descrevem requisitos funcionais. Acrescentandos
Notas aos diagramas de casos de uso podemos especificar tambm os requisitos no-funcionais.
Um diagrama de casos de uso contm:
Casos de Uso
Atores
Relacionamentos de dependncia, generalizao e associaes
Podem ser acrescentadas Notas com em qualquer outro diagrama UML.
Para modelar os requisitos de software de um sistema podemos seguir as seguintes regras.
Estabelea o contexto do sistema identificando os atores (usurios e sistemas externos) associados a

ele.
Para cada ator, considere o comportamento que cada um deles espera ou requer que o sistema possua,
para que as suas metas sejam satisfeitas.
Considere cada um destes comportamentos esperados como casos de uso, dando nomes para cada um
deles.
Analise os casos de uso tentando identificar comportamentos comuns a mais de um deles. Defina esta
parte comum como caso de uso genrico, estabelecendo um relacionamento de generalizao. Tente
identificar outros relacionamentos, como a dependncia entre casos de uso que incluem o
comportamento de outros .
Modele estes casos de uso, atores e seus relacionamentos em diagramas de casos de uso.
Complemente estes casos de uso com notas que descrevam requisitos no-funcionais.
Alm destas regras bsicas, algumas dicas ajudam a construir diagramas mais claros.
D nomes que comuniquem o seu propsito.

Quando existirem relacionamentos, distribua os casos de uso de maneira a minimizar os cruzamentos
de linhas.
Organize os elementos espacialmente de maneira que aqueles que descrevem comportamento
associados fiquem mais prximos.
Use notas para chamar a ateno de caractersticas importantes - as notas no so apenas para os
requisitos no funcionais.
No complique o diagrama, coloque apenas o que essencial para descrever os requisitos. O diagrama
deve ser simples sem deixar de mostrar o que relevante.
4.3 Tcnicas complementares para anlise de requisitos

Definir casos a partir do nada pode ser bastante difcil. Antes de comear a pensar em casos de uso o analista
pode descrever cenrios com situaes do domnio. Estes cenrios contm informaes que podem ser
extradas mais detalhadamente com o objetivo de detalhar os cenrios. Alm dos cenrios, a anlise do perfil
dos usurio e das tarefas que eles executam permitem um maior conhecimento do domnio, possibilitando
uma melhor especificao dos requisitos.
4.3.1 Cenrios
Do ponto de vista de usabilidade, o desenvolvimento de um novo sistema implica na transformao das
tarefas e prticas atuais dos usurios e da organizao. Conhecer a situao atual e antecipar o impacto que
um novo sistema deve ter fundamental para o seu sucesso. Isso ocorre porque quando se introduz novas
tecnologias, parte do contexto de tarefa de uma organizao alterado. Nessa reengenharia, novas tarefas e
prticas so incorporadas enquanto que outras so eliminadas.
O levantamento de informaes sobre as tarefas e os usurios pode ser melhor realizado quando os analistas
procuram descrever situaes do processo de trabalho. Os mtodos baseados em cenrios consistem de uma
coleo de narrativas de situaes no domnio que favorecem o levantamento de informaes, a identificao
de problemas e a antecipao das solues. Cenrios so uma maneira excelente de representar, para clientes
e usurios, os problemas atuais e as possibilidades que podem surgir.
Os cenrios tm como foco as atividades que as pessoas realizam nas organizaes possibilitando uma
perspectiva mais ampla dos problemas atuais onde o sistema ser inserido, explicando porque ele
necessrio. Eles proporcionam um desenvolvimento orientado a tarefas possibilitando maior usabilidade do
sistema.
No objetivo dos cenrios oferecer uma descrio precisa, mas provocar a discusso e estimular novos
questionamentos. eles permitem tambm documentar o levantamento de informaes a respeito dos
problemas atuais, possveis eventos, oportunidades de aes e riscos.
Por sua simplicidade, cenrios so um meio de representao de fcil compreenso para os clientes e
usurios envolvidos (muitas vezes de formao bastante heterognea) que podem avaliar, criticar e fazer
sugestes, proporcionando a reorganizao de componentes e tarefas do domnio. Cenrios oferecem um
"meio-intermedirio" entre a realidade e os modelos que sero especificados possibilitando que clientes,
usurios e desenvolvedores participem do levantamento das informaes e especificao dos requisitos. Em
resumo, os cenrios permitem compreenso dos problemas atuais pelos analistas e antecipao da situao
futura pelo clientes e desenvolvedores.
Elaborando Cenrios
Como toda atividade de anlise e especificao de requisitos, a descrio do domnio atravs de cenrios
requer tcnicas de comunicao e modelagem.
A descrio de cenrios deve ser apoiada pelas trs tcnicas de comunicao vistas anteriormente. Antes de
descrever os cenrios, os analistas devem entrevistar clientes para entender os problemas e requisitos iniciais.
A entrevista com usurios permite que cada um descreva as suas tarefas e os problemas associados a cada
uma delas. A observao direta in loco fundamental para que os analistas possam descrever a situao de
uso como ela realmente vem ocorrendo na prtica.
Aps a elaborao dos cenrios, clientes, usurios e analistas podem participar de encontros para que
possam discutir cada um destes cenrios. Eles podem ser afixados em quadros na parede onde os
participantes possa analis-los e fazer comentrios, possivelmente afixando pequenos pedaos de papel a
cada uma das cenas.
Cenrios podem ser descritos em narrativas textuais ou atravs de storyboards. As narrativas textuais podem
ser descritas livremente, identificando os agentes e as aes que eles participam. possvel utilizar notaes
para descrever roteiros de cinemas ou notaes mais precisas como aquelas utilizadas pela Inteligncia
Artificial para representao de conhecimento.
Uma tcnica que est bastante relacionada com cenrios, por permitir descrever situaes de uso, o
storyboarding. Essa tcnica envolve a descrio atravs de quadros com imagens que ilustram as situaes
do domnio. Cada quadro deve apresentar a cena que descreve a situao, os atores e as aes que cada um
deve desempenhar. Abaixo de cada quadro devem estar descritas aes que os atores desempenham. Os
storyboards so bastante utilizados em cinemas como forma de comunicao entre roteiristas, diretores,
atores e tcnicos.
Existem ferramentas computacionais que podem ser utilizadas para a descrio de cenrios como o
Scenario's Browser [Rosson 99].
Exemplos de cenrios
Como exemplo vamos considerar o domnio de uma locadora de fitas de vdeo.
Cena 1: Cliente procura uma fita com uma certa atriz

Agentes: Cliente, Atendente, Balconista
Aes:
Cliente entra na loja e dirige-se at a atendente.

Cliente: - Eu gostaria de alugar um filme com a atriz que ganhou o oscar este ano.
Atendente: - Algum especfico?
Cliente: - No, mas que no seja policial ou ao.
Atendente: Voc sabe o nome dela?
Cliente: No.
A atendente pergunta balconista.
Atendente: - Voc sabe o nome da atriz que ganhou o Oscar 99?
Balconista: - Ih. um nome bem complicado. S sei que comea com G e o sobrenome algo
parecido com Paltrow.
Cliente: isto mesmo.
A atendente ento procura no fichrio de atrizes as que comeam com G. No encontra nenhum nome
parecido com o que a balconista falou. Ela ento lembra-se de consultar uma revista especializada com
os ganhadores do Oscar 99 e l descobre o nome correto da atriz. Entretanto, no existe realmente
ficha alguma com os filmes estrelados por esta atriz. O fichrio est desatualizado.
A atendente procura nas estantes alguns filmes e lembra-se de dois: O Crime Perfeito e Seven e
mostra-os ao cliente. O cliente recusa-se dizendo que no gosta do gnero destes filmes e pergunta
pelo filme vencedor do Oscar.
A atendente responde: - Shakespeare Apaixonado? Ainda no saiu em vdeo.
Cena 2: O cliente procura por filmes de um certo gnero

Agentes: Cliente, Atendente, Balconista
Aes:
Cliente: - Eu gostaria de comprar um filme de ao.

Atendente: - Ns apenas alugamos.
Cliente: - Tudo bem. Ento, por favor, me d algumas dicas de filmes de ao.
Atendente: Com algum ator especial.
Cliente: Pode ser com Chuck Norris, Van Dame, Statellone, Charles Bronson
Atendente: Temos estes aqui.
A atendente apresenta dez filmes. O cliente escolhe cinco e fica em dvida se j assistiu outros trs.
Ele tambm pergunta atendente se os outros dois filmes so bons. Aps conversar durante alguns
minutos com a atendente que entende muito do gnero, decide ficar com seis fitas. A atendente
encaminha o cliente balconista para calcular o valor da locao e o prazo de devoluo. Aps
consultar as tabelas de preos e prazos, a balconista apresenta trs planos de pagamento.
Balconista: - Se voc devolver em um dia, paga apenas R$ 6,00. Se devolver em seis dias paga R$
12,00 e se devolver em uma semana paga R$ 15,00. Aps este prazo paga mais R$ 2,00 por fita, por
dia.
Cena 3: Cliente procura por filme usando o sistema de consulta

Agentes: Cliente e Sistema de Consulta
Aes:
Joo gostaria de assistir a um filme de guerra. Ele vai a uma locadora de fitas e, chegando l, utiliza
um sistema de consulta. Ele no lembra o ttulo nem o diretor, mas sabe que se passava na guerra do
Vietn e lembra bastante da trilha sonora. Utilizando o sistema ele solicita as opes de filmes de
guerra. Os sistema oferece a ele as possibilidades de escolher os filmes por local da guerra ou por
poca. Joo escolhe a sua opo (guerra) e obtem uma lista com dezenas de filmes sobre o vietnam.
Ele pode organizar esta lista, por diretor, atores e ttulo. Na tela do sistema aparecem a ilustrao com
o cartaz de divulgao do filme e uma opo para ele visualizar o trailler. O sistema, entretanto, no
possibilita ele ouvir a trilha sonora.
Aps analisar algumas opes ele finalmente encontra o filme desejado, mas uma informao na tela
do sistema indica que o filme est alugado. Joo quer saber quando o filme ser devolvido, mas esta
informao no consta no sistema. Ele entretanto pode reservar e o sistema enviar para ele um e-mail
avisando quando o filme estiver disponvel. Ele sai da loja pensando "Que tempo perdido. Seria
melhor que eu pudesse consultar o sistema de casa".
4.3.2 Questionamento Sistemtico

A descrio de informaes do domnio atravs de narrativas s efetivamente realizada se o processo de
compreenso por parte dos analistas e projetista for realizado de maneira sistemtica [J. Carroll et al. 94]. O
questionamento sistemtico uma tcnica que permite ao analista obter, a partir dos cenrios, uma rede de
proposies na qual identifica-se agentes (atores), aes (processos de casos de uso), e objetos
(informaes).
O questionamento sistemtico uma tcnica psico-lingustica que permite a psiclogos e lingistas

examinar o contedo e a estrutura de informaes contidas numa narrativa. Uma narrativa um sumrio de
um conjunto de eventos e aes envolvendo agentes e objetos do mundo. Nem todas as informaes
integrantes do contexto so passadas atravs da narrativa. Muitas dessas informaes so inferidas do
conhecimento cultural de cada indivduo. Outras, entretanto, precisam ser obtidas diretamente na fonte, isto
, junto ao autor da narrativa. Essa tcnica foi desenvolvida para se entender melhor o processo de
compreenso de estrias em narrativas. O objetivo compreender tudo o que envolve o contexto daquilo que
est sendo passado na narrativa.
Aplicando essa tcnica no processo de anlise de domnios, os especialistas devem descrever em narrativas
seu conhecimento do domnio. Entretanto, esse conhecimento muito mais abrangente. O questionamento
sistemtico permite obter todo o conhecimento que est alm do que foi comunicado na narrativa. Assim,
analistas e projetista podem utilizar essa tcnica para adquirir mais eficazmente conhecimento sobre o
domnio e inferir objetos e interaes que no esto descritos na narrativa. Isto ocorre usando-se cada
sentena ou afirmao da narrativa como ponto de entrada na complexidade do problema.
Nessa tcnica, cada questo uma ponte entre uma idia e outra. Uma resposta a uma questo sobre um
componente da narrativa revela outras conexes que so crticas para o seu entendimento. Realizando,
sistematica e exaustivamente muitos tipos de questes sobre componentes da narrativa e iterativamente
fazendo perguntas sobre as respostas geradas, o analista elabora um mapa conceitual (rede de proposies)
que representa as estruturas do conhecimento do domnio.
Os passos do mtodo consistem de:
1. Gerao do cenrio - as narrativas que compe o cenrio devem ser decritas pelo especialista no
domnio. O analista pode motiv-lo fazendo perguntas como num processo convencional de entrevista
(questes de elicitao do cenrio).
2. Elaborao da rede de proposies - as narrativas devem ser simplificadas e expressas atravs de

proposies.
3. Anlise - a partir das proposies pode-se determinar as tarefas (aes e objetos) e usurios
(agentes das aes).
4. Questionamento sistemtico - novas proposies podem ser elaboradas atravs de questes que
so feitas sobre elementos das proposies anteriores, num processo iterativo.
Nos passos iniciais obtem-se informaes sobre agentes, interaes e objetos abstratos do domnio. Usando a
tcnica, pode-se chegar a um conhecimento mais profundo do domnio que permite aos analistas e projetista
a elaborao de modelos funcionais do sistema.
Exemplo
Considere o seguinte cenrio sobre um caixa eletrnico.
Questo de elicitao do cenrio:
Como posso sacar R$ 100,00 do caixa eletrnico?
Cenrio:
Primeiro ponha o seu carto do banco no caixa eletrnico, digite a sua senha e pressione o boto
"saque rpido". Depois pegue o dinheiro.
As duas sentenas do cenrio acima contm quatro proposies:
CLIENTE -- pe -- CARTO
CLIENTE -- digita -- SENHA
CLIENTE -- pressiona -- BOTO-DE-SAQUE-RPIDO
CLIENTE -- pega -- DINHEIRO
A partir dessas proposies, o analista determina que o carto e o cliente so agentes de aes. Numa anlise
voltada para a elicitao de requisitos da interao, seria determinado como usurio do sistema, o cliente. A
aes so portanto: digita, pressiona e pega. So objetos da interao a senha, o boto e o dinheiro. Outros
objetos so o caixa eletrnico e o carto. preciso determinar que tipo de objetos so esses. Uma outra
dvida a respeito do carto ser objeto ou agente.
Obviamente, como esse exemplo bastante simples e a aplicao tambm muito conhecida, parece
desnecessrio obter mais conhecimentos a respeito. Entretanto, como o objetivo aqui exemplificar a
tcnica, mostraremos como pode-se questionar a respeito dessa aplicao.
O analista deve ento realizar uma srie de questes sobre as proposies. Nesse questionamento o analista
precisa determinar qual o relacionamento entre a resposta e a proposio que originou a pergunta.
As questes da categoria por que, visam responder "razes" (metas) e "causas" a respeito de eventos da
narrativa. As questes da categoria como oferecem maiores detalhes a respeito de determinados eventos,
permitindo determinar sub-tarefas e maiores detalhes sobre a interao. Questes da categoria o que podem
ser feitas sobre objetos, e revelam atributos e hieraquias de objetos. Perguntas de verificao podem ser feitas
para se saber se as proposies esto sendo entendidas corretamente. As perguntas de verificao so as que
tm resposta sim/no. Uma taxonomia mais completa ainda est sendo pesquisada pelos autores do mtodo.
Continuando o exemplo anterior a tabela abaixo descreve uma seo de questionamento sistemtico:
Questes "por que"
Por que o carto entra no caixa eletrnico?

_ Para iniciar. (evento conseqente)
_ E ento a mquina saber quem o cliente. (estado conseqente)
Por que o cliente digita sua senha?
_ Para provar que ele o usurio autorizado. (meta)
Por que o cliente pressiona o boto de saque rpido?

_ Porque o boto para saques de R$ 100,00 (critrio de descriminao).
_ Para evitar a digitao (cenrio alternativo).
_ Porque ele est com pressa (causa)
Questes "como"
Como o cliente pe o carto?

_ O cliente tira o carto de sua bolsa e
_ insere no local apropriado no caixa eletrnico..
Como o cliente digita a senha?
_ Pressionando os botes adequados.
Como o cliente pressiona o boto de saque rpido?
_ Colocando o seu dedo nele.
Questes "o que"
O que um boto de saque rpido?

_ um tipo de boto que se pode pressionar.
O que um boto?
_ um dispositivo de controle no painel do caixa eletrnico.
Observe que se o analista estivesse utilizando essa tcnica para num mtodo orientado a objetos, outras
questes poderiam ser realizadas com outros objetivos de acordo com as necessidades do mtodo, como, por
exemplo, para determinar classes e hierarquia de classes.
Aps os cenrios estarem desenvolvidos, os analistas devem trabalhar em conjunto com os usurios para
avali-los e refin-los. Isto pode ser feito, por exemplo, colocando-se posters numa sala pela qual os usurios
podem circular livremente e observar os diversos cenrios. Cada cenrio deve apresentar quadros (desenhos,
grficos, fotografias, etc.), usando storyboards por exemplo, e uma descrio narrativa da tarefa. Os usurios,
munidos de papeis e lpis, podem fazer anotaes (crticas e sugestes) e anex-las a cada poster.
Consideraes finais sobre cenrios

O resultado da modelagem atravs de cenrios uma base para a compreenso de quem so os usurios,
quais a tarefas envolvidas e quais funes a interface e a aplicao devem prover, de maneira que, j se possa
ter meios de garantir a usabilidade do sistema.
A idia de cenrios em anlise no est necessariamente associada tcnica de questionamento sistemtico.

Os cenrios so extremamente teis para descrio do domnio. A tcnica sistematiza o processo de
compreenso do conhecimento adquirido.
Os mtodos em geral, e esse no deve fugir regra, devem ser usados, no como uma camisa-de-fora que
limite o processo de anlise, mas como ferramentas que orientam os analistas e aumentam sua capacidade
intelectual.
4.4 Anlise de Usurios

Para que o sistema seja construdo como uma ferramenta de apoio s atividades de usurios no domnio de
aplicao, preciso conhecer quem so os usurios e quais as suas necessidades, isto quais tarefas eles
necessitam realizar. A anlise de usurios deve determinar quem eles so e quais tarefas eles normalmente
fazem no domnio. Ela envolve a descrio dos diferentes papis de usurios e qual o conhecimento,
capacidade e cultura possuem os futuros usurios do sistema.
4.4.1 Anlise de Perfis de Usurios

A anlise do perfil dos diversos usurios do sistema descreve as vrias caractersticas que podem influenciar
as decises dos projetistas no desenvolvimento do sistema. Os objetivos so assegurar que certas
propriedades do sistema estejam adequadas ao conhecimento, cultura e capacidades do usurio, e que
potenciais deficincias sejam levadas em considerao. Por exemplo, para um software de acompanhamento
de pacientes em hospital, certos termos especficos da medicina devem ser includos nas telas do sistema e
devem ser evitados termos tcnicos de informtica ( fornea informaes patolgicas ao invs de entrar
dados da doena). Para usurios com alguma deficincia fsica ou motora, elemento da interface devem ser
modificados, como por exemplo, tela de maior tamanho e letras maiores para deficientes visuais.
Os perfil do usurio pode ser analisado atravs de formulrios do tipo:
Perfil do Usurio
Nome do Sistema: ____________________________________________________________________
Funo do Usurio: ___________________________________________________________________
Conhecimento e Experincia do Usurio

Nvel educacional Lngua Nativa Nvel de leitura e expresso
( ) Ensino fundamental ( ) Portugus ( ) Excelente
( ) Ensino mdio ( ) Ingls ( ) Bom
( ) Graduao ( ) outra: ___________________ ( ) Regular
( ) Ps-Graduao ( ) Ruim
Experincia com computadores Experincia com sistema similar Conhecimento sobre o domnio
( ) Iniciante ( ) Utiliza bastante um similar ( ) Elementar
( ) Intermedirio ( ) J utilizou um similar ( ) Intermedirio
( ) Experiente ( ) Nunca utilizou um similar ( ) Especialista no domnio
Caractersticas Fsicas
Manipulao Deficincias
( ) Canhoto ( ) Auditiva
( ) Destro ( ) Visual
( ) Ambidestro ( ) Corporal
( ) Vocal
O perfil deve dar as informaes necessrias que os desenvolvedores precisam para tomar as suas decises.
A anlise do perfil pode ser adaptada de acordo com as caractersticas do sistema e com as necessidades de
analistas e desenvolvedores. Por exemplo, pode ser interesse dos designers saber se os usurios tm algumas
experincia com interfaces grficas e qual o padro (Windows, Motif, Macintosh, etc.) eles esto
acostumados a utilizar.
4.4.2 Papis de Usurios

O papel (ou funo ) especfico de cada usurio definido pelas tarefas que eles realizam. Numa
organizao, as pessoas trabalham juntas, de maneira estruturada. A estrutura da organizao define
relacionamentos entre as pessoas. A implicao imediata dos diferentes papis de cada usurio so as
diferentes tarefas que eles iro realizar. Algumas tarefas podem ser comuns a diferentes papis de usurios,
enquanto outras podem ser exclusivas de papis especficos.
O conceito de papel de usurio permite abstrairmos as caractersticas especficas de um usurio e enfatizar

nas diferentes necessidades associadas a funo que ele exerce. Para cada papel devemos associar um
conjunto de funes, como veremos mais adiante.
No domnio do departamento de informtica da UFRN podemos identificar como papis de usurios:

secretrio do departamento, chefe, coordenador de graduao, secretrio da coordenao, coordenador de
ps-graduao, professor, aluno, funcionrio de administrao de laboratrios e usurio externo.
4.5 Anlise e Modelagem de Tarefas

Os cenrios permitem o levantamento e a descrio mais global das informaes, das tarefas e dos problemas
do domnio. O perfil de usurio descreve as caractersticas de usurios em termo de conhecimento, cultura,
capacidades e limitaes. A anlise de tarefas visa determinar quais as atividades que os usurios (ou cada
papel de usurio) devem realizar. Esta informao essencial para se especificar os requisitos funcionais,
determinando a funcionalidade do software. Para que o sistema possa ser construdo para que estes
problemas sejam resolvidos, ele deve ser uma ferramenta auxiliar na realizao das tarefas de cada usurio.
Uma tarefa , genericamente, uma atividade na qual um ou mais agentes tentam atingir uma meta
especificada, atravs de uma mudana de estado em uma ou mais entidades do mundo. Num domnio de
aplicao, as tarefas so as atividades que modificam estados de elementos deste domnio. A construo de
um sistema computacional em um certo domnio tem por objetivo apoiar a realizao de algumas destas
atividades. Durante o processo de anlise, deve-se determinar quais as do domnio e identificar quais delas
podem ser auxiliadas pelo sistema.
A anlise e modelagem de tarefas visa descrever as principais as tarefas que cada usurio do sistema ter de
realizar para que os projetistas possam elaborar quais funes o sistema deve oferecer para que elas possam
ser desempenhadas. Estas tarefas so descritas em termos de metas e um planejamento de possveis
atividades necessrias para atingi-las. As tarefas podem ser descritas a partir das informaes obtidas nos
cenrios e devem ser agrupadas por papis de usurio.
A anlise de tarefas pode ser utilizadas nas diversas fases do ciclo de vida do software. Na fase de anlise de
requisitos ela pode ser utilizada para identificar problemas na maneira de como as tarefas vm sendo
realizadas. Os modelos de tarefas tambm podem descrever quais tarefas podem ser realizadas com o auxlio
do sistema e como os usurios gostariam que ela fosse realizada. A anlise de tarefa tambm utilizada na
avaliao do sistema para se determinar se como os usurios esto utilizando o sistema e se os objetivos
foram atingidos. Nestes casos, a anlise de tarefas ajuda ao projetista da interface ter uma viso da aplicao
sob a perspectiva do usurio, isto , um modelo das tarefas do usurio quando executando sesses da
aplicao.
4.5.1 Modelo de tarefas como base para a especificao de requisitos funcionais

A anlise e modelagem de tarefas pode ser utilizada como base para a especificao de requisitos funcionais.
Para isto preciso descrever as metas associadas a cada papel de usurio, que permitiro saber o que os
usurio querem.
Resultados da psicologia cognitiva mostram que as pessoas realizam tarefas estabelecendo metas e
elaborando um plano para cada uma delas. O planejamento consiste numa decomposio hierrquica de
metas em sub-metas at que elas possam ser atingidas por operaes. O plano ou mtodo , portanto, uma
estrutura de sub-metas e operaes para se atingir um certa meta. As operaes correspondem a aes
bsicas humanas, isto , aquelas que qualquer pessoa pode e sabe como realizar. So exemplos de operaes
escrever uma palavra ou frase, ler uma informao, falar uma palavra ou frase, andar, relembrar, mover um
objeto, pressionar um boto de controle e vrias outras.
Por exemplo, suponhamos que uma pessoa tem como meta avisar a um amigo, atravs de uma carta, que
sua filha nasceu. Para atingir seu objetivo a pessoa deve estabelecer duas sub-metas: Escrever a carta e
Coloc-la no correio. A sub-meta escrever carta pode ser atingida pelo mtodo: Conseguir papel e lpis e
Escrever mensagem. Escrever mensagem j pode ser considerada uma operao, enquanto que conseguir
papel e lpis requer um novo planejamento que determine as seguintes operaes: ir at o escritrio, abrir o
armrio, pegar o papel e o lpis, lev-los at a mesa.
O gro de refinamento do que podemos considerar com sendo uma operao bastante subjetivo. Vai
depender das dificuldades de quem realiza o plano. Na prtica o plano necessrio quando a pessoa que vai
realizar as aes no sabe ainda qual o mtodo. Com a experincia o mtodo torna-se automtico e podemos
considerar uma sub-meta como uma operao
Na utilizao de um sistema computacional, os usurios realizam tarefas com o objetivo de atingir certas
metas. Uma meta um determinado estado do sistema ou de objetos do sistema ao qual o usurio quer
chegar. Ao estabelecer a meta o usurio deve realizar um planejamento decompondo a meta em sub-metas
at que ele saiba que existe uma determinada funo do sistema que permita que sua meta seja atingida. O
caso agora um pouco diferente do planejamento anterior, pois no o usurio quem vai realizar a operao
desejada, mas o sistema. A decomposio deve ocorrer at que ele identifique que o sistema tem uma
determinada funo que quando executada realiza a operao necessria para que sua meta seja atingida.
Chamamos estas operaes que o sistema executa para satisfazer as metas do usurio de funo da
aplicao. O conjunto de funes da aplicao determina a funcionalidade do sistema.
Vejamos um exemplo. Suponha que o usurio esteja escrevendo uma carta utilizando um editor de texto e
tenha como meta formatar um documento.Para atingir esta meta ele estabelece as seguintes sub-metas:
Formatar pgina, Formatar pargrafos, Formatar fontes. Para cada uma destas sub-metas ele estabelece
novas sub-metas at que ele identifique no software funes que o sistema pode realizar que permitam que as
sub-metas sejam atingidas. Por exemplo, formatar pgina pode ser decomposta na funo da aplicao
especificar tamanho da pgina e na sub-meta definir margens. Esta ltima por sua vez pode ser atingida
pelas operaes especificar valor da margem superior, especificar valor da margem inferior, especificar
valor da margem esquerda e especificar valor da margem direita.
Vejamos o plano deste usurio
META: Formatar documento

PLANO:
Formatar pgina (sub-meta)
especificar tamanho da pgina (funo da aplicao )
Definir margens (sub-meta)
especificar valor da margem superior (funo da aplicao)
especificar valor da margem inferior (funo da aplicao)
especificar valor da margem esquerda (funo da aplicao)
especificar valor da margem direita (funo da aplicao)
Formatar pargrafos (sub-meta)
selecionar pargrado (funo da aplicao)
Especificar atributos do pargrafo (sub-meta)
especificar espaamento (funo da aplicao)
especificar recuos (funo da aplicao)
...
Formatar fontes (sub-meta)
...
O modelo de tarefas extremamente til para determinarmos as metas dos usurios e quais funes da
aplicao eles gostariam que o sistema oferecesse. Por exemplo, a especificao dos requisitos pode
determinar que deve existir uma funo da aplicao para formatar documento de maneira que a meta do
usurio pudesse ser atingida pelo sistema sem a necessidade de planejamento algum.
importante ressaltar que uma meta pode ser satisfeita por uma nica ou por vrias funes da aplicao e
que tambm mais de um mtodo pode ser atingido uma mesma funo da aplicao.Por exemplo, ao utilizar
o Word 7.0, o usurio pode ter como meta formatar um estilo. Ao construir o seu plano o usurio em
determinado momento pode estabelecer a sub-meta Especificar atributos do pargrafo. Esta sub-meta requer
as mesmas funes de aplicao do plano para a meta formatar pargrafo. Assim, temos um grupo de
funes da aplicao que so utilizadas para duas (ou mais) metas distintas.
Para que o usurio solicite ao sistema que execute uma determinada funo de usurio, ele deve realizar
operaes que correspondam a um comando de funo. Por exemplo, para o usurio solicitar ao sistema
operacional que realize a funo de copiar um arquivo de um diretrio para outro ele deve escrever um
comando do tipo copy nome1 dir1 dir2 ou se estiver numa interface grfica, mover o cone correspondente
ao arquivo da janela do diretrio para a do outro diretrio. Ao realizar o comando, o usurio precisa realizar
operaes com os dispositivos de interface do sistema, como pressionar mouse, digitar nmero, teclar enter,
etc.
Apenas com a descrio das operaes do usurio que um plano para atingir uma meta fica completo.
Quando o sistema est pronto, o plano tem que determinar exatamente as operaes necessrias para
comandar a funo e, conseqentemente, ter a meta atingida com o auxlio do sistema.
Na especificao de requisitos suficiente decompor as metas que o usurio quer atingir nas correspondentes
sub-metas. Caber ao designer do software determinar qual o conjunto de funes que permita atingir o
maior nmero possvel de metas para cada papel de usurio e quais devem ser os comandos de interface para
cada uma das funes.
4.5.2 Modelagem de Tarefas usando GOMS

Neste curso, utilizaremos a anlise de tarefas na especificao de requisitos para determinar as tarefas que os
usurios necessitam realizar com o sistema a ser construdo. Para isto utilizaremos um mtodo especfico que
utiliza o modelo GOMS simplificado. O modelo GOMS (Goals, Operators, Methods, and Selection Rules)
oferece uma abodagem de anlise da tarefa baseada num modelo do comportamento humano que possui trs
subsistemas de interao: o perceptual (auditivo e visual), o motor (movimentos brao-mo-dedo e cabea-
olho), e cognitivo (tomadas de deciso e acesso a memria). O modelos GOMS descreve o comportamento
dinmico da interao com um computador, especificando-se:
Metas - Uma aplicao desenvolvida para auxiliar os usurios atingirem metas especficas. Isso
requer uma srie de etapas. Dessa forma, uma meta pode ser decomposta em vrias submetas,
formando uma hierarquia.
Operadores - So as aes humanas bsicas que os usurios executam.
perceptual - operaes visuais e auditivas (olhar a tela, escutar um beep).
motor - movimentos brao-mo-dedo e cabea-olho (pressionar uma tecla).
cognitivo - tomadas de deciso, armazenar e relembrar um item da memria de trabalho.
Mtodos - Um mtodo uma sequncia de passos para se atingir uma meta. Dependendo do nvel da
hierarquia, os passos num mtodo podem ser submetas, operadores ou a combinao de ambos.
Regras de Seleo - Pode existir mais de um mtodo para se atingir uma meta. Uma regra de seleo
especifica certas condies que devem ser satisfeitas antes que um mtodo possa ser aplicado. Uma
regra de seleo uma expresso do tipo "condio-ao".
O GOMS permite que se construa modelos de tarefas bem mais complexos e detalhados do que o necessrio
numa tarefa de anlise para a especificao de requisitos. Usaremos uma verso simplificada do GOMS,
pois:
o modelo da tarefa no dever descrever informaes de design da interface, uma vez que ela
ainda no foi construda;
o analista no um especialista em psicologia cognitiva;
o modelo simplificado pode ser expandido para o original, o que bastante til.
1. Diretrizes do Modelo de Tarefas Simplificado
Uma vez que a hierarquia de metas representa um aumento no nvel de detalhe, se nos limitarmos descrio
de metas e submetas de mais alto nvel, nenhuma deciso de design ser envolvida.
Faa a anlise "top-down" - comece das metas mais gerais em direo as mais especficas.
Use termos gerais para descrever metas - no use termos especficos da interface.
Examine todas as metas antes de descer para um nvel mais baixo - isso facilita reuso de metas.
Considere todas as alternativas de tarefas - as regras de seleo possibilitam representar
alternativas.
Use sentenas simples para especificar as metas - estruturas complexas indicam a necessidade
de decomposio da meta em submetas.
Retire os passos de um mtodo que sejam operadores - os operadores so dependentes da
interface.
Pare a decomposio quando as descries estiverem muito detalhadas - quando os mtodos
so operadores ou envolvem pressuposies de design.
1. Modelagem da Tarefa para aplicaes com mltiplas funes de usurios.
Se, para uma determinada aplicao, a funo do usurio for um fator crtico dominante na anlise de
usurios, deveremos ter modelos de tarefas diferentes para cada funo de usurio. No GOMS
simplificado, veremos como representar as tarefas para cada usurio num s modelo. Antes de
estudarmos a notao do modelo, vejamos algumas regras para modelos com mltiplas funes de
usurios:
Inicie especificando metas de alto nvel para cada funo de usurio.

Se mais de um compartilham a mesma meta, agrupe-os sob uma s.
Se todos compartilham a mesma meta, retire as referncias a funes de usurio.
2. Notao
1. Notao para Funes de Usurios.
Funes de usurios distintas sero denotadas pelo smbolo FU seguido por um nmero.
ex.: Gerente de vendas (FU1), balconista (FU2), caixa (FU3)
A descrio de cada funo de usurio a primeira parte do modelo de tarefas.
ex.: Gerente de vendas (FU1): responsvel pela vendas nas lojas. Tem acesso a todos os
dados do sistema.
Um ponto-e-vrgula (;) usado para separar o smbolo da funo do usurio do restante da

notao do modelo de tarefas.
ex.: FU1;...
Se uma meta usada para mais de uma funo de usurio, elas devem ser separadas por uma
vrgula (,).
ex.: FU1, FU2; ...
Um asterisco (*) usado se uma meta aplicada a todas as funes de usurios.
ex.: *;...
1. Notao para especificao de metas
Cada passo num mtodo numerado numa ordem seqencial, com cada nvel de decomposio
separado por um ponto (.), e com a endentao apropriada para reforar a noo de hierarquia.
Aps o ltimo nmero usa-se dois-pontos (:).
ex.: FU2; 2.1: Anotar correes.
Um comentrio comea com duas barras inclinadas para direita (//) e acaba ao final da linha.
ex.: // Para fazer as anotaes o balconista dever examinar as

// listagens produzida durante as vendas do dia.
FU2; 2.1: Anotar correes
Notao para Mtodos e Regras de Seleo
Se uma meta possui mais de um mtodo para ser atingida, uma letra do alfabeto usada de
forma ordenada aps o nmero que descreve a meta.
ex.:
FU2; 2: Fazer relatrio de vendas (meta)
FU2; 2A: ... (mtodo A)
FU2; 2B: ... (mtodo B)
As regras de seleo e o mtodo associado so descritos como pares "condio-ao", logo aps
a notao numrica da meta.
ex.: FU2; 2A: se (dia de hoje for sbado)
ento (fazer relatrio semanal)
1. Reutilizando Metas
Um aspecto importante dessa notao que pode-se reutilizar metas, simplesmente usando o
mesmo nmero de uma meta preexistente.
ex.:
FU2; 2.1: Anotar correes. (meta preexistente)
...
FU1, FU3; 3: Modificar livro-caixa.
FU1, FU3; 3.1: Procurar lotes em aberto.
FU1, FU3; 2.1: Anotar correes. (meta reusada)
FU1, FU3; 3.3: Recalcular valores.
2. Diretrizes adicionais
Delimite os passos de um mtodo entre chaves: {}.

Em aplicaes com apenas uma funo de usurio, no necessrio incluir a notao de funo
usurio antes de cada meta.
Num nvel de decomposio onde todas as metas tm o mesmo nmero-prefixo, apenas o
nmero que indica a seqncia naquele nvel necessrio.
A diretriz anterior se aplica tambm notao de funo de usurio.
Ao reutilizar uma meta anterior necessrio usar a notao completa para ela.
ex.: FU1, FU3; 3: Modificar livro-caixa.
1: Procurar lotes em aberto.
2.1: Anotar correes. (meta reusada)
3: Recalcular valores.
Anterior | ndice | Prximo
(C) Jair C Leite, 2000 ltima atualizao: 25/04/01

Análise e Especificação de Requisitos

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Análise e Especificação de Requisitos

Uploaded by

Copyright:

Available Formats

9/24/2017 4.

Anlise e Especificao de Requisitos

Notas de aula de Engenharia de Software (C) Jair C Leite, 2000

Anterior | ndice | Prximo

4. Anlise e Especificao de Requisitos

Definir o que so requisitos de software

4.1 Engenharia de Requisitos

A anlise e especificao de requisitos de software envolve as atividades de determinar os objetivos de um

Anlise e especificao so atividades inter-dependentes e devem ser realizadas conjuntamente. A anlise

4.1.1 O que so requisitos?

Tradicionalmente, os requisitos de software so separados em requisitos funcionais e no-funcionais. Os

So exemplos de requisitos funcionais:

Requisitos no-funcionais so as qualidades globais de um software, como manutenibilidade, usabilidade,

So exemplos de requisitos no-funcionais:

A necessidade de se estabelecer os requisitos de forma precisa crtica na medida que o tamanho e a

4.1.2 A Engenharia de Requisitos

Investigao de objetivos, funes e restries de uma aplicao de software

Associar requisitos com os vrios agentes do domnio

Os benefcios da Engenharia de Requisitos so:

Uma boa especificao de requisitos deve ser:

(Veja mais em Dorfman, Merlin - Requirements Engineering)

4.1.3 Tcnicas de levantamento de requisitos

Dentre as tcnicas mais importantes para a comunicao podemos citar trs:

Os encontros so reunies envolvendo analistas, clientes e usurios destinadas exclusivamente ao

4.1.4 Modelos de documentos de especificao de requisitos

Pressman apresenta o seguinte documento de especificao de requisitos de software:

II. Descrio da Informao

1. Representao do fluxo de informao

III Descrio Funcional

1. Diviso funcional em parties

IV. Descrio Comportamental

Viso geral do produto e Sumrio

4.2 Especificando Requisitos utilizando Casos de Uso

4.2.1 A representao de casos de uso usando UML

Fluxo de evento excepcional: O cliente pode cancelar a transao a qualquer momento

4.2.3 Diagrama de Casos de Uso em UML

Um diagrama de casos de uso contm:

Podem ser acrescentadas Notas com em qualquer outro diagrama UML.

Para modelar os requisitos de software de um sistema podemos seguir as seguintes regras.

Estabelea o contexto do sistema identificando os atores (usurios e sistemas externos) associados a

D nomes que comuniquem o seu propsito.

4.3 Tcnicas complementares para anlise de requisitos

Como exemplo vamos considerar o domnio de uma locadora de fitas de vdeo.

Cena 1: Cliente procura uma fita com uma certa atriz

Cliente entra na loja e dirige-se at a atendente.

Cena 2: O cliente procura por filmes de um certo gnero

Cliente: - Eu gostaria de comprar um filme de ao.

Cena 3: Cliente procura por filme usando o sistema de consulta

4.3.2 Questionamento Sistemtico

O questionamento sistemtico uma tcnica psico-lingustica que permite a psiclogos e lingistas

Os passos do mtodo consistem de:

2. Elaborao da rede de proposies - as narrativas devem ser simplificadas e expressas atravs de

Como posso sacar R$ 100,00 do caixa eletrnico?

As duas sentenas do cenrio acima contm quatro proposies:

Questes "por que"

Por que o carto entra no caixa eletrnico?

Por que o cliente pressiona o boto de saque rpido?

Como o cliente pe o carto?

Questes "o que"

O que um boto de saque rpido?

Consideraes finais sobre cenrios

A idia de cenrios em anlise no est necessariamente associada tcnica de questionamento sistemtico.

4.4 Anlise de Usurios