Observação

Observação é uma técnica em que o engenheiro escuta, vê, “sente”. Nesse caso a fonte de informação é o contexto, ou o local. Nessa técnica o Engenheiro de Requisitos coloca-se numa posição onde possa visualizar num determinado contexto, o comportamento dos atores, como eles lidam com recursos, e com outros atores. 

Seguindo a máxima de Becker, que “pessoas definem atividade”, pode-se observar quais atividades elas desempenham (papéis). Os atores podem também ser agentes não humanos, quando se observa situações com máquinas.

Na observação, o Engenheiro deve tomar nota, tentando extrair o conhecimento da situação (campo visual) registrando os elementos citados: atores/agentes (humanos ou máquinas), os recursos que eles manipulam, e seus papéis (inferindo as atividades desenvolvidas).

A observação é fundamentalmente não participativa, sem interação ou com o mínimo de interação com o campo visual observado. Pode ser necessário, que num mesmo contexto, diferentes campos visuais devam ser utilizados, para evitar uma observação parcial.

A Figura do livro do Prof. Sá Carvalho  (Análise de Sistemas: O Outro Lado da Informática)

simboliza bem essa técnica.

Requisitos Propriamente Ditos

A palavra requisitos pode ter diferentes semânticas.  Três em particular são mais comuns:

• A primeira, de cunho geral, que denota um conjunto de informações necessárias para a construção de um software.  Esse conjunto é composto de informações que procuram significar desejos dos que demandam o software e de informações sobre fatos do contexto onde o software irá operar.
• A segunda, muito usada na literatura, denota modelos escritos em linguagens artificiais que procuram organizar algumas das informações necessárias para a construção de um software.
• A terceira, de cunho específico, denota frases que representam diretivas explícitas a serem levadas adiante pelo software (demanda).  Chamamos essas frases de: Requisitos Propriamente Ditos.

Sobre como representar essas frases (RPD), que devem ser atômicas e com identificador único, leia aqui.

i*

Vejam a parte de i* de um tutorial do SBES.

Vejam a dissertação do Herbet Souza.

Vejam a tese do Antonio de Padua.

Ferramentas de i* podem ser encontradas aqui. Em especial procurem usar a OpenOME ou OME.

Baú de Fatos

Um dos problemas da Engenharia de Requisitos é entender onde termina a elicitação e onde começa a modelagem. Dependendo do Universo de Informações (UdI) esse limite pode ser mais fácil ou mais difícil de ser vislumbrado. Como já ressaltamos no pré-livro, as atividades de elicitar, modelar e analisar estão misturadas, mas sua fatoração é importante, principalmente, pelo lado educativo. Isto é, mostrar que são tarefas distintas conceitualmente, mas que podem estar paralelizadas, ou seja: temporalmente essa distinção pode ser tênue.

Para falicitar a separação conceitual entre elicitação e modelagem, criamos o conceito de Baú de Fatos. Esse baú é um repositório não estruturado onde os Engenheiros de Requisitos, “jogam” os fatos elicitados. Esses fatos podem estar descritos de várias maneiras: listas, frases, frases de requisitos (“O sistema deve...”), tabelas, grafos conceituais, definições de termos, pequenos parágrafos, desenhos explicativos, enfim qualquer maneira que o Engenheiro de Requisito tenha usado para descrever suas anotações após ou durante o uso de técnicas de elicitação. O conteúdo desse baú, apesar de não estruturado, deverá ter uma maneira de identificar cada fato “jogado” no baú; por exemplo, um contador que é aumentado de um a cada descrição de fato que é “jogada” no baú.

Os fatos, como vimos, são o que os engenheiros de requisitos elícitam. Na verdade, esses fatos podem ser ou requisitos para o software ou podem ser conhecimento do UdI necessários para que os requisitos sejam entendidos. Alguns autores de Engenharia de Requisitos falam de requisitos da aplicação e requisitos do domínio; mas essa classificação, no nosso entender, confunde mais que explica. O importante é saber que temos que elicitar tanto o que o software deve fazer como o conhecimento para entender o que ele deve fazer.

O baú de fatos é, portanto, um buffer, utilizado para marcar a passagem do tempo de elícitar para o tempo de modelar. Quando modelamos usamos linguagens bem definidas que limitam nossa liberdade de expressão, porque são sistematizadas, isto é oferecem elementos de representação próprios. Claro, que é possível , como dissemos acima, fazer a elicitação e descrever os fatos usando uma linguagem (criando um modelo) mas isso requer experiência e também limita a possibilidade das anotações. Criando-se um buffer, pode-se pensar melhor em como modelar, e com que linguagem, os fatos “jogados” no baú de fatos.

