Notas de aula de Engenharia de Software                              (C) Jair C Leite, 2000 
Anterior | Índice | Próximo

4. Análise e Especificação de Requisitos

Os objetivos deste capítulo são:

4.1 Engenharia de Requisitos

Vimos que o software é parte de um sistema computacional mais abrangente e que a Análise de Sistemas é a atividade de identificar os problemas do domínio, apresentar alternativas de soluções e o estudo da viabilidade de cada uma delas. Uma vez que se tenha feito a análise do sistema computacional, e delimitado o escopo do software, os requisitos do software devem ser analisados e especificados.

A análise e especificação de requisitos de software envolve as atividades de determinar os objetivos de um software e as restrições associadas a ele. Ela deve também estabelecer o relacionamento entre estes objetivos e restrições e a especificação precisa do software.

A análise e especificação dos requisitos de software deve ser vista como uma sub-atividade da análise de sistemas. Normalmente ela é iniciada juntamente com a análise do sistema, podendo se estender após a elaboração do documento de especificação do sistema e do planejamento do desenvolvimento, quando serão refinados os requisitos do software.

Análise e especificação são atividades inter-dependentes e devem ser realizadas conjuntamente. A análise é o processo de observação e levantamento dos elementos do domínio no qual o sistema será introduzido. Deve-se identificar  as pessoas, atividades, informações do domínio para que se possa decidir o que deverá ser informatizado ou não. Pessoas e as atividades que não serão informatizadas deverão ser consideradas entidades externas ao software.

A especificação é a descrição sistemática e abstrata do que o software deve fazer, a partir daquilo que foi analisado. Ela apresenta a solução de como os problemas levantados na análise serão resolvidos pelo software do sistema computacional. Visa descrever de maneira sistemática quais as propriedades funcionais são necessárias para resolver o problema do domínio. A especificação é também a forma de comunicação sistemática entre analistas e projetistas do software.

O objetivo da definição dos requisitos é especificar o que o sistema deverá fazer e determinar os critérios de validação que serão utilizados para  que se possa avaliar se o sistema cumpre o que foi definido.

4.1.1 O que são requisitos?

Como sistemas computacionais são construídos para terem utilidade no mundo real. Modelar uma parte do mundo real, o domínio de aplicação é uma atividade extremamente importante para se compreender a necessidade e a importância do sistema a ser construído e definir os requisitos que tornam o sistema útil.

Requisitos são objetivos ou restrições estabelecidas por clientes e usuários do sistema que definem as diversas propriedades do sistema. Os requisitos  de software são, obviamente, aqueles dentre os requisitos de sistema que dizem respeito a propriedades do software.

Um conjunto de requisitos pode ser definido como uma condição ou capacidade necessária que o software deve possuir (1) para que o usuário possa resolver um problema ou atingir um objetivo ou (2) para atender as necessidades ou restrições da organização ou dos outros componentes do sistema.

Tradicionalmente, os requisitos de software são separados em requisitos funcionais e não-funcionais. Os requisitos funcionais são a descrição das diversas funções que clientes e usuários querem ou precisam que o software ofereça. Eles definem a funcionalidade desejada do software. O termo função é usado no sentido genérico de operação que pode ser realizada pelo sistema, seja através comandos dos usuários ou seja pela ocorrência de eventos internos ou externos ao sistema.

São exemplos de requisitos funcionais:

A especificação de um requisito funcional deve determinar o que se espera que o software faça, sem a preocupação de como ele faz. É importante diferenciar a atividade de especificar requisitos da atividade de especificação que ocorre durante o design do software. No design do software deve-se tomar a decisão de quais a funções o sistema efetivamente terá para satisfazer àquilo que os usuários querem.

Requisitos não-funcionais são as qualidades globais de um software, como manutenibilidade, usabilidade, desempenho, custos e várias outras. Normalmente estes requisitos são descritos de maneira informal, de maneira controversa (por exemplo, o gerente quer segurança mas os usuários querem facilidade de uso) e são difíceis de validar.

São exemplos de requisitos não-funcionais:

A necessidade de se estabelecer os requisitos de forma precisa é crítica na medida que o tamanho e a complexidade do software aumentam. Os requisitos exercem influência uns sobre os outros. Por exemplo, o requisito de que o software deve ter grande portabilidade (por exemplo, ser implementado em Java) pode implicar em que o requisito desempenho não seja satisfeito (programas em Java são, em geral, mais lentos).

4.1.2 A Engenharia de Requisitos

Os diversos relacionamento e restrições que os requisitos exercem uns sobre os outros são muito difíceis de ser controlados. Principalmente se considerarmos que algumas decisões de design que afetam um ou mais requisitos só serão tomadas mais adiante do desenvolvimento. Por exemplo, a decisão de implementar em Java pode ser decidida apenas após o design da arquitetura. Desta forma, os requisitos precisam ser gerenciados durante todo o desenvolvimento. 

