O processo de determinar requisitos é chamado de processo de definição de requisitos. Tê-lo bem definido auxilia, em muito, o entendimento do que precisa ser realizado ao desenvolver ou evoluir um determinado sistema ou componente, bem como auxilia na gerência dos requisitos. Com um processo bem definido pode-se obter (elicitar), entender e validar as necessidades e expectativas do cliente e, posteriormente, documentá-las (documento Especificação de Requisitos).

O principal objetivo do processo de definição de requisitos é concluir com êxito um acordo entre quem solicita e quem desenvolve, estabelecendo clara e rigorosamente o que deverá ser produzido. O processo de definição de requisitos compreende basicamente três subprocessos: elicitação, modelagem e análise, que na sua utilização, são adaptados para cada caso. Um exemplo das atividades de um processo de definição de requisitos pode ser encontrado em [2] e [3].

Além de ser ter um processo de definição de requisitos é importante salientar a questão da gerência de requisitos. Esta preocupação está clara no CMM [4], um exemplo de modelo de melhoria do processo de desenvolvimento de software. Este modelo define, em seu segundo nível de maturidade, a necessidade da gerência de requisitos e estabelece as seguintes metas a serem alcançadas pela organização:

Os requisitos possuem uma forte característica: podem mudar, evoluir durante todo o ciclo de vida de um sistema. Ou seja, desde a elicitação até a desativação do sistema os requisitos podem ser alterados, novos requisitos podem surgir e requisitos definidos podem ser excluídos devido a motivos, como por exemplo, restrições de implementação. E a proposta de manter planos, artefatos e atividades de software consistentes com os requisitos alocados torna-se uma tarefa complexa. Dessa forma, para auxiliar na gerência dos requisitos deve-se estabelecer uma baseline de requisitos.

Uma baseline é um conjunto de artefatos aceitos e controlados, e que serão utilizados em atividades posteriores à sua aceitação. A evolução da baseline se dá através da evolução dos artefatos existentes, exclusão de artefatos ou adição de novos artefatos e documentos, e é um indicador do progresso realizado no desenvolvimento dos trabalhos. Uma vez estabelecida uma baseline, a alteração da mesma (dos artefatos aceitos e aprovados) só pode ser realizada via procedimento formal. Assim, a partir do momento que alguns requisitos forem definidos pode-se estabelecer uma baseline de requisitos e desta forma, tem-se um controle maior sobre as alterações e as versões dos requisitos. Para maiores detalhes veja a proposta de baseline de requisitos em [5].

Além destes pontos é necessário conhecer os processos que tratam dos requisitos. Não se pode esperar um gerência efetiva se não se sabe realmente como as atividades são realizadas e como deveriam ser realizadas. No entanto muitas pessoas executam atividades relacionadas a requisitos sem sequer conhecer ou definir um processo de requisitos. Aprenderam um dia com alguém, que o cliente define os requisitos; deve-se realizar uma análise; os requisitos gerados serão a base para o desenvolvimento e, quando possível, devem ser documentados. Percebe-se então, que não existe um controle sobre as alterações e versões dos requisitos e imaginar um rastreamento dos requisitos é impossível. Sem contar com fato que a "análise de requisitos" (assim denominado todo e qualquer processo relacionado a requisitos; não existe claramente o conceito de processo) é um conhecimento das pessoas e não da organização. Na medida que um analista sai da organização e o processo não está documentado o conhecimento o acompanha. A definição e documentação de processos fornece dados para uma gerência efetiva na medida que medições podem ser realizadas, na medida que o acompanhamento do processo pode revelar áreas de melhoria e na medida em que é um guia para a execução das atividades.

Considerando a importância da definição e documentação de processos, propomos um esquema básico para registro e organização dos processos de requisitos. O CMM também dá esta ênfase em processos, no seu nível 3, e apresenta uma proposta de se ter um processo de software padrão da organização, onde um de seus elementos seria o processo de requisitos. Este processo padrão é então adaptado, segundo critérios e diretrizes, para definir um processo específico para cada projeto. No entanto, o CMM não define quais são estes critérios e diretrizes e não descreve como elaborá-los. Fowler [6] também apresenta uma forma de manter e disponibilizar "um conhecimento sobre requisitos", ou seja, apresenta procedimentos e outros documentos relativos a requisitos e suas práticas. Este conhecimento auxilia na definição de processos.

Como a nossa proposta envolve padrões (patterns), faremos, a seguir, uma breve introdução ao conceito, que está mais detalhado em [7].

Em Coplien [17] é abordada a questão de padrões de organização e de processo (process and organization patterns). Coplien comenta que o estudo de processos e organizações é um domínio maduro. Entretanto, a forma de padrões para a descrição desses processos ainda é um tema de pesquisa.

Recomendação: isto é extremamente importante para incluir o uso de <protótipos> como parte chave da análise de requisitos.

Pré-condição: estabelecer e manter um acordo com o cliente; a análise de requisitos só inicia quando a investigação estiver completa e todos os envolvidos forem identificados.

Entradas: Requisitos.

Saídas: Especificação de requisitos validados; uma ou mais simulações de produtos.

Vale ressaltar que a forma de documentar processos segundo três pontos de vista (processo padrão, padrão de processo e processo solução) e segundo três níveis de detalhamento (processo indivíduo, processo em família e processo em comunidade), permite uma melhor organização e entendimento dos processos, possibilitando a adaptação dos mesmos às características específicas, por exemplo, de cada projeto.

A organização proposta é uma forma sistemática para especialistas em Engenharia de Requisitos registrarem e manterem seus conhecimentos relativos a processos de requisitos. Também é um guia para os sucessores destes especialistas e gerentes, no que se refere a execução e gerência de processos relativos a requisitos, mantendo o conhecimento na organização.

Também é importante salientar a clareza da organização na medida em que a mesma utiliza a descrição de padrões de processos em linguagem natural com base em um léxico ampliado da linguagem (LAL) [23]. Este léxico possibilita uma descrição mais precisa dos termos utilizados e facilita a possibilidade de rastreamento das informações utilizadas no processo [5].

Entendemos que nossa proposta de aplicação de um esquema baseado em padrões para organizar o processo de requisitos abre oportunidade para trabalhos futuros, tanto no aspecto de aquisição de conhecimento, através da elaboração de padrões de requisitos como também na possível integração da organização proposta com o conceito de base de requisitos (requirements baseline) [5], com ênfase no aspecto evolutivo. Também está claro que são necessários mais estudos de caso para validar os conceitos aqui apresentados e os futuros desenvolvimentos a partir desses.