A Figura que utilizo para explicar o BF é a seguinte:

Na Figura notem que F.Is (Fontes de Informação) são rastreadas bi-direcionalmente para os fatos do baú. Os fatos do baú são rastreados bi-direcionalmente para partes do modelo.

Truques de Becker : Parte III

Os truques (heurísticas) abaixo foram retirados do livro Segredos e Truques da Pesquisa de Howard S. Becker, Ed. Zahar, 2008. O livro original em Inglês foi publicado em 1998. O que estiver entre aspas é uma citação direta do livro. Mantemos as páginas para facilitar a consulta ao livro através de um rastro.

15. Truque das relações contextuais (p. 174)
"Situar qualquer termo que pareça descrever um traço de uma pessoa ou grupo no contexto do sistema de relações a que pertence". Isso nos ensina que se um elemento de um conjunto possui uma característica relacionada ao conjunto, isso não fará que esse elemento tenha a mesma característica em relação a outro conjunto. Uma pessoa considerada alta numa sala de primeiro grau, não necessáriamente será considerada alta num grupo jovens de primeiro grau interessados em aprender basquete.

16. Truque da falácia da página em branco (p. 31)
O cientista social tem de evitar o preenchimento de espaços em brancos com estereótipos que se pode ter em mente. Aqui vale frisar uma parte do texto: ” No entanto, como todos nós afirmamos ser cientistas sociais, não nos contentamos com a imaginação e a extrapolação, como poderiam fazer um romancista ou um diretor de cinema”. Ou seja, o conhecimento anterior que temos, ou que pensamos ter, só poderá ser utilizado se for comprovado no caso em questão.

17. Truque da visão social (p. 73)
"As coisas são apenas pessoas agindo juntas". Esse truque procura demonstrar que os objetos na verdade são entendidos como o contexto social o usa, e, portanto outros usos podem estar mascarados. Portanto, ao estudar as coisas há que levar em conta os contextos sociais que lhe interpretam. O exemplo usado no livro é sobre máquinas de escrever. O teclado QWERTY, o padrão de teclados, foi desenhado com o objetivo de reduzir a velocidade de escrita para que a máquina de datilografia funcionasse a contento. Quando se descobriu que poderíamos ter teclados mais eficientes, já era tarde para mudar um padrão com o nível de aceitação tão maciça.

18. Truque do papel dos atores (p. 70)
"Transformar pessoas em atividades". Esse truque orienta que se evite classificar pessoas por tipos, mas que as pessoas sejam relacionadas por atividades que fazem ou desempenham. Focando e atividades, o fazer, evita-se uma possível estagnação oriunda de classificação por tipo. "O foco em atividades e não em pessoas desperta em nós um interesse pela mudança, e não pela estabilidade, por idéias de processo, e não de estrutura".

19. Truque dos loucos (p. 48)
"Eles devem estar loucos". Quando em algum momento nos defrontamos com situações que aparamente não tem sentido, mas fazem para outros, podemos pensar então na loucura, mas se estudarmos mais a fundo o problema, poderemos descobrir algum sentido que deixamos de ver, a princípio. Becker dá exemplos com a situação da troca de sexos e da prostituição de mulheres visualizadas como "normais". A castração pode ser entendida como loucura, mas pode ter sentido se uma análise mais detalhada for feita. O mesmo em relação a as razões que levam uma mulher a se prostituir.

20. Truque da coincidência (p. 50)
A atenção à coincidência pode levar a que relacionamentos entre eventos ou coisas, sem aparente ligação, possam se tornar explícitos. A revelação de coincidências é possível quando procuramos ter um foco em estórias ou processos. Essas estórias permitem que coisas sem aparente ligação tenham o seu elo revelado. O truque da coincidência consiste em analisar com mais detalhe aquilo que aparentemente é, somente, mera coincidência.

Truques de Becker : Parte II

Os truques (heurísticas) abaixo foram retirados do livro Segredos e Truques da Pesquisa de Howard S. Becker, Ed. Zahar, 2008. O livro original em Inglês foi publicado em 1998. O que estiver entre aspas é uma citação direta do livro. Mantemos as páginas para facilitar a consulta ao livro através de um rastro.

6. Truque da congruência e da coerência (p. 39)
As descrições resultantes da tarefa de entendimento do meio social devem ser coerentes, ou seja devem ter início, meio e fim; devem fluir. Essas estórias também devem ser congruentes, isto é refletir os fatos da realidade.