A importância e complexidade desta atividade levou ao surgimento, no início dos anos 90, da Engenharia de Requisitos. O objetivo desta denominação é 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 fundamentação e processos próprios, 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 três grupos principais [Zave]:

A Engenharia de Requisitos deve envolver a documentação das funções, do desempenho, interfaces externas e internas e atributos de qualidade do Software.

Esta área é inerentemente abrangente, interdisciplinar e aberta. Ela lida com a descrição de observações do mundo real através de notações apropriadas.

Os benefícios da Engenharia de Requisitos são:

Uma boa especificação de requisitos deve ser: (Veja mais em Dorfman, Merlin - Requirements Engineering)

4.1.3 Técnicas de levantamento de requisitos

Um dos objetivos da Engenharia de Requisitos é ultrapassar barreiras de comunicação entre os clientes e usuários e os analistas para que os requisitos possam capturados e modelados corretamente

Dentre as técnicas mais importantes para a comunicação podemos citar três:

Estas três técnicas são complementares e podem todas ser usadas numa mesma análise de requisitos. A entrevista é normalmente a primeira técnica utilizada. Analistas entrevistam clientes para definir os objetivos gerais e restrições que o software deverá ter. A entrevista deve ser feita de forma objetiva visando obter o máximo de informações do cliente. Diversas seções de entrevistas podem ser marcadas.

Na observação in loco os analista devem estar inseridos na rotina de trabalho da organização tentando entender e descrever as principais atividades que são realizadas. Na observação devem ser identificadas quais as atividades podem ser automatizadas, quem são os potenciais usuários, quais tarefas eles querem realizar com a ajuda do novo sistema, etc. A observação deve ser complementada com entrevistas específicas com os futuros usuários.

Os encontros são reuniões envolvendo analistas, clientes e usuários destinadas exclusivamente ao levantamento de informações, descrição dos problemas atuais e de metas futuras. Os encontros devem ser realizados em um local neutro (fora da organização) e normalmente duram poucos alguns dias. Nos encontros as informações que vão sendo levantadas vão sendo afixadas em paineis na sala de encontro para que possam ser analisadas e validadas pelos clientes e usuários. Ao final do encontro os analistas devem elaborar um relatório descrevendo os requisitos analisados.

4.1.4 Modelos de documentos de especificação de requisitos

O resultado final da análise e especificação de requisitos e das outras atividades da fase de definção devem ser apresentados aos clientes para que eles possam validá-lo. Este documento oferece a concordância entre clientes, analistas e desenvolvedores sobre o que deve ser desenvolvido. É utilizando este documento que as atividades da fase de desenvolvimento (design e programação) serão validadas.

Cada desenvolvedor utiliza um modelo específico para elaborar este documento. A sua estrutura muitas vezes depende do método que está sendo utilizado. Em linhas gerais este modelo deve ser basicamente textual, utilizando o mínimo de termos técnicos, e ilustrados como modelos gráficos que demonstrem mais claramente a visão 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 não apenas a especificação dos requisitos, mas os resultados do estudo de viabilidade e o processo de desenvolvimento.

Pressman apresenta o seguinte documento de especificação de requisitos de software:
I. Introdução

II. Descrição da Informação III Descrição Funcional IV. Descrição Comportamental V. Critérios de Validação VI. Bibliografia
VII Apêndice

Uma proposta alternativa é a de Farley. De acordo com ele, um documento de especificação de requisitos deve possui as seguintes seções:

4.2 Especificando Requisitos utilizando Casos de Uso

Após saber quais as tarefas associadas a cada papel de usuário, é hora de elaborar os casos de uso (use cases) que permitem definir as funções de aplicação que o sistema deverá oferecer para o usuário. Os casos de uso podem ser utilizadas durante a análise e especificação 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 notações para a representação 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 funções da aplicação que caracterizam a funcionalidade do sistema. Um caso de uso representa o que o sistema faz e não como o sistema faz, proporcionando uma visão externa e não interna do sistema.

Cada caso de uso define um requisito funcional do sistema. Por exemplo, num sistema bancário, consulta de saldo, empréstimos e saques de dinheiro são exemplos de casos de uso.

O caso de uso descreve um conjunto de seqüências de ações que o sistema desempenha para produzir um resultado esperado pelo usuário. Cada seqüência representa a interação de entidades externas e o sistema. Estas entidades são chamadas de atores e que podem ser usuários ou outros sistemas. No caso de usuários, um ator representa na verdade uma função de usuários.

Os casos de uso podem ser compostos por outros casos de uso mais específicos. Esta estrutura deve estar em conformidade com o particionamento do sistema em sub-sistemas. Desta forma tanto é possível descrever casos de uso que aplicam-se ao sistema global, quanto casos que são específicos para cada uma das partes do sistema.

Casos de uso também 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-poupança.

