Análise de Requisitos

A investigação do domínio do problema e do negócio a ser apoiado nos leva a perceber que o desenvolvimento de um novo sistema de informação é um agente de mudanças no negócio e na prática dos profissionais envolvidos. Podemos pensar que estamos diante de duas versões de um sistema: o sistema como ele é (as-is) e o sistema que se pretende obter (to-be). Note que quando falamos do sistema neste contexto não estamos falando de um sistema computacional, mas sim de sistema em uma acepção mais geral da palavra: um conjunto intelectualmente organizado de elementos (pessoas, produtos de software, dispositivos etc.). O sistema as-is apresenta problemas, limitações e deficiências. O sistema to-be tem a intenção de tratar esses problemas usando oportunidades oferecidas pela tecnologia. Assim, para que o sistema to-be seja bem-sucedido, o sistema de software a ser desenvolvido (software to-be) precisa cooperar efetivamente com seu ambiente (pessoas, dispositivos e outros sistemas de software existentes). Assim, podemos estruturar o trabalho de ER em termos de três dimensões, como mostra a Figura 4.1 (LAMSWEERDE, 2009):

Figura 4.1 – As dimensões da ER (adaptado de (LAMSWEERDE, 2009)).

• Por quê? As razões para se desenvolver um novo sistema computacional (software

to-be) devem ser explicitadas em termos de objetivos a serem satisfeitos.

• O que? Esta dimensão preocupa-se com os serviços (requisitos funcionais) que o novo sistema computacional deve prover para satisfazer os objetivos. Esses serviços devem satisfazer restrições (requisitos não funcionais), garantir regras de negócio e apoiam-se em suposições.

Problemas, Oportunidades, Conhecimento de

Domínio

Sistema as-is Sistema to-be Dimensões Objetivos

Serviços, Restrições, Regras de Negócio,

Suposições satisfaz

Software to-be Pessoas Dispositivos Software Existente Ambiente

Por quê?

O que?

• Quem? Alguns serviços serão implementados pelo software to-be, enquanto outros serão realizados por procedimentos manuais, operações de dispositivos ou por outros produtos de software já existentes.

Para responder a essas perguntas, é necessário um entendimento mais profundo do domínio do problema, do negócio a ser apoiado, das limitações do sistema atual e dos requisitos para o novo sistema. Requisitos de cliente são insuficientes para isso. Eles resultam diretamente da atividade de levantamento de requisitos, sendo tipicamente descritos em linguagem natural, em um baixo nível de detalhes. Assim, uma vez identificados os requisitos de cliente, é necessário detalhá-los, colocando-os no nível de descrição de requisitos de sistema. Este é o propósito da Análise de Requisitos.

Requisitos de sistema resultam dos esforços dos analistas de organizar e detalhar requisitos de cliente, envolvendo a elaboração de um conjunto de modelos abstratos do sistema, agora em um nível alto de detalhes. A correta derivação de requisitos de sistema a partir de requisitos de cliente é fundamental para assegurar que equívocos não serão arbitrariamente introduzidos pelos engenheiros de requisitos na especificação de requisitos (AURUM; WOHLIN, 2005). Durante a análise de requisitos, requisitos funcionais e não funcionais devem ser expressos em um nível de detalhes que permita guiar as etapas subsequentes do desenvolvimento de software (projeto, implementação e testes). Além disso, atenção especial deve ser dada às regras de negócio. Elas têm de ser capturadas e incorporadas às funcionalidades do sistema. Neste contexto, vale destacar que a aplicação de técnicas de levantamento de requisitos é imprescindível e, portanto, o levantamento detalhado de requisitos ocorre em paralelo com a análise de requisitos.

Para descrever requisitos funcionais detalhadamente, é necessário produzir modelos, cada um deles capturando uma perspectiva diferente do sistema. A linguagem natural ainda é utilizada, mas em uma escala reduzida, circunscrita a descrições de certos modelos ou às definições em glossários ou dicionários de dados. Grande parte das informações tratadas na análise de requisitos funcionais é melhor comunicada por meio de diagramas do que por meio de texto. Assim, a modelagem é uma atividade essencial da análise de requisitos.

A modelagem de objetivos pode ser empregada para tratar a dimensão “Por quê?”. Um modelo de objetivo procura capturar precisamente os objetivos a serem satisfeitos pelo sistema

to-be, suas ramificações em termos de subobjetivos, como esses objetivos interagem (conflitos

e sinergias) e como eles estão alinhados a objetivos de negócio (LAMSWEERDE, 2009). A modelagem conceitual visa definir em detalhes as funções requeridas pelo sistema e o conhecimento necessário para realizá-las. O produto principal da modelagem conceitual é o esquema conceitual do sistema (OLIVÉ, 2007). O esquema ou modelo conceitual3 de um sistema captura as funções e informações que o sistema deve prover e gerenciar. Ele deve ser concebido com foco no domínio do problema e não no domínio da solução, mas deve tratar tanto uma visão externa do sistema (como o sistema é percebido pelos usuários) quanto uma visão interna do mesmo (como as abstrações do domínio são representadas e relacionadas).