7. Truque do “como” ao invés do “por que” (p. 85)
Muitas vezes o uso da pergunta "por que" pode ser impróprio. Becker, no contexto de pesquisa social, acredita que o "por que" intimida; provocando respostas defensivas. Ele sugere o uso do "como" para chegar-se ao que se deseja saber. Ele argumenta que a pergunta "como" é menos intrusiva.

8. Truque das anomalias (p. 84)
Em algumas situações encontram-se partes que fogem da regra, são anômalas, isto é: são um ponto fora da curva. Esses casos devem ser tratados com cuidado, quer para invalidar uma conclusão geral, ou para chamar a atenção para uma eventual exceção. Ou seja, se existe razão para uma conclusão geral, essa não deve ser impedida por um caso anômalo, mas que precisa ser tratado.

9. Truque do lugar (p. 83)
"Tudo tem que estar em algum lugar". Esse truque enfatiza o uso da pergunta "onde" do conjunto básico de questões de Quintilian (O quê, Por quê, Quem, Quando, Onde, Como). Enfatiza também o sentido de contexto, ou o mapa. Veja nas notas de aula (Parte II).

10. Truque da omissão (p. 83)
"Insira o que não puder ser omitido". Esse truque enfatiza a noção de que se deve ter atenção ao que é essencial e remete ao truque da essência.

11. Truque do tempo (p. 83)
"Tudo tem que acontecer em algum momento". Esse truque enfatiza o uso da pergunta "quando" do conjunto básico de questões de Quintilian.

12. Truque da dúvida (p. 124)
"Duvide de tudo que lhe for dito por qualquer pessoa que detenha o poder". Claro que, isoladamente, essa frase é discriminatória e pouco científica, no entanto, o que Becker quer dizer é que muitas vezes ao fazer uma investigação, os clientes de nossa investigação por diversos motivos, delimitam o acesso ao Universo de Informações as quais se terá acesso (Ver Seção 2, da Parte III). Cabe ao engenheiro de requisitos deixar claro, aos interessados, sobre os problemas gerados por análises parciais.

13. Truque da definição do conceito (p. 161)
"Deixe o caso definir o conceito". Aqui Becker argumenta que o estudo de situações usando-se um conceito já estabelecido limita o que podemos apreender sobre a situação, o que justificaria partir-se para uma estratégia diversa que seria a produzir conceitos com base nos casos. Na verdade esse truque é fundamental porque tem implicações sobre a tarefa de classificar.

14. Truque da completeza (p. 60)
Evitar a concentração em elementos únicos e estudar também aqueles relacionados. O exemplo dado por Becker foi a implantação de um política publica para doentes mentais que se mostrou ineficaz porque deixou de levar em conta além dos pacientes, suas famílias.

Truques de Becker : Parte I

Os truques (heurísticas) abaixo foram retirados do livro Segredos e Truques da Pesquisa de Howard S. Becker, Ed. Zahar, 2008. O livro original em Inglês foi publicado em 1998. O que estiver entre aspas é uma citação direta do livro. Mantemos as páginas para facilitar a consulta ao livro através de um rastro.

1. Truque da essência (p. 180)
"Quando levanto a mão, meu braço se levanta" se pensarmos nessa ação sem o braço, fica evidente que a ação não ocorrerá. Portanto lembre-se: esse truque ajuda a eliminar o acessório do que essencial num dado fenômeno. Becker chama esse o truque de Wittgenstein, porque essa reflexão provém do dito filósofo.

2. Truque da causa (p. 91)
Quando estudamos algo é importante usar a idéia de causalidade, já que isso permite estabelecer relações importantes. Beck argumenta que, o raciocínio sobre variáveis dependentes e independentes, quando se faz uma pesquisa, ajuda a estabelecer causalidade, já que, se uma variável dependente sofrer impacto com a mudança de uma variável independente pode-se estabelecer causalidade.

3. Truque da generalização (p. 165)
"Diga-me o que encontrou, mas sem usar nenhuma das características definidoras do caso real”. Ou seja, procure descrever algo que ocorreu sem utilizar os descritores fundamentais. Por exemplo, se você estiver diante de uma situação que envolve, por exemplo, professores e alunos num processo de avaliação de ensino, explique isso sem mencionar professores, alunos ou ensino. Isto é, diga que a situação envolve emissores e receptores e avaliação da qualidade da emissão. Generalizações são extremamente úteis, mas tem que ser utilizadas com muito cuidado.