Ao definir os requisitos funcionais, o caso de uso define o comportamento, as respostas esperadas e os casos de testes que devem validar a implementação do sistema.

4.2.1 A representação de casos de uso usando UML

A notação UML será utilizada neste curso como linguagem de especificação para a maioria das atividades do ciclo de vida do sistema. A partir de agora vamos introduzir esta notação necessária para representar casos de uso. Ao longo do curso outros aspectos da linguagem serão 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 função de usuário é representado por uma figura simples de um indivíduo (um boneco-de-palitos).

Os atores são conectados a casos de uso por uma associação representadas por uma linha.

O comportamento associado a cada caso de uso pode ser descrito como um cenário. Cada cenário descreve textualmente o fluxo de eventos ou seqüência que caracteriza o comportamento do ator e as respostas do sistema. Um cenário é uma instância do caso de uso.

Por exemplo num caixa eletrônico bancário, o caso de uso validar cliente pode ser descrito pelo seguinte cenário:

Fluxo de eventos principal: O casos de uso inicia quando o sistema solicita ao cliente (do banco) a sua senha. O cliente fornece os números através do teclado. O cliente confirma a senha pressionando a tecla entre. O sistema checa este número e verifica se ele é válido.

Fluxo de evento excepcional: O cliente pode cancelar a transação a qualquer momento pressionando o botão cancele, reiniciando o caso de uso. Não é feita nenhuma mudança na conta do usuário.

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 número de senha inválido o caso de uso é reiniciado. Se isto acontecer três vezes seguidas, o sistema cancela o caso de uso e bloqueia por até uma hora.

Os casos de uso também podem ser descritos de maneira mais estruturada e formal, por exemplo, usando pré- e pós-condições. Diversas técnicas e notações para especificações formais permitem descrever o comportamento da funções da aplicação em termos de pré- e pós-condições. As pré-condições estabelecem as condições que devem estar satisfeita antes que a função seja executada pelo sistema, enquanto que as pós-condições determinam o que deve ser válido ao final da execução. 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 programação a serem utilizados. As especificações formais não são abordadas neste curso.

Os casos de uso podem ainda ser descritos através de outros diagramas UML. Os diagramas de atividades descrevem os diversos estados e as transições entre cada um deles. Os diagramas de interação permitem descrever as interações entre o ator e o componente do sistema que implementa o caso de uso. Estes diagramas serão estudados mais adiante no capítulo 5.
Veja o exemplo acima especificado através de diagramas de estados e de atividades na seção 5.2.7.

4.2.3 Diagrama de Casos de Uso em UML

A UML permite elaborar diversos diagramas para visualização, especificação, construção e documentação de diversas partes do sistema em diversas etapas do ciclo de vida. Existem cinco tipos de diagramas que permitem modelar aspectos dinâmicos do sistema através da UML. O diagrama de  casos de uso é um destes diagramas e pode ser utilizado para visualização, especificação e documentação de requisitos do sistema.

A especificação dos requisitos visa descrever o que o sistema deve fazer para satisfazer as metas dos usuários (requisitos funcionais) e quais outras propriedades é desejável que o sistema possua (requisitos não-funcionais). Vimos que casos de usos, individualmente, descrevem requisitos funcionais. Acrescentandos Notas aos diagramas de casos de uso podemos especificar também os requisitos não-funcionais.

Um diagrama de casos de uso contém:

Podem ser acrescentadas Notas com em qualquer outro diagrama UML.

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

 Além destas regras básicas, algumas dicas ajudam a construir diagramas mais claros.

4.3 Técnicas complementares para análise de requisitos

Definir casos a partir do nada pode ser bastante difícil. Antes de começar a pensar em casos de uso o analista pode descrever cenários com situações do domínio. Estes cenários contêm informações que podem ser extraídas mais detalhadamente com o objetivo de detalhar os cenários. Além dos cenários, a análise do perfil dos usuário e das tarefas que eles executam permitem um maior conhecimento do domínio, possibilitando uma melhor especificação dos requisitos. 

4.3.1 Cenários 

Do ponto de vista de usabilidade, o desenvolvimento de um novo sistema implica na transformação das tarefas e práticas atuais dos usuários e da organização. Conhecer a situação 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 organização é alterado. Nessa reengenharia, novas tarefas e práticas são incorporadas enquanto que outras são eliminadas.

O levantamento de informações sobre as tarefas e os usuários pode ser melhor realizado quando os analistas procuram descrever situações do processo de trabalho. Os métodos baseados em cenários consistem de uma coleção de narrativas de situações no domínio que favorecem o levantamento de informações, a identificação de problemas e a antecipação das soluções. Cenários são uma maneira excelente de representar, para clientes e usuários, os problemas atuais e as possibilidades que podem surgir.

