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

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.