4. Truque da resposta (p. 160)
"As informações que tenho são resposta para uma pergunta, qual seria essa pergunta?". Ou seja, uma vez tendo coletado uma série de informações sobre fatos, como será que esses fatos estarão relacionados com uma indagação? Que indagação? A resposta a essa pergutna leva a que, ao tratar desses fatos, fique claro qual o objeto de interesse em estudo, para o qual esses fatos sejam relevantes.

5. Truque da hipótese nula (p. 40)
Para explicação do truque chamado Hipótese Nula, recorremos ao livro de Pedro Alberto Barbetta, “Estatística Aplicada às Ciências Sociais”. Segundo Barbetta: “ Dado um problema de pesquisa, o pesquisador precisa saber escrever a chama hipótese de trabalho ou hipótese nula. Esta hipótese é descrita em termos de parâmetros populacionais e é, basicamente, uma negação daquilo que o pesquisador deseja provar. “, “Quando os dados mostrarem evidência suficiente de que a hipótese nula H0, é falsa, o teste a rejeita, aceitando em seu lugar a chamada hipótese alternativa, H1. A hipótese alternativa é, em geral, aquilo que o pesquisador quer provar, ou seja, a própria hipótese da pesquisa, considerando a foram do planejamento da pesquisa.
Como exemplo: “H0: a proporção de homens fumantes é igual à proporção de mulheres fumantes, na população em estudo.” e “H1: a proporção de homens fumantes é diferente da proporção de mulheres fumantes, na população em estudo”. Vejam quer a hipótese nula é colocada na forma de igualdade e a alternativa em termos de desigualdade. Para refutar a H0 é necessário verificar se os dados fornecem evidência suficiente, isto, em estatística, significa aplicar um teste de significância.

Veja mais aqui.

O livro de Becker usa o troque da hipótese nula como uma forma de coletar mais informações. Falamos sobre o caso de escolhas aleatórias de população de pesquisa e do caso do que você esta fazendo aqui. Escolher aleatoriamente participantes de uma pesquisa como hipótese nula leva a que se estude as razões de porque rejeitar tal hipótese e nesse processo aprende-se mais como melhor escolher os participantes. No caso do que você esta fazendo aqui, parte de uma hipótese aparentemente sem sentido, mas que ao tentarmos refutá-la consegue-se saber mais sobre a aparente falta de sentido da hipótese nula

Segredos e Truques da Pesquisa

Esse é o título de um livro do Professor Howard S. Becker. É um livro que ensina, com
base em exemplos, uma série de heurísticas úteis para que um investigador social proceda uma investigação da melhor maneira.

Acreditamos que muitos desses "truques" podem ser de relevância para o Engenheiro de Requisitos, principalmente quando desempenhando as tarefas de elicitação de requisitos.

Nas notas seguintes estaremos detalhando uma série desses truques, bem como dando ponteiros para o livro, segundo sua primeira edição em Português pela editora Zahar.

Falácia da Página em Branco

Falácia da Completeza

Reuniões

O uso da técnica de reunião durante a Elicitação é muito difundido em situações onde vários interessados devem ser ouvidos num mesmo contexto temporal. Pode ser entendida como uma extensão da técnica de entrevista ou da técnica de participação ativa dos atores (Clientes) do UdI.

Uma reunião pode englobar um ou mais atores no papel de engenheiro de requisitos. Os participantes de uma reunião de elicitação de requisitos são os interessados no sistema de software. Eventualmente um moderador de reuniões pode estar presente para ajudar a condução da reunião. A existência de um moderador dependerá do tipo de reunião a ser conduzida, tendo em vista que alguns métodos de reunião demandam o papel de moderador.

Reuniões permitem que requisitos sejam elicitados de uma maneira participativa, já que são vários, os interessados, além dos engenheiros de requisitos, presentes a uma reunião. Essa maneira participativa apresenta vantagens e desvantagens que precisam ser bem exploradas e controladas. Sob a ótica da vantagem tem-se que várias opiniões podem ser contrastadas de modo a enriquecer o conhecimento sendo elicitado. No que diz respeito à desvantagem, é preciso ter cuidados para que não se perca o foco da reunião, nem que divergências não-funcionais, aquelas referentes a aspectos pessoais dos participantes, sobressaiam.

