Análise e Especificação de Requisitos – Engenharia de Requisitos

Análise e Especificação de Requisitos

Os objetivos deste capítulo (Análise e Especificação de Requisitos) são:

  • Definir o que são requisitos de software
  • Introduzir os objetivos da Engenharia de Requisitos
  • Apresentar técnicas de comunicação para obter informações dos clientes e usuários
  • Apresentar técnicas para descrever o domínio, usuários e tarefas.
  • Especificar requisitos funcionais utilizando Casos de Uso
  • Especificar requisitos não funcionais

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 softwareenvolve 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 funcionaissão a descrição das diversas funções que clientes e usuários querem ou precisam que o software ofereça. Eles definem a funcionalidade desejada do software. O termo função é usado no sentido genérico de operação que pode ser realizada pelo sistema, seja através comandos dos usuários ou seja pela ocorrência de eventos internos ou externos ao sistema.

São exemplos de requisitos funcionais:

  • “o software deve possibilitar o cálculo dos gastos diários, semanais, mensais e anuais com pessoal”.
  • “o software deve emitir relatórios de compras a cada quinze dias”
  • “os usuários devem poder obter o número de aprovações, reprovações e trancamentos em todas as disciplinas por um determinado período de tempo.

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

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

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

  • “a base de dados deve ser protegida para acesso apenas de usuários autorizados”.
  • “o tempo de resposta do sistema não deve ultrapassar 30 segundo”.
  • “o software deve ser operacionalizado no sistema Linux”
  • “o tempo de desenvolvimento não deve ultrapassar seis meses”.

A necessidade de se estabelecer os requisitos de forma precisa é crítica na medida 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 desempenhonã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]:

  • Investigação de objetivos, funções e restrições de uma aplicação de software
    • Ultrapassar as barreiras de comunicação
    • Gerar estratégias para converter objetivos vagos em propriedades ou restrições específicas
    • Compreender prioridades e graus de satisfação
    • Associar requisitos com os vários agentes do domínio
    • Estimar custos, riscos e cronogramas
    • Assegurar completude
  • Especificação do software
    • Integrar representações e visões múltiplas
    • Avaliar estratégias de soluções alternativas que satisfaçam os requisitos
    • Obter uma especificação completa, consistente e não ambígua
    • Validar a especificação – verificar que ela satisfaz aos requisitos
    • Obter especificações que sejam apropriadas para as atividades de design e implementação
  • Gerenciamento da evolução e das famílias do software
    • Reutilização de requisitos durante o processo de evolução
    • Reutilização de requisitos no desenvolvimento de software similares
    • Reconstrução de requisitos

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:

  • Concordância entre desenvolvedores, clientes e usuário sobre o trabalho a ser feito e quais os critérios de aceitação 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 mínimo de desperdício

Uma boa especificação de requisitos deve ser:

  • Clara e não-ambígua
  • Completa
  • Correta
  • Compreensível
  • Consistente
  • Concisa
  • Confiável