Os cenários têm como foco as atividades que as pessoas realizam nas organizações possibilitando uma perspectiva mais ampla dos problemas atuais onde o sistema será inserido, explicando porque ele é necessário. Eles proporcionam um desenvolvimento orientado a tarefas possibilitando maior usabilidade do sistema.

Não é objetivo dos cenários oferecer uma descrição precisa, mas provocar a discussão e estimular novos questionamentos. eles permitem também documentar o levantamento de informações a respeito dos problemas atuais, possíveis eventos, oportunidades de ações e riscos.

Por sua simplicidade, cenários são um meio de representação de fácil compreensão para os clientes e usuários envolvidos (muitas vezes de formação bastante heterogênea) que podem avaliar, criticar e fazer sugestões, proporcionando a reorganização de componentes e tarefas do domínio. Cenários oferecem um "meio-intermediário" entre a realidade e os modelos que serão especificados possibilitando que clientes, usuários e desenvolvedores participem do levantamento das informações e especificação dos requisitos. Em resumo, os cenários permitem compreensão dos problemas atuais pelos analistas e antecipação da situação futura pelo clientes e desenvolvedores.

Elaborando Cenários

Como toda atividade de análise e especificação de requisitos, a descrição do domínio através de cenários requer técnicas de comunicação e modelagem.

A descrição de cenários deve ser apoiada pelas três técnicas de comunicação vistas anteriormente. Antes de descrever os cenários, os analistas devem entrevistar clientes para entender os problemas e requisitos iniciais. A entrevista com usuários permite que cada um descreva as suas tarefas e os problemas associados a cada uma delas. A observação direta in loco é fundamental para que os analistas possam descrever a situação de uso como ela realmente vem ocorrendo na prática.

Após a elaboração dos cenários, clientes, usuários e analistas podem participar de encontros para que possam discutir cada um destes cenários. Eles podem ser afixados em quadros na parede onde os participantes possa analisá-los e fazer comentários, possivelmente afixando pequenos pedaços de papel a cada uma das cenas.

Cenários podem ser descritos em narrativas textuais ou através de storyboards. As narrativas textuais podem ser descritas livremente, identificando os agentes e as ações que eles participam. É possível utilizar notações para descrever roteiros de cinemas ou notações mais precisas como aquelas utilizadas pela Inteligência Artificial para representação de conhecimento.

Uma técnica que está bastante relacionada com cenários, por permitir descrever situações de uso, é o storyboarding. Essa técnica envolve a descrição através de quadros com imagens que ilustram as situações do domínio. Cada quadro deve apresentar a cena que descreve a situação, os atores e as ações que cada um deve desempenhar. Abaixo de cada quadro devem estar descritas ações que os atores desempenham. Os storyboards são bastante utilizados em cinemas como forma de comunicação entre roteiristas, diretores, atores e técnicos.

Existem ferramentas computacionais que podem ser utilizadas para a descrição de cenários como o Scenario's Browser [Rosson 99].

Exemplos de cenários

Como exemplo vamos considerar o domínio de uma locadora de fitas de vídeo.

Cena 1: Cliente procura uma fita com uma certa atriz
Agentes: Cliente, Atendente, Balconista
Ações:

Cena 2: O cliente procura por filmes de um certo gênero
Agentes: Cliente, Atendente, Balconista
Ações: Cena 3: Cliente procura por filme usando o sistema de consulta
Agentes: Cliente e Sistema de Consulta
Ações:

4.3.2 Questionamento Sistemático

A descrição de informações do domínio através de narrativas só é efetivamente realizada se o processo de compreensão por parte dos analistas e projetista for realizado de maneira sistemática [J. Carroll et al. 94]. O questionamento sistemático é uma técnica que permite ao analista obter, a partir dos cenários, uma rede de proposições na qual identifica-se agentes (atores), ações (processos de casos de uso), e objetos (informações). 

 O questionamento sistemático uma técnica psico-linguística que permite a psicólogos e lingüistas examinar o conteúdo e a estrutura de informações contidas numa narrativa. Uma narrativa é um sumário de um conjunto de eventos e ações envolvendo agentes e objetos do mundo. Nem todas as informações integrantes do contexto são passadas através da narrativa. Muitas dessas informações são inferidas do conhecimento cultural de cada indivíduo. Outras, entretanto, precisam ser obtidas diretamente na fonte, isto é, junto ao autor da narrativa. Essa técnica foi desenvolvida para se entender melhor o processo de compreensão de estórias em narrativas. O objetivo é compreender tudo o que envolve o contexto daquilo que está sendo passado na narrativa.

Aplicando essa técnica no processo de análise de domínios, os especialistas devem descrever em narrativas seu conhecimento do domínio. Entretanto, esse conhecimento é muito mais abrangente. O questionamento sistemático permite obter todo o conhecimento que está além do que foi comunicado na narrativa. Assim, analistas e projetista podem utilizar essa técnica para adquirir mais eficazmente conhecimento sobre o domínio e inferir objetos e interações que não estão descritos na narrativa. Isto ocorre usando-se cada sentença ou afirmação da narrativa como ponto de entrada na complexidade do problema.