Duas técnicas: “JAD” e “Brainstorm” são bastante mencionadas na literatura de engenharia de software. A última é uma técnica de reunião onde se enfatiza a opinião livre sobre determinados assuntos em pauta, principalmente sob a ótica de aplicação de novas idéias para a resolução de problemas. Esse tipo de técnica, quando bem conduzida e com pessoas criativas, pode, muitas vezes, resolver problemas de uma forma original e criativa. Na elicitação de requisitos a técnica precisa ter uma boa moderação de maneira a evitar a perda de foco, já que uma reunião de elicitação de requisitos não se destina a resolução de um problema, mas de aprofundar o conhecimento sobre determinado tópico. Veja aqui uma descrição sobre "brainstorm", aqui e aqui também.

O “JAD” (“Joint Application Design) tem por objetivo fazer com que os clientes e usuários participem, por intermédio de reuniões, na discussão sobre a definição de um sistema de software. O “JAD” tem formulários e processos bem definidos que ajudam os interessados na representação e discussão do conteúdo de um artefato de software. Vejam, aqui e aqui, textos sobre essa estratégia.

É recomendável a leitura do trabalho de mestrado de Cecilia Camacho sobre reuniões. A autora faz uma evolução de um método criado na PUC-Rio para aumentar o nível de conflito funcional em uma reunião.

Entrevistas

Sem dúvida, de todas as técnicas de coleta de fatos, a mais comum e mais conhecida é a entrevista.

Uma entrevista é normalmente uma comunicação entre entrevistado e entrevistador. No caso de engenharia de requisitos, o entrevistador é o engenheiro de requisitos e o entrevistado é o cliente ou um interessado no software para o qual se quer conhecer os requisitos.

Um interessado pode ser desde um futuro operador de um artefato no qual o software fará parte ou o executivo da empresa que pagará pelo software, mas que dificilmente irá interagir com o mesmo. Portanto, a diversidade de entrevistados demandará estratégias distintas de entrevista.

Entrevistas são classificadas como estruturadas ou não-estruturadas. Uma entrevista estruturada requer um prévio conhecimento sobre o contexto onde se aplica a entrevista. Uma entrevista não-estruturada é aplicada quando se inicia o contato com o Universo de Informações e serve para garimpar informações iniciais. Fundamentalmente o entrevistador deixa o entrevistado falar, mas procura orienta-lo para que a entrevista mantenha o foco no tópico de interesse.

O papel do entrevistador na entrevista não estruturada é um papel de aprendizado.

A entrevista estruturada é feita com base em perguntas previamente pensadas ou delineadas, é uma entrevista mais focada porque é dirigida por um elenco de perguntas que já têm um foco específico. Claro, que o entrevistador tem liberdade de inserir perguntas de clarificação ou eventualmente outras que se façam necessárias, mas o núcleo de perguntas já é definido a priori.

Ressaltamos que muitas vezes a equipe pode usar perguntas preparadas por outros atores, mas é comum que os entrevistadores sejam aqueles que elaboram as perguntas.

Perguntas de controle, que usam de redundância para identificar problemas, é uma maneira de auferir mais qualidade nas respostas.

O papel do entrevistador na entrevista estruturada é um papel de questionador.

O engenheiro de requisitos no papel de entrevistador deve ter cuidados ao conduzir uma entrevista, tanto porque pode estar falando com interessados de alto poder de decisão como também com interessados que podem estar receosos de mudanças organizacionais. O principal é estabelecer, desde do início, um clima de colaboração, no o qual a entrevista é um fator importante para que o contexto seja melhor compreendido pelos profissionais de informática.

Uma entrevista pode ser conduzida por mais de um entrevistador e pode ter mais de um entrevistado.

Cabe ao entrevistador tomar notas ao longo da entrevista. Essa tarefa é difícil. O método de anotar palavras chaves e usar setas para ligar essas palavras chave é o mais recomendado, mas exige prática. A prática de gravar entrevistas e anotar com base na gravação é um recurso que pode ajudar, mas é preciso levar em conta que haverá o custo extra de escutar a gravação. Em alguns casos o entrevistado tem interesse que a entrevista seja gravada, assim como alguns preferem que se evite o uso do gravador. É claro que a política de gravação deve ser acordada com o entrevistado.

As anotações de entrevistas tornam-se documentos do processo de construção de requisitos e devem seguir padrões de armazenamento de modo a facilitar consultas futuras. Esses padrões devem atender aos requisitos de rastreamento.

Aponto quatro referências que apresentam diferentes visões sobre entrevistas. Vale a pena
conferir. A primeira tem uma visão jornalística, a segunda apresenta uma visão do ponto de vista social, a terceira mostra o esquema de um curso sobre entrevistas e a quarta mostra um procedimento padrão para entrevistas de auditoria.

Técnicas de Coleta de Fatos (Elicitação)

