Apesar dos processos de desenvolvimento de sistemas variarem muito de tamanho e complexidade, bem como dependerem do tipo de sistema e das
organizações envolvidas no seu desenvolvimento, existem algumas etapas principais que são comuns a todos eles. A figura 2.3 apresenta um processo genérico de desenvolvimento de sistemas, onde são destacadas as etapas que envolvem o processo de engenharia de requisitos (KOTONYA, 1998).
Figura 2.3: Processo de desenvolvimento de sistemas (KOTONYA, 1998) As etapas da figura 2.3 tem as seguintes definições (KOTONYA, 1998):
Definição dos requisitos de sistema: nesta etapa os requisitos globais do sistema são estabelecidos. Usualmente estes requisitos são expressos em um alto nível de abstração, geralmente utilizando uma linguagem natural, gerando a especificação de requisitos do sistema. Algumas restrições (consideradas críticas para o sucesso do sistema) podem estar incluídas nesta etapa, contribuindo para a elicitação dos RNF;
Partição da arquitetura: nesta etapa é realizado o projeto da arquitetura do sistema, sendo o mesmo decomposto em um conjunto de subsistemas;
PARTIÇÃO DA ARQUITETURA DESENVOLVIMENTO DOS SUBSISTEMAS INTEGRAÇÃO DO SISTEMA VALIDAÇÃO D0 SISTEMA ALOCAÇÃO DE REQUISITOS DEFINIÇÃO DE REQUISITOS DECOMPOSIÇÃO DE REQUISITOS
Alocação de requisitos: nesta etapa os requisitos são distribuídos nos vários subsistemas, sendo definidos quais requisitos serão atribuídos ao hardware e quais serão atribuídos ao software;
Decomposição de requisitos: nesta etapa os requisitos de alto nível de software (e de hardware) são decompostos em um conjunto mais detalhado de requisitos que serão aplicados aos componentes do sistema;
Desenvolvimento dos subsistemas: nesta etapa os subsistemas de hardware e software são projetados e implementados em paralelo, prosseguindo o detalhamento dos requisitos em função do detalhamento destes;
Integração do sistema: nesta etapa os subsistemas de hardware e software são unidos e testados em conjunto para comporem o sistema completo; Validação do sistema: nesta etapa o sistema é validado contra seus requisitos
globais (definidos na especificação de requisitos do sistema e detalhados durante o processo de desenvolvimento do sistema).
As etapas da figura 2.3 estão representadas numa seqüência progressiva, entretanto, existe uma interação entre cada etapa e a etapa anterior (interação especialmente forte entre as etapas de partição, alocação e decomposição) de modo que, se algum erro for detectado em relação à especificação de requisitos, a etapa anterior terá que ser revisada, evidenciando um mecanismo iterativo no processo da engenharia de requisitos em relação ao desenvolvimento do sistema.
Dessa forma, os modelos de ciclo de vida tradicionais (que pressupõem uma seqüência de etapas, onde uma só inicia-se quando a anterior termina) são modelos muito simplificados, na medida em que eles não consideram a forte interação entre as etapas de decomposição e integração dos vários elementos que compõem o sistema. Na prática, tem sido observado que o modelo de desenvolvimento de sistema em espiral é o aquele que melhor modela essa realidade (DORFMAN, 1997).
O mecanismo iterativo de refinamento dos requisitos faz com que o processo de manutenção de requisitos do sistema possa ser uma atividade complexa, exigindo
uma documentação adequada e um processo de gerenciamento de requisitos extremamente organizado, para permitir a sua rastreabilidade em qualquer fase do ciclo de vida do sistema (FIORINI, 1998); (VAN LAMSWEERDE, 2000).
Na figura 2.3 evidencia-se um envolvimento entre a definição de requisitos e a partição da arquitetura do sistema, logo no início do processo de desenvolvimento. Neste contexto, o desenvolvimento da arquitetura do sistema associado à definição dos requisitos torna-se estratégica, uma vez que a necessidade de descrição da arquitetura do sistema define a estrutura do projeto, as estratégias de desenvolvimento e pode limitar o atendimento dos requisitos do sistema. Assim, os requisitos do sistema poderão ser mais robustos, se a definição da arquitetura do sistema for associada à elicitação dos requisitos, considerando-se a participação dos vários envolvidos nos processos de aquisição, definição, desenvolvimento, utilização e manutenção do sistema (stakeholders), bem como considerando-se os vários cenários de utilização (especialmente nas etapas de alocação e decomposição de requisitos) (IEEE-STD-1471, 2000).
Finalmente é importante ressaltar o entendimento do que seja a arquitetura do sistema. Neste trabalho adotada-se a definição proposta no modelo ODP, onde:
Arquitetura: refere-se aos conceitos e regras que definem a estrutura, comportamento semântico e relacionamento entre partes de um sistema, podendo ser entendido como o planejamento de algo a ser construído. Essa definição inclui os elementos que compreendem as entidades do sistema, o relacionamento entre esses elementos, as restrições associadas a esses relacionamentos, focalizando as partes das entidades e focalizando as entidades como um todo (IS0-10746-2, 1995).
Essa definição de arquitetura, que compreende o software e o hardware do sistema, possibilita variados graus de abstração e de detalhamento, podendo a arquitetura representar uma parte ou o todo de um sistema. Assim, pode ser chamada de arquitetura do componente o inter-relacionamento (incluindo sua estrutura, comportamento semântico e restrições associadas) dos elementos que compõem esse
componente; a arquitetura de um subsistema pode ser o inter-relacionamento entre componentes que compõem este subsistema; a arquitetura de sistema pode ser o inter-relacionamento dos subsistemas que compõem esse sistema; e assim sucessivamente, permitindo uma visão hierárquica das diversas partes do sistema.
O resultado da aplicação dos processos de partição, alocação e decomposição de um sistema, representados na figura 2.3, é conhecido como projeto de arquitetura ou projeto de alto nível do sistema, que leva a uma definição da hierarquia até um certo nível de abstração, com a geração dos requisitos para todos os elementos e determinação das interfaces entre eles. Embora essa atividade seja chamada de projeto, a engenharia de requisitos está envolvida ao longo desse processo.
Assim, o desenvolvimento do projeto de arquitetura é um processo no qual os passos de análise de requisitos e projeto da arquitetura se alternam, com um detalhamento maior a cada iteração do ciclo de desenvolvimento. A saída da análise de requisitos é fornecida como entrada para a próxima fase de projeto, e a saída do projeto é utilizada como entrada da próxima fase de análise de requisitos.
Pode-se considerar que, no processo inicial de elicitação, os requisitos são inerentemente ambíguos, intuitivos e informais. Já o software é logicamente não intuitivo (por exemplo, é difícil de ser decifrado sem o conhecimento da sua linguagem) e deve ser interpretado pela máquina de uma forma não ambígua. A arquitetura do sistema pode ser considerada como a ponte semântica entre os requisitos e o software (ALLEMAN, 2000).
As ferramentas e métodos utilizados na engenharia de requisitos fornecem suporte a todos os aspectos de desenvolvimento do projeto da arquitetura (partição, alocação e decomposição), permitindo que os processos de análise de requisitos e desenvolvimento da arquitetura sejam integrados.
A qualidade dos sistemas de grande porte baseados em software são determinadas principalmente pelas características da arquitetura do sistema. Dessa forma, em sistemas de grande porte, a satisfação dos RNF podem depender mais da arquitetura global do sistema do que de boas práticas no nível de código (como
escolha de linguagem, detalhamento do projeto, algoritmos, estruturas de dados, testes, etc.). Assim, a elicitação e a análise dos RNF no início do processo de desenvolvimento são de extrema importância para a determinação da viabilidade e adequação da arquitetura ao sistema a ser desenvolvido. Entretanto, poucos trabalhos tem sido realizados para sistematizar técnicas que permitam extrair a descrição da arquitetura do sistema a partir da sua especificação de requisitos (VAN LAMSWEERDE, 2000).