Nessa técnica, cada questão é uma ponte entre uma idéia e outra. Uma resposta a uma questão sobre um componente da narrativa revela outras conexões que são críticas para o seu entendimento. Realizando, sistematica e exaustivamente muitos tipos de questões sobre componentes da narrativa e iterativamente fazendo perguntas sobre as respostas geradas, o analista elabora um mapa conceitual (rede de proposições) que representa as estruturas do conhecimento do domínio.

Os passos do método consistem de:

Nos passos iniciais obtem-se informações sobre agentes, interações e objetos abstratos do domínio. Usando a técnica, pode-se chegar a um conhecimento mais profundo do domínio que permite aos analistas e projetista a elaboração de modelos funcionais do sistema.

Exemplo
Considere o seguinte cenário sobre um caixa eletrônico.
Questão de elicitação do cenário:

Cenário: As duas sentenças do cenário acima contém quatro proposições: A partir dessas proposições, o analista determina que o cartão e o cliente são agentes de ações. Numa análise voltada para a elicitação de requisitos da interação, seria determinado como usuário do sistema, o cliente. A ações são portanto: digita, pressiona e pega. São objetos da interação a senha, o botão e o dinheiro. Outros objetos são o caixa eletrônico e o cartão. É preciso determinar que tipo de objetos são esses. Uma outra dúvida é a respeito do cartão ser objeto ou agente.

Obviamente, como esse exemplo é bastante simples e a aplicação também é muito conhecida, parece desnecessário obter mais conhecimentos a respeito. Entretanto, como o objetivo aqui é exemplificar a técnica, mostraremos como pode-se questionar a respeito dessa aplicação.

O analista deve então realizar uma série de questões sobre as proposições. Nesse questionamento o analista precisa determinar qual o relacionamento entre a resposta e a proposição que originou a pergunta.

As questões da categoria por que, visam responder "razões" (metas) e "causas" a respeito de eventos da narrativa. As questões da categoria como oferecem maiores detalhes a  respeito de determinados eventos, permitindo determinar sub-tarefas e maiores detalhes sobre a interação. Questões da categoria o que podem ser feitas sobre objetos, e revelam atributos e hieraquias de objetos. Perguntas de verificação podem ser feitas para se saber se as proposições estão sendo entendidas corretamente. As perguntas de verificação são as que têm resposta sim/não. Uma taxonomia mais completa ainda está sendo pesquisada pelos autores do método.

Continuando o exemplo anterior a tabela abaixo descreve uma seção de questionamento sistemático:



Questões "por que"

Questões "como"
Questões "o que" Observe que se o analista estivesse utilizando essa técnica para num método orientado a objetos, outras questões poderiam ser realizadas com outros objetivos de acordo com as necessidades do método, como, por exemplo, para determinar classes e hierarquia de classes.

Após os cenários estarem desenvolvidos, os analistas devem trabalhar em conjunto com os usuários para avaliá-los e refiná-los. Isto pode ser feito, por exemplo, colocando-se posters numa sala pela qual os usuários podem circular livremente e observar os diversos cenários. Cada cenário deve apresentar quadros (desenhos, gráficos, fotografias, etc.), usando storyboards por exemplo, e uma descrição narrativa da tarefa. Os usuários, munidos de papeis e lápis, podem fazer anotações (críticas e sugestões) e anexá-las a cada poster.

Considerações finais sobre cenários

O resultado da modelagem através de cenários é uma base para a compreensão de quem são os usuários, quais a tarefas envolvidas e quais funções a interface e a aplicação devem prover, de maneira que, já se possa ter meios de garantir a usabilidade do sistema.

A idéia de cenários em análise não está necessariamente associada à técnica de questionamento sistemático. Os cenários são extremamente úteis para descrição do domínio. A técnica sistematiza o processo de compreensão do conhecimento adquirido.

Os métodos em geral, e esse não deve fugir à regra, devem ser usados, não como uma camisa-de-força que limite o processo de análise, mas como ferramentas que orientam os analistas e aumentam sua capacidade intelectual.

4.4 Análise de Usuários

Para que o sistema seja construído como uma ferramenta de apoio às atividades de usuários no domínio de aplicação, é preciso conhecer quem são os usuários e quais as suas necessidades, isto é quais tarefas eles necessitam realizar. A análise de usuários deve determinar quem eles são e quais tarefas eles normalmente fazem no domínio. Ela envolve a descrição dos diferentes papéis de usuários e qual o conhecimento, capacidade e cultura possuem os futuros usuários do sistema.

4.4.1 Análise de Perfis de Usuários