Conforme o texto da Seção 3 da Parte III são as seguintes as estratégias que se pode utilizar para coletar fatos:

• Leitura de Documentos
• Observação
• Entrevistas
  
• Questionários
• Análise de Protocolos
• Participação Ativa dos Atores (Clientes)
• Enfoque Antropológico
• Reuniões
• Reutilização
• Recuperação do Desenho

Outra estratégia que é bastante útil é o Ordenamento de Cartões. Essa técnica é útil para elicitarmos relacionamentos entre conceitos, com também para identificarmos níveis de abstração utilizados no Universo de Informações. A técnica consiste em distribuir cartões com frases ou palavras para os interessados (clientes) e pedir que, individualmente ou em grupo, eles formem grupos com os cartões e nomeiem os grupos. Em Inglês chama-se de “Card-Sorting”. Veja aqui uma animação de como funciona essa técnica (clique em "Open Sort") (em Inglês).

Identificação de Fontes de Informação

Na Seção 2 da Parte III, descrevemos a importância da identificação das fontes de informação. Afinal, é da qualidade das fontes de informação que dependemos para elicitarmos o conhecimento do que se demanda do software a ser construído ou evoluído.

Além de ressaltarmos que as fontes de informação podem ser de diferentes tipos, além de pessoas, detalhamos heurísticas gerais que ajudam na identificação de fontes de informação.

Em um artigo publicado no WERpapers, um método para identificação de fontes de informação é proposto. O método é colaborativo e envolve pelo menos três engenheiros de requisitos. São 5 as etapas a serem seguidas pelo método.

1. Seleção: nesta etapa, cada engenheiro de requisitos, usando as heurísticas como as da Seção 2, elabora uma lista de fontes de informação encontradas no Universo de Informações. A heurística principal consiste em que observar as fontes de informação que respondem as perguntas: O que? Quem? e Onde?. O “o que” normalmente leva a documentos ou sistemas, o “quem” leva a atores do Universo de Informações e “onde” leva a lugares onde o software irá operar.
2. Desenho: cada engenheiro desenha um grafo de influência ligando através de relacionamentos as várias fontes de informação.
3. Consolidação: em uma reunião os engenheiros constroem coletivamente um grafo que consolide os grafos construídos individualmente.
4. Eleição: em uma reunião com base no grafo consolidado os engenheiros discutem e propõem estratégias de elicitação para cada fonte.
5. Avaliação: através de reunião os engenheiros estabelecem prioridades e custo associados a cada fonte.

Elicitação

A palavra acima é um neologismo. Foi criada para distinguir essa tarefa tão fundamental para a construção de software.

O texto na Parte III define-a como uma mescla de outras palavras como: clarear, entender, extrair. A Figura 1 da Parte III procura detalhar a semântica de elicitar.

A Necessidade da Elicitação

A Seção 1 (Introdução) da Parte III ressalta a importância da tarefa de entendermos o que é preciso ser feito, antes de começarmos a fazer. Essa afirmação é óbvia, mas é muitas vezes esquecida por engenheiros que se apressam em construir antes de entender exatamente o que se deseja construir. Para ressaltar a importância da tarefa de ELICITAR citamos no texto dois autores: von Neumann e Polya. Dois matemáticos: um deles é o responsável pela teorização que levou a concepção dos computadores digitais; outro é responsável por uma série de trabalhos no campo da matemática e do seu ensino, em particular a maneira de resolver problemas.

Sobre von Neumann repito aqui o que escrevi em outro lugar:

Por que os requisitos são importantes? São várias as razões, mas: a mais evidente é porque não se pode construir nada, sem que antes saiba-se o que se quer construir. Eu utilizo, há muito tempo, uma frase atribuída a von Neumann que diz:

There is no sense in being precise about
something when you do not even know what you
are talking about.

Esta frase foi encontrada em um dos livros de Gerald Weinberg. Cabe a ele a citação original. Vale lembrar quem foi von Neumann. Veja também este elo.

Sobre Polya, utilizei três questões que são freqüentes em várias citações ao seu trabalho:

a) “What is the unknown?” ( qual a incógnita?)
b) “Do you know a related problem?” (conheces um problema semelhante?)
c) “Could you restate the problem?” (podes repetir o problema com suas palavras?)

Alcino Simões e Lisette Poggioli fornecem mais detalhes sobre o tema. A Universidade de Lisboa disponibiliza um resumo sobre Polya.

Além das citações a Polya e a von Neumann, gostaria de ressaltar alguns truísmos que identifiquei em um artigo de Michael Jackson, e que considero de fundamental importância.