3 Olivé (2007) utiliza o termo “esquema conceitual” para designar o conjunto de artefatos que capturam o conhecimento que um sistema de informação necessita para realizar suas funções. Contudo, a maioria dos textos, tais como (WAZLAWICK, 2004) e (BLAHA; RUMBAUGH, 2006), utiliza o termo “modelo conceitual” para designar esse conjunto de artefatos. Olivé utiliza o termo “modelo conceitual” para designar tipos de modelos, tais como modelos de objetos, modelos de casos de uso etc. Nestas notas de aula, o termo “modelo conceitual” é usado como na maioria dos textos, não sendo feita uma distinção precisa entre as duas acepções do termo. De maneira geral, o contexto indica a que se refere o termo.

Os termos análise de sistemas e análise de requisitos são muitas vezes empregados para designar as atividades de modelagem conceitual (análise de requisitos funcionais). Assim, a maioria dos métodos de análise de sistemas concentra-se na análise de requisitos funcionais, nada falando sobre a análise de requisitos não funcionais. Entretanto, durante a atividade de análise de requisitos, tanto requisitos funcionais quanto requisitos não funcionais devem ser especificados em detalhes.

O produto de trabalho principal da análise de requisitos é o Documento de Especificação de Requisitos. Esse documento deve conter os requisitos funcionais e não funcionais descritos em nível de requisitos de sistema. Conforme citado anteriormente, os requisitos funcionais de sistema são descritos por um conjunto de modelos inter-relacionados. Os requisitos não funcionais de sistema detalham os requisitos não funcionais de usuário, adicionando a eles critérios de aceitação.

É importante apontar que há uma forte dependência entre os métodos e técnicas usados na modelagem conceitual e o paradigma de desenvolvimento adotado. Isso ocorre porque um modelo é uma representação do sistema segundo um particular metamodelo. Esse metamodelo corresponde ao conjunto de elementos de modelagem (estruturais e comportamentais) e regras de uso desses elementos, o qual permite construir modelos segundo o respectivo paradigma (AURUM; WOHLIN, 2005). Assim, para a modelagem conceitual de requisitos funcionais é necessário escolher um paradigma de desenvolvimento (e o correspondente metamodelo subjacente a ele) a partir do qual os modelos serão construídos. O paradigma orientado a objetos, por exemplo, fornece um conjunto de elementos de modelagem que permite modelar um sistema como sendo composto de objetos organizados em classes que se comunicam entre si por meio de troca de mensagens. Uma classe define as propriedades (atributos, relacionamentos e operações) que todos os objetos dela podem possuir. Assim, classes, objetos, associações, atributos e operações, dentre outros, são elementos do metamodelo subjacente ao paradigma orientado a objetos. Neste texto, o paradigma adotado é o da orientação a objetos.

Uma vez que a modelagem conceitual é uma tarefa essencial e complexa, é útil seguir um método. Um método pode ser visto como uma maneira sistemática de trabalhar para se obter um resultado desejado (PASTOR; MOLINA, 2007). Há diversos métodos de análise orientada a objetos propostos na literatura, dentre eles os apresentados em (LARMAN, 2007), (WAZLAWICK, 2004)4, (BLAHA; RUMBAUGH, 2006) e (PASTOR; MOLINA, 2007). Vale ressaltar que não há um método reconhecido como um método padrão para o desenvolvimento de software orientado a objetos. Diferentes projetos podem requerer diferentes processos e, portanto, não há como definir um método adequado a quaisquer situações. Neste capítulo é apresentado um método que incorpora ideias de vários métodos, o qual tem se mostrado eficaz na prática, sobretudo, no desenvolvimento de sistemas de informação.

Este capítulo trata da análise de requisitos, discutindo a análise de objetivos, requisitos funcionais (modelagem conceitual) e não funcionais. A Seção 4.1 discute a análise de objetivos. A Seção 4.2 discute a modelagem conceitual com foco em sistemas de informação e os tipos de modelos comumente utilizados no desenvolvimento de software orientado a objetos. A Seção 4.3 apresenta a Linguagem de Modelagem Unificada (Unified Modeling Language – UML), amplamente usada na modelagem conceitual. A Seção 4.4 apresenta o método de análise de requisitos funcionais sugerido, indicando suas atividades e modelos a serem produzidos. A

4 O método apresentado em (WAZLAWICK, 2004) é, segundo o próprio autor, “uma interpretação e um detalhamento do método de análise e projeto apresentado por Larman”.

Seção 4.5 trata da especificação de requisitos não funcionais. Finalmente, a Seção 4.6 discute a documentação de requisitos em nível de sistema.