A análise do perfil dos diversos usuários do sistema descreve as várias características que podem influenciar as decisões dos projetistas no desenvolvimento do sistema. Os objetivos são assegurar que certas propriedades do sistema estejam adequadas ao conhecimento, cultura e capacidades do usuário, e que potenciais deficiências sejam levadas em consideração. Por exemplo, para um software de acompanhamento de pacientes em hospital, certos termos específicos da medicina devem ser incluídos nas telas do sistema e devem ser evitados termos técnicos de informática ( forneça informações patológicas ao invés de  entrar dados da doença). Para usuários com alguma deficiência física ou motora, elemento da interface devem ser modificados, como por exemplo, tela de maior tamanho e letras maiores para deficientes visuais.

Os perfil do usuário pode ser analisado através de formulários do tipo:


Perfil do Usuário

Nome do Sistema: ____________________________________________________________________
Função do Usuário: ___________________________________________________________________

Conhecimento e Experiência do Usuário
Nível educacional 
(  ) Ensino fundamental 
(  ) Ensino médio 
(  ) Graduação 
(  ) Pós-Graduação
Língua Nativa 
(  ) Português 
(  ) Inglês 
(  ) outra: ___________________
Nível de leitura e expressão 
(  ) Excelente 
(  ) Bom 
(  ) Regular 
(  ) Ruim
Experiência com computadores 
(  ) Iniciante 
(  ) Intermediário 
(  ) Experiente
Experiência com sistema similar 
(  ) Utiliza bastante um similar 
(  ) Já utilizou um similar 
(  ) Nunca utilizou um similar
 Conhecimento sobre o domínio 
(  ) Elementar 
(  ) Intermediário 
(  ) Especialista no domínio
Características Físicas
Manipulação 
(  ) Canhoto 
(  ) Destro 
(  ) Ambidestro 
Deficiências 
(  ) Auditiva 
(  ) Visual 
(  ) Corporal 
(  ) Vocal


O perfil deve dar as informações necessárias que os desenvolvedores precisam para tomar as suas decisões. A análise do perfil pode ser adaptada de acordo com as características do sistema e com as necessidades de analistas e desenvolvedores. Por exemplo, pode ser interesse dos designers saber se os usuários têm algumas experiência com interfaces gráficas e qual o padrão (Windows, Motif, Macintosh, etc.) eles estão acostumados a utilizar.

4.4.2 Papéis de Usuários

O papel (ou função ) específico de cada usuário é definido pelas tarefas que eles realizam. Numa organização, as pessoas trabalham juntas, de maneira estruturada. A estrutura da organização define relacionamentos entre as pessoas. A implicação imediata dos diferentes papéis de cada usuário são as diferentes tarefas que eles irão realizar. Algumas tarefas podem ser comuns a diferentes papéis de usuários, enquanto outras podem ser exclusivas de papéis específicos.

O conceito de papel de usuário permite abstrairmos as características específicas de um usuário e enfatizar nas diferentes necessidades associadas a função que ele exerce. Para cada papel devemos associar um conjunto de funções, como veremos mais adiante.

No domínio do departamento de informática da UFRN podemos identificar como papéis de usuários: secretário do departamento,  chefe, coordenador de graduação, secretário da coordenação, coordenador de pós-graduação, professor,  aluno, funcionário de administração de laboratórios e  usuário externo.

4.5 Análise e Modelagem de Tarefas

Os cenários permitem o levantamento e a descrição mais global das informações, das tarefas e dos problemas do domínio. O perfil de usuário descreve as características de usuários em termo de conhecimento, cultura, capacidades e limitações. A análise de tarefas visa determinar quais as atividades que os usuários (ou cada papel de usuário) devem realizar. Esta informação é essencial para se especificar os requisitos funcionais, determinando a funcionalidade do software. Para que o sistema possa ser construído para que estes problemas sejam resolvidos, ele deve ser uma ferramenta auxiliar na realização das tarefas de cada usuário.

Uma tarefa é, genericamente, uma atividade na qual um ou  mais agentes tentam atingir uma meta especificada, através de uma mudança de estado em uma ou mais entidades do mundo. Num domínio de aplicação, as tarefas são as atividades que modificam estados de elementos deste domínio. A construção de um sistema computacional em um certo domínio tem por objetivo apoiar a realização de algumas destas atividades. Durante o processo de análise, deve-se determinar quais as do domínio e identificar quais delas podem ser auxiliadas pelo sistema.

A análise e modelagem de tarefas visa descrever as principais as tarefas que cada usuário do sistema terá de realizar para que os projetistas possam elaborar quais funções o sistema deve oferecer para que elas possam ser desempenhadas. Estas tarefas são descritas em termos de metas e um planejamento de possíveis atividades necessárias para atingi-las. As tarefas podem ser descritas a partir das informações obtidas nos cenários e devem ser agrupadas por papéis de usuário.