a)"Distinguish the machine from the problem domain"
b) "Don’t restrict description to the machine",
c) "State explicitly what is described".
d) “Requirements Are Not Given Properties”,
e) “The Model Is Not the Reality”, and
f) “The Problem Is Not at the Interface”

Esses “mantras” estão contextualizados na diferença que Jackson faz da máquina computacional (software e hardware) e o contexto no qual essa máquina irá atuar (“problem domain”). Para ele requisitos é a ponte entre o contexto (Universo de Informações) e a máquina.

Desses seis “mantras” é importante saber: que o “problema” não está na interface, que requisitos não são propriedades previamente existentes, que a máquina deve ser entendida como separada do Universo de Informações e que o modelo não é a realidade.

Fundamentalmente, os “mantras” de Jackson expressam a necessidade da elicitação dos requisitos, e que esses precisam refletir a perspectiva da máquina e a perspectiva do contexto onde a máquina irá atuar.

Evolução do Universo de Informações

A Figura 17 página 26 (Parte II) mostra algo que, comumente, é esquecido.

A Figura mostra que o Universo de Informações evolui na medida em que construímos os requisitos! Ou seja, a base, que utilizamos para entendermos o que os clientes desejam, muda durante o processo de construção dos requisitos. É preciso ter consciência de que isso é uma dificuldade, a mais, no processo de entender as necessidades dos clientes.

Portanto, é importante que a fase de construção de requisitos tenha uma visão de processo contínuo. É preciso saber que os requisitos não estão prontos para serem descritos e formalizados, que o próprio processo de questionamento dos requisitos leva a com que eles mudem.

Processo de Construção de Requisitos

A Figura 16 página 25 mostra nosso entendimento do processo de construção de requisitos. Essa Figura é de um modelo SADT [Ross 77] do tipo “actigrama”, ou seja utiliza a perspectiva de função ou atividade. Nele vemos o quão importante é escolher as pessoas e os métodos com que se irá trabalhar. Mostra também que, fundamentalmente, o processo de construção de requisitos (no livro uso o termo definição) é pautado por três atividades: elicitar, modelar e analisar. É importante notar que a saídas dessa Figura: delta, requisitos e modelo refletem: a importância da retro-alimentação, o papel de comunicação dos requisitos em linguagem natural e a necessidade de utilização de modelos para explicitar a semântica dos requisitos.

A Figura 16 abstrai-se do processo gerencial que é ortogonal ao processo de construção e que fundamentalmente cuida para que o processo seja eficaz e eficiente. Particularmente importante, é notar, que o ciclo de retro-alimentação é inerente ao processo, através da produção de deltas. Esses deltas podem ser gerados pelas atividade de análise. No contexto da atividade de análise é importante ressaltar a implementação de políticas de qualidade quer por processos de verificação, quer por processos de validação.

Referência Bibliográfica

[Ross 77] Douglas T. Ross: Structured Analysis (SA): A Language for Communicating Ideas. IEEE Trans. Software Eng. 3(1): 16-34 (1977)

Universo de Informações

A Seção 2 da Parte II procura ressaltar o papel de contexto na produção de software. O texto enfatiza a importância de modelos como força de contextualização. Esses modelos estabelecem perspectivas para os engenheiros de software.

O conceito de Universo de Informações (UdI) é essencial na produção de software. Todo processo de software tem um UdI, no entanto muitas vezes os engenheiros de software não tem um mapa desse UdI. Você já esteve numa situação onde, em terras estranhas, você precisa locomover-se? Turistas precisam de mapas, porque querem saber como locomover-se em lugares com os quais não tem familiaridade.

Definimos UdI como:

"É o contexto no qual o software deverá ser desenvolvido e operado. O UdI inclui todas as fontes de informação e todas as pessoas relacionadas ao software. Essas pessoas são também conhecidas como os atores desse universo. O UdI é a realidade circunstanciada pelo conjunto de objetivos definidos pelos que demandam o software."

É no UdI que os engenheiros de requisitos irão trabalhar. É no UdI que o software desempenhará suas funções.

Saber da existência do UdI é fundamental. Saber que o UdI é um corte da realidade, ou seja é uma redução do contexto mais geral, mundo, para um contexto mais específico. Em Banco de Dados utiliza-se o nome Mini Mundo. O termo escopo é também utilizado em alguns métodos de produção de software.