(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:

  • Entrevistas
  • Observação in loco
  • Encontros

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 locoos 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 encontrossã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

    1. Referências do Sistema 2. Descrição Geral 3. Restrições de projeto do software

II. Descrição da Informação

      1. Representação do fluxo de informação

        a. Fluxo de Dados b. Fluxo de Controle

2. Representação do conteúdo de informação 3. Descrição da interface com o sistema

III Descrição Funcional

      1. Divisão funcional em partições 2. Descrição funcional

        a. Narativas b. Restrições/limitações c. Exigências de desempenho

 

        d. Restrições de projeto e. Diagramas de apoio

3. Descrição do controle

      a. Especificação do controle b. Restrições de projeto

IV. Descrição Comportamental

    1. Estados do Sistema 2. Eventos e ações

V. Critérios de Validação

    1. Limites de desempenho 2. Classes de testes 3. Reação esperada do software 4. Considerações especiais

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:

  • Visão geral do produto e Sumário
  • Ambientes de desenvolvimento, operação e manutenção
  • Interfaces Externas e Fluxo de Dados
  • Requisitos Funcionais
  • Requisitos de Desempenho
  • Tratamento de Exceções
  • Prioridades de Implementação
  • Antecipação de mudanças e extensões
  • Dicas e diretrizes de Design
  • Critérios de aceitação
  • Índice Remissivo
  • Glossário

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 comoo 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 clientepode 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 teclaentre

. 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 Notasaos diagramas de casos de uso podemos especificar também os requisitos não-funcionais.

Um diagrama de casos de uso contém:

  • Casos de Uso
  • Atores
  • Relacionamentos de dependência, generalização e associações

Podem ser acrescentadas Notascom em qualquer outro diagrama UML.

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

  • Estabeleça o contexto do sistema identificando os atores(usuários 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 genérico, estabelecendo um relacionamento de generalização. Tente identificar outros relacionamentos, como a dependência 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 não-funcionais.

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

  • Dê nomes que comuniquem o seu propósito.
  • 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 próximos.
  • Use notas para chamar a atenção de características importantes – as notas não são apenas para os requisitos não funcionais.
  • Não 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 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áriosconsistem 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 encontrospara 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:

      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 específico? Cliente

      : -

Não, mas que não seja policial ou ação.Atendente

      :

Você sabe o nome dela?Cliente

      :

Não

      . 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 começa com G e o sobrenome é algo parecido com Paltrow.Cliente

      :

É isto mesmo.

      A atendente então procura no fichário de atrizes as que começam com G. Não encontra nenhum nome parecido com o que a balconista falou. Ela então lembra-se de consultar uma revista especializada com os ganhadores do Oscar 99 e lá descobre o nome correto da atriz. Entretanto, não existe realmente ficha alguma com os filmes estrelados por esta atriz. O fichário 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 não gosta do gênero destes filmes e pergunta pelo filme vencedor do Oscar.

A atendente responde

      : -

Shakespeare Apaixonado?

    Ainda não saiu em vídeo.

Cena 2: O cliente procura por filmes de um certo gênero Agentes: Cliente, Atendente, Balconista
Ações:

Cliente

      : -

Eu gostaria de comprar um filme de ação

      .

Atendente

      : -

Nós apenas alugamos.Cliente

      : -

Tudo bem. Então, por favor, me dê algumas dicas de filmes de ação.
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 dúvida se já assistiu outros três. Ele também pergunta à atendente se os outros dois filmes são bons. Após conversar durante alguns minutos com a atendente que entende muito do gênero, decide ficar com seis fitas. A atendente encaminha o cliente à balconista para calcular o valor da locação e o prazo de devolução. Após consultar as tabelas de preços e prazos, a balconista apresenta três 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. Após 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 Ações:

      João gostaria de assistir a um filme de guerra. Ele vai a uma locadora de fitas e, chegando lá, utiliza um sistema de consulta. Ele não lembra o título nem o diretor, mas sabe que se passava na guerra do Vietnã e lembra bastante da trilha sonora. Utilizando o sistema ele solicita as opções de filmes de guerra. Os sistema oferece a ele as possibilidades de escolher os filmes por local da guerra ou por época. João escolhe a sua opção (guerra) e obtem uma lista com dezenas de filmes sobre o vietnam. Ele pode organizar esta lista, por diretor, atores e título. Na tela do sistema aparecem a ilustração com o cartaz de divulgação do filme  e uma opção para ele visualizar o trailler. O sistema, entretanto, não possibilita ele ouvir a trilha sonora.

Após analisar algumas opções ele finalmente encontra o filme desejado, mas uma informação na tela do sistema indica que o filme está alugado. João quer saber quando o filme será devolvido, mas esta informação não consta no sistema. Ele entretanto pode reservar e o sistema enviará para ele um e-mail avisando quando o filme estiver disponível. Ele sai da loja pensando “Que tempo perdido. Seria melhor que eu pudesse consultar o sistema de casa”.

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:

      1.

Geração do cenário

      - as narrativas que compõe o cenário devem ser decritas pelo especialista no domínio. O analista pode motivá-lo fazendo perguntas como num processo convencional de entrevista (questões de elicitação do cenário). 2.

Elaboração da rede de proposições

      - as narrativas devem ser simplificadas e expressas através de proposições. 3.

Análise

      - a partir das proposições pode-se determinar as

tarefas

      (ações e objetos) e

usuários

      (agentes das ações). 4.

Questionamento sistemático

    - novas proposições podem ser elaboradas através de questões que são feitas sobre elementos das proposições anteriores, num processo iterativo.

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:

Como posso sacar R$ 100,00 do caixa eletrônico?

Cenário:

Primeiro ponha o seu cartão do banco no caixa eletrônico, digite a sua senha e pressione o botão “saque rápido”. Depois pegue o dinheiro

    .

As duas sentenças do cenário acima contém quatro proposições:

    CLIENTE — põe — CARTÃO CLIENTE — digita — SENHA CLIENTE — pressiona — BOTÃO-DE-SAQUE-RÁPIDO CLIENTE — pega — DINHEIRO

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”

    Por que o cartão entra no caixa eletrônico? _ Para iniciar. (evento conseqüente) _ E então a máquina saberá quem é o cliente. (estado conseqüente) Por que o cliente digita sua senha? _ Para provar que ele é o usuário autorizado. (meta) Por que o cliente pressiona o botão de saque rápido? _ Porque é o botão para saques de R$ 100,00 (critério de descriminação). _ Para evitar a digitação (cenário alternativo). _ Porque ele está com pressa (causa)

Questões “como”

      Como o cliente põe o cartão? _ O cliente  tira o cartão de sua bolsa e

 

    _ insere no local apropriado no caixa eletrônico.. Como o cliente digita a senha? _ Pressionando os botões adequados. Como o cliente pressiona o botão de saque rápido? _ Colocando o seu dedo nele.

Questões “o que”

    O que é um botão de saque rápido? _ É um tipo de botão que se pode pressionar. O que é um botão? _ É um dispositivo de controle no painel do caixa eletrônico.

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 controlee 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

      META: Formatar documento

        PLANO:

Formatar página

          (sub-meta)

especificar tamanho da página

            (função da aplicação )

Definir margens

            (sub-meta)

especificar valor da margem superior

              (função da aplicação)

especificar valor da margem inferior

              (função da aplicação)

especificar valor da margem esquerda

              (função da aplicação)

especificar valor da margem direita

              (função da aplicação)

Formatar parágrafos

          (sub-meta)

selecionar parágrado

            (função da aplicação) Especificar atributos do parágrafo (sub-meta)

especificar espaçamento

              (função da aplicação)

especificar recuos

                (função da aplicação)

Formatar fontes

        (sub-meta)

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:

 

  • o modelo da tarefa não deverá descrever informações de design da interface, uma vez que ela ainda não foi construída;
  • o analista não é 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 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.

 

  • Faça a análise “top-down” - comece das metas mais gerais em direção as mais específicas.
  • Use termos gerais para descrever metas - não use termos específicos da interface.
  • Examine todas as metas antes de descer para um nível mais baixo – isso facilita reuso de metas.
  • Considere todas as alternativas de tarefas - as regras de seleção possibilitam representar alternativas.
  • Use sentenças simples para especificar as metas - estruturas complexas indicam a necessidade de decomposição da meta em submetas.
  • Retire os passos de um método que sejam operadores- os operadores são dependentes da interface.
  • Pare a decomposição quando as descrições estiverem muito detalhadas - quando os métodos são operadores ou envolvem pressuposições de design.

 

  1. Modelagem da Tarefa para aplicações com múltiplas funções de usuários.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:
    • Inicie especificando metas de alto nível para cada função de usuário.
    • Se mais de um compartilham a mesma meta, agrupe-os sob uma só.
    • Se todos compartilham a mesma meta, retire as referências a funções de usuário.

     

  2. Notação
    1. Notação para Funções de Usuários.

 

  • Funções de usuários distintas serão denotadas pelo símbolo FU seguido por um número.

ex.: Gerente de vendas (FU1

), balconista (FU2

), caixa (FU3

)

  • A descrição de cada função de usuário é a primeira parte do modelo de tarefas.

ex.: Gerente de vendas (FU1

): responsável pela vendas nas lojas. Tem acesso a todos os dados do sistema.

  • Um ponto-e-vírgula (;) é usado para separar o símbolo da função do usuário do restante da notação do modelo de tarefas.

ex.: FU1;…

 

  • Se uma meta é usada para mais de uma função de usuário, elas devem ser separadas por uma vírgula (,).

ex.: FU1, FU2; …

 

  • Um asterisco (*) é usado se uma meta é aplicada a todas as funções de usuários.

ex.: *;…

    1. Notação para especificação de metas

 

  • Cada passo num método é numerado numa ordem seqüencial, com cada nível de decomposição separado por um ponto (.), e com a endentação apropriada para reforçar a noção de hierarquia. Após o último número usa-se dois-pontos (:).

ex.: FU2; 2.1: Anotar correções.

 

  • Um comentário começa com duas barras inclinadas para direita (//) e acaba ao final da linha.

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

 

  • Se uma meta possui mais de um método para ser atingida, uma letra do alfabeto é usada de forma ordenada após o número que descreve a meta.

ex.:

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

FU2; 2A:

… (método A)FU2; 2B:… (método B)

 

 

  • As regras de seleção e o método associado são descritos como pares “condição-ação”, logo após a notação numérica da meta.

ex.: FU2; 2A: se (dia de hoje for sábado)então (fazer relatório semanal)

    1. Reutilizando MetasUm 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.

       

    2. Diretrizes adicionais

 

  • Delimite os passos de um método entre chaves: {}.
  • Em aplicações com apenas uma função de usuário, não é necessário incluir a notação de função usuário antes de cada meta.
  • Num nível de decomposição onde todas as metas têm o mesmo número-prefixo, apenas o número que indica a seqüência naquele nível é necessário.
  • A diretriz anterior se aplica também à notação de função de usuário.
  • Ao reutilizar uma meta anterior é necessário usar a notação completa para ela.

ex.: FU1, FU3; 3: Modificar livro-caixa.1: Procurar lotes em aberto.

2.1: Anotar correções. (meta reusada)

3: Recalcular valores.

Fonte: http://www2.dem.inpe.br/ijar/EngSofAnalEspc.html

Sobre a DANRESA – Com mais de 14 anos de experiência no mercado de TI, a DANRESA é uma Consultoria de Informática com atuação em todo o território nacional, focada em duas linhas de serviços principais e complementares: Fábrica de SoftwareDesenvolvimento de Sistemas, Infraestrutura e Outsourcing de TI. A área de Desenvolvimento é voltada a Projetos de Negócios por meio de Sistemas Personalizados de TI de acordo com a especificidade de cada cliente, realizando levantamento dos processos, análise e programação através de sua fábrica de software ou com profissionais alocados no cliente. Já a área de Infraestrutura inclui serviços como Outsourcing de TI, Gerenciamento e Monitoramento de equipamentos de missão crítica como Servidores, Roteadores, Switches e Links de conectividade, Instalação e Manutenção de pontos de rede, voz e dados, Suporte Técnico por meio de Service Desk – em que os atendimentos são feitos por uma equipe especializada e certificada nas práticas do ITIL – entre outros. Com cerca de 400 colaboradores e 100 clientes, a DANRESA possui em sua carteira empresas como ANFAVEA, BASF (Suvinil), Ernst Young, Sem Parar, Schneider, CBC, Eurobras, Avape, Alves Feitosa Advogados, Instituto Airton Senna, Grupo Kaduna, CVC, WoodBrook, Salles Leite (Iguaçu Energia ), etc. Para mais informações, ligue: (11) 4452-6450