A análise de tarefas pode ser utilizadas nas diversas fases do ciclo de vida do software. Na fase de análise de requisitos ela pode ser utilizada para identificar problemas na maneira de como as tarefas vêm sendo realizadas. Os modelos de tarefas também podem descrever quais tarefas podem ser realizadas com o auxílio do sistema e como os usuários gostariam que ela fosse realizada. A análise de tarefa também é utilizada na avaliação do sistema para se determinar se como os usuários estão utilizando o sistema e se os objetivos foram atingidos.  Nestes casos, a análise de tarefas ajuda ao projetista da interface ter uma visão da aplicação sob a perspectiva do usuário, isto é, um modelo das tarefas do usuário quando executando sessões da aplicação.

4.5.1 Modelo de tarefas como base para a especificação de requisitos funcionais

A análise e modelagem de tarefas pode ser utilizada como base para a especificação de requisitos funcionais. Para isto é preciso descrever as metas associadas a cada papel de usuário, que permitirão saber o que os usuário 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 decomposição hierárquica de metas em sub-metas até que elas possam ser atingidas por operações. O plano ou método é, portanto, uma  estrutura de sub-metas e operações para se atingir um certa meta. As operações correspondem a ações básicas humanas, isto é, aquelas que qualquer pessoa pode e sabe como realizar. São exemplos de operações  escrever uma palavra ou frase, ler uma informação, falar uma palavra ou frase, andar, relembrar, mover um objeto, pressionar um botão de controle e várias outras.

Por exemplo, suponhamos que uma pessoa tem como meta avisar a um amigo, através 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 método:  Conseguir papel e lápis e Escrever mensagem. Escrever mensagem já pode ser considerada uma operação, enquanto que conseguir papel e lápis requer um novo planejamento que determine as seguintes operações: ir até o escritório, abrir o armário, pegar o papel e o lápis, levá-los até a mesa.
O grão de refinamento do que podemos considerar com sendo uma operação é bastante subjetivo. Vai depender das dificuldades de quem realiza o plano. Na prática o plano é necessário quando a pessoa que vai realizar as ações não sabe ainda qual o método. Com a experiência o método torna-se automático e podemos considerar uma sub-meta como uma operação

Na utilização de um sistema computacional, os usuários realizam tarefas com o objetivo de atingir certas metas. Uma meta é um determinado estado do sistema ou de objetos do sistema ao qual o usuário quer chegar. Ao estabelecer a meta o usuário deve realizar um planejamento decompondo a meta em sub-metas até que ele saiba que existe uma determinada função do sistema que permita que sua meta seja atingida. O caso agora é um pouco diferente do planejamento anterior, pois não é o usuário quem vai realizar a operação desejada, mas o sistema. A decomposição deve ocorrer até que ele identifique que o sistema tem uma determinada função que quando executada realiza a operação necessária para que sua meta seja atingida. Chamamos estas operações que o sistema executa para satisfazer as metas do usuário de função da aplicação. O conjunto de funções da aplicação determina a funcionalidade do sistema.

Vejamos um exemplo. Suponha que o usuário 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 página, Formatar parágrafos, Formatar fontes. Para cada uma destas sub-metas ele estabelece novas sub-metas até que ele identifique no software funções que o sistema pode realizar que permitam que as sub-metas sejam atingidas. Por exemplo, formatar página pode ser decomposta na função da aplicação especificar tamanho da página e na sub-meta definir margens. Esta última por sua vez pode ser atingida pelas operações 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 usuário

O modelo de tarefas é extremamente útil para determinarmos as metas dos usuários e quais funções da aplicação eles gostariam que o sistema oferecesse. Por exemplo, a especificação dos requisitos pode determinar que deve existir uma função da aplicação para formatar documento de maneira que a meta do usuário pudesse ser atingida pelo sistema sem a necessidade de planejamento algum.

É importante ressaltar que uma meta pode ser satisfeita por uma única ou por várias funções da aplicação e que também mais de um método pode ser atingido uma mesma função da aplicação.Por exemplo, ao utilizar o Word 7.0, o usuário pode ter como meta formatar um estilo. Ao construir o seu plano o usuário em determinado momento pode estabelecer a sub-meta Especificar atributos do parágrafo. Esta sub-meta requer as mesmas funções de aplicação do plano para a meta formatar parágrafo. Assim, temos um grupo de funções da aplicação que são utilizadas para duas (ou mais) metas  distintas.

Para que o usuário solicite ao sistema que execute uma determinada função de usuário, ele deve realizar operações que correspondam a um comando de função. Por exemplo, para o usuário solicitar ao sistema operacional que realize a função de copiar um arquivo de um diretório para outro ele deve escrever um comando do tipo copy nome1 dir1 dir2 ou se estiver numa interface gráfica, mover o ícone correspondente ao arquivo da janela do diretório para a do outro diretório. Ao realizar o comando, o usuário precisa realizar operações com os dispositivos de interface do sistema, como pressionar mouse, digitar número, teclar enter, etc.