O UdI é representado por uma forma que se assemelha a uma nuvem. Essa forma é importante porque mostra que os limites (vejam os pontos fundamentais da TGS, Parte I) não são bem definidos. A forma gasosa da nuvem passa também a idéia de volatilidade, e essa característica é também presente no UdI, em maior ou menor grau, dependo de cada caso. Na verdade, o UdI diminui ou aumenta na medida em que, no processo de construção de software, melhor entendemos as necessidades dos clientes e as restrições de implantação. O UdI evolui.

A estratégia para mapear o UdI é fundamentada no objetivo mais geral disponível. Ou seja, no evento que dispara o uso do SDS (veja entrada do SDS). Um processo de produção de software é iniciado por atores que têm interesse na construção ou evolução de um determinado artefato de software. Vejamos três casos como exemplo.

Caso 1: uma empresa produtora de software tem conhecimento de um edital para concorrência pública para a evolução de um sistema de software. O edital mencionará o objeto da concorrência, a infra-estrutura de software pré-existente, normas de produção, por exemplo, a Mps. Br, local físico onde o trabalho deverá ser implantado entre outras informações. Nesse caso, o edital, através de suas informações, delineia a primeira versão do UdI.

Caso 2: o departamento de software de uma organização recebe um memorando do diretor financeiro pedindo que um novo sistema de software seja feito para auxiliar a visualização do acompanhamento do fluxo de caixa da organização. O UdI nesse caso já tem um delimitado o ator requisitante (diretor financeiro), o objetivo geral (software de visualização) e onde será empregado (integração como sub-sistema de fluxo de caixa).

Caso 3: um empreendedor resolve apostar na construção de um software para ajudar as pessoas no controle de suas finanças. O empreendedor acredita que as soluções disponíveis deixam a desejar e pensa em fazer um software, que será acessado via navegadores padrão, com facilidade de mobilidade (celular). Portanto esse empreendedor já estabeleceu os contornos do UdI em pauta.

Para a Engenharia de Requisitos o UdI é de fundamental importância porque será no UdI que as fontes de informação serão identificadas. Essas fontes de informação é que permitirão com que o delineamento do UdI seja elaborado e constantemente evoluído. O Engenheiro de Requisitos precisa das fontes de informação da mesma maneira que um repórter precisa de fontes para escrever uma matéria.

O UdI é formado através de aproximações sucessivas, principalmente na identificação de fontes de informação. As fontes de informação podem ser de diferentes tipos, sendo as principais: atores (pessoas ou organizações), artefatos de software, artefatos físicos e documentos.

Uma estratégia utilizada para identificar as fontes de informação é saber que fonte de informação aponta para outras fontes de informação. As fontes mais referenciadas certamente deverão ser consideradas na formação do UdI: se pensarmos em grafos essas fontes seriam nós com um maior número de elos.

Outra maneira de identificar a importância de fontes de informação é através de prioridades. No que se refere a atores, normalmente os "donos" do software são os de maior prioridade.

Um mapa de fontes de informação se assemelharia ao uma rede, como a mostrada num mapa de ligações entre grandes corporações alemãs. O uso do software "They Rule" permite que você monte seu próprio mapa de atores do mundo corporativo americano.

Modelos

Na parte II, ressaltamos quatro pontos fundamentais para melhor entendermos o contexto de um artefato de software.

São eles:

• Aspectos Sociais
• Modelos
• Um Sistema é Sempre um Sub-Sistema de um Sistema Maior
• A Definição de um Sistema é Função da Implantação de Seu Macro-Sistema
• Falácia da Completeza
• Falácia da Página em Branco

Um desses pontos é o conhecimento de modelos (páginas 4 e 5, Parte II). Aqui usamos o sentido da palavra modelo de uma forma bastante ampla. Modelos são abstrações gerais sobre algo do mundo real. Apresentamos diferentes Modelos na Seção 3 da Parte II.

Um desses modelos é o modelo de Sá Carvalho. Esse modelo mostra que, para entendermos o que uma Fábrica de Informações deve produzir, é necessário saber quais as ações concretas que ocorrem no contexto organizacional em que essa Fábrica funcionará. Veja que Sá Carvalho usou de uma analogia para descrever Sistemas de Informação como Fábricas. Ações concretas são ações que ocorrem numa organização e que estão diretamente relacionadas com seus objetivos.

O modelo de Sá Carvalho mostra que devemos deslocar o foco do que a Fábrica produz, ou deverá produzir, e centrar nossa atenção na razão da existência da Fábrica. Dessa maneira, o modelo nos ensina que, para chegarmos as saídas da fábrica, devemos fazer um percurso inverso: identificar as ações, identificar as tomadas de decisão que motivaram a ação, e identificar as informações necessárias para as decisões.