Bem-Vindo !

Este livro é sobre Engenharia de Requisitos, uma area de conhecimento fundamental para a construção de software.

A forma de publica-lo é diferente, mistura a tecnologia de blogs com a de páginas da internet. É um livro vivo.

A base desse livro é um pré-livro que escrevi em 1994. Por vários motivos não foi publicado em forma de livro e só agora -- Julho de 2007 -- consegui disponibilizar seu texto. Esse texto é arquivo imagem no formato "pdf". Esse texto não passou por processo de revisão editorial e contém alguns defeitos, alguns de Português e alguns conceituais. Os defeitos conceituais que existirem serão tratados na evolução do livro. Esse "blog" tem exatamente esse papel, tornar-se um livro vivo.

Os comentários serão abertos, com moderação, mas é pouco provável que sejam respondidos diretamente. Permitirei diálogos de leitores, desde de que sejam de interesse geral. Como o livro é de acesso livre, estarei utilizando anúncios veiculados pelo provedor desse conteúdo (Google). É a maneira que me parece ser mais adequada para essa iniciativa.

Esse livro é de minha inteira responsabilidade. No entanto, tenho que agradecer a PUC-Rio e ao CNPq que apoiam minhas pesquisas em Engenharia de Requisitos.

Os textos pertencem ao autor. Se gostou e quiser usar, use. No entanto, não esqueça de fazer a citação.
[Leite 07] Leite, J.C.S.P., "<"título da nota">","<"mes/ano ">", em Livro Vivo : Engenharia de Requisitos, http://livrodeengenhariaderequisitos.blogspot.com/, 2007

sábado, 20 de abril de 2013

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.

quarta-feira, 1 de junho de 2011

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.

quinta-feira, 21 de abril de 2011

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.

quinta-feira, 13 de maio de 2010

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

quarta-feira, 12 de maio de 2010

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.