Apenas com a descrição das operações do usuário é que um plano para atingir uma meta fica completo. Quando o sistema está pronto, o plano tem que determinar exatamente as operações necessárias para comandar a função e, conseqüentemente, ter a meta atingida com o auxílio do sistema.

Na especificação de requisitos é suficiente decompor as metas que o usuário quer atingir nas correspondentes sub-metas. Caberá ao designer do software determinar qual o conjunto de funções que permita atingir o maior número possível de metas para cada papel de usuário e quais devem ser os comandos de interface para cada uma das funções.

4.5.2 Modelagem de Tarefas usando GOMS

Neste curso, utilizaremos a análise de tarefas na especificação de requisitos para determinar as tarefas que os usuários necessitam realizar com o sistema a ser construído. Para isto utilizaremos um método específico que utiliza o modelo GOMS simplificado. O modelo GOMS (Goals, Operators, Methods, and Selection Rules) oferece uma abodagem de análise da tarefa baseada num modelo do comportamento humano que possui três subsistemas de interação: o perceptual (auditivo e visual), o motor (movimentos braço-mão-dedo e cabeça-olho), e cognitivo (tomadas de decisão e acesso a memória). O modelos GOMS descreve o comportamento dinâmico da interação com um computador, especificando-se: Metas - Uma aplicação é desenvolvida para auxiliar os usuários atingirem metas específicas. Isso requer uma série de etapas. Dessa forma, uma meta pode ser decomposta em várias submetas, formando uma hierarquia.

Operadores - São as ações humanas básicas que os usuários executam.

perceptual - operações visuais e auditivas (olhar a tela, escutar um beep).

motor - movimentos braço-mão-dedo e cabeça-olho (pressionar uma tecla).

cognitivo - tomadas de decisão, armazenar e relembrar um item da memória de trabalho.
 

Métodos - Um método é uma sequência de passos para se atingir uma meta. Dependendo do nível da hierarquia, os passos num método podem ser submetas, operadores ou a combinação de ambos.

Regras de Seleção - Pode existir mais de um método para se atingir uma meta. Uma regra de seleção especifica certas condições que devem ser satisfeitas antes que um método possa ser aplicado. Uma regra de seleção é uma expressão do tipo "condição-ação".

O GOMS permite que se construa modelos de tarefas bem mais complexos e detalhados do que o necessário numa tarefa de análise para a especificação de requisitos. Usaremos uma versão simplificada do GOMS, pois:
  1. Diretrizes do Modelo de Tarefas Simplificado
Uma vez que a hierarquia de metas representa um aumento no nível de detalhe, se nos limitarmos à descrição de metas e submetas de mais alto nível, nenhuma decisão de design será envolvida.  
  1. Modelagem da Tarefa para aplicações com múltiplas funções de usuários.
  2. Se, para uma determinada aplicação, a função do usuário for um fator crítico dominante na análise de usuários, deveremos ter modelos de tarefas diferentes para cada função de usuário. No GOMS simplificado, veremos como representar as tarefas para cada usuário num só modelo. Antes de estudarmos a notação do modelo, vejamos algumas regras para modelos com múltiplas funções de usuários:
     

     
  3. Notação
    1. Notação para Funções de Usuários.
ex.: Gerente de vendas (FU1), balconista (FU2), caixa (FU3) ex.: Gerente de vendas (FU1): responsável pela vendas nas lojas. Tem acesso a todos os dados do sistema. ex.: FU1;... ex.: FU1, FU2; ... ex.: *;...
    1. Notação para especificação de metas
ex.: FU2; 2.1: Anotar correções. ex.: // Para fazer as anotações o balconista deverá examinar as
       // listagens produzida durante as vendas do dia.

FU2; 2.1: Anotar correções
 

  • Notação para Métodos e Regras de Seleção
  • ex.:

    FU2; 2: Fazer relatório de vendas (meta)

    FU2; 2A: ... (método A)

    FU2; 2B: ... (método B)

     

    ex.: FU2; 2A: se (dia de hoje for sábado) então (fazer relatório semanal)
      1. Reutilizando Metas
      2. Um aspecto importante dessa notação é que pode-se reutilizar metas, simplesmente usando o mesmo número de uma meta preexistente.

        ex.:

        FU2; 2.1: Anotar correções. (meta preexistente)

        ...

        FU1, FU3; 3: Modificar livro-caixa.

        FU1, FU3; 3.1: Procurar lotes em aberto.

        FU1, FU3; 2.1: Anotar correções. (meta reusada)

        FU1, FU3; 3.3: Recalcular valores.
         

      3. Diretrizes adicionais
    ex.: FU1, FU3; 3: Modificar livro-caixa. 1: Procurar lotes em aberto.   2.1: Anotar correções. (meta reusada)   3: Recalcular valores.  
    Anterior | Índice | Próximo
    (C) Jair C Leite, 2000                                                          Última atualização: 25/04/01