Vantagens da MUC

Uma prática comum de modelagem de requisitos, principalmente antes do advento dos UCs, consistia em listar os requisitos ou features (LAUESEN, 2002) a serem implementados pelo sistema (ROBERTSON, ROBERTSON, 1999) (ROBERTSON, ROBERTSON, 2006). Uma feature pode ser definida como uma afirmação de alto-nível sobre uma capacidade desejada para o sistema, em termos de funcionalidade ou algum atributo de qualidade (performance, segurança, etc.) (JACOBSON, NG, 2004). Por exemplo, a Lista de Requisitos (LRqs) para um sistema de hotelaria poderia incluir estes dois requisitos: (1) o sistema deverá ser capaz de colocar um quarto indisponível em um determinado período, para a realização de reparos; (2) o sistema deverá ser capaz de reservar quartos pelo seu tipo.

A literatura aponta pelo menos três vantagens da modelagem de requisitos com UCs (MUC) em relação à LRqs, relacionadas e discutidas a seguir:

1. Facilita a verificação de completude e consistência da especificação de requisitos;

2. Reduz o risco do sistema modelado não atender as reais necessidades dos stakeholders (LARMAN, 2004);

3. Facilita a rastreabilidade de requisitos entre os artefatos produzidos ao longo do desenvolvimento (KULAK, GUINEY, 2003).

A Figura 2.3 mostra as vantagens listadas anteriormente e a relação delas com algumas características também apontadas na MUC, servindo de pano de fundo para a análise que se segue.

Figura 2.3 – Características da MUC e vantagens em relação à LRqs

Existem diversos fatores de qualidade que devem estar presentes em uma especificação: completude, consistência, precisão, legibilidade, manutenibilidade, concisão, compreensibilidade, testabilidade, etc. Desses, a utilização de UCs em substituição (ou acréscimo) à Lista de Requisitos (LRqs) impacta mais diretamente a consistência, completude e rastreabilidade de requisitos, conforme indicado na Figura 2.3.

Uma especificação incompleta pode resultar em um sistema incapaz de atender todas as necessidades dos seus stakeholders, por não implementar algumas funções imprescindíveis a eles. Se uma especificação de requisitos é inconsistente, então ela possui pelo menos dois requisitos que não podem ser satisfeitos ao mesmo tempo, qualquer que seja a implementação do sistema. Trata-se de uma falha da especificação que, se não resolvida, pode igualmente impedir o sistema de satisfazer seus stakeholders.

No caso de uma LRqs extensa, é difícil avaliar se ela é consistente e completa. Também, é difícil para os stakeholders se certificarem de que seus objetivos de negócio serão efetivamente apoiados pelo sistema especificado na LRqs (LAUESEN, 2002). A raiz dessas dificuldades está na estruturação inexistente ou inadequada que esta abordagem de especificação promove. Diferentemente, na modelagem com UCs (MUC) os requisitos são estruturados segundo os usuários (atores) do futuro sistema, e principalmente, em torno dos objetivos desses atores e demais stakeholders. Cada UC mostra como o sistema deverá interagir com os atores para alcançar um objetivo de algum stakeholder. Enquanto que para a LRqs, o fundamental é responder “o que os usuários desejam que o sistema faça”, para a MUC é “quem vai usar o sistema, quais são seus objetivos ao fazer isso, e quais os cenários típicos dessa utilização” (WIEGERS, 2003) (LARMAN, 2004). A visibilidade dada aos objetivos dos stakeholders, e a estruturação dos requisitos segundo esses objetivos, contribuem para facilitar a verificação da consistência e completude da especificação, e a sua validação pelos stakeholders. Em conseqüência, essa característica especial da MUC também ajuda a reduzir o risco do sistema resultante não atender adequadamente as reais necessidades dos stakeholders.

Outra característica da MUC também é fundamental para propiciar a redução do risco do sistema especificado não satisfazer os stakeholders: o sentimento de familiaridade que ela desperta neles. Eles não se sentem intimidados ao serem apresentados à técnica de UCs (LARMAN, 2004). Isso ocorre por dois motivos principais. Primeiro, porque essa técnica é, na essência, um relato de estórias ou cenários de utilização do sistema pelos usuários (atores) que com ele interagem, e como tal, é percebida como simples e familiar por eles (KULAK, GUINEY, 2003). Além disso, ela emprega, pelo menos na forma mais comum, a linguagem natural para a descrição dos cenários (casos) de uso. Nas fases iniciais da modelagem, essa linguagem é utilizada sem maiores restrições ou elementos estruturantes e, portanto, não há necessidade de um treinamento extenso para capacitar os stakeholders a ler, ou mesmo escrever, versões iniciais (outlines) dos UCs. Isso tudo facilita e estimula o envolvimento dos mesmos na definição e revisão dos requisitos, o que ajuda a garantir a sintonia do sistema especificado com os anseios dos stakeholders.

A estruturação baseada nas necessidades dos stakeholders também tem efeitos benéficos sobre a rastreabilidade de requisitos entre os diversos artefatos produzidos ao

longo do ciclo de desenvolvimento de um sistema. Rastreabilidade de requisitos é a capacidade de se descrever e acompanhar a vida de um requisito, tanto na direção da sua implementação no sistema (forward traceability), quanto na direção de sua origem (backward traceability) (PINHEIRO, 2004). Segundo KULAK, GUINEY (2003), UCs são rastreáveis, pois as estórias contidas neles são mapeadas naturalmente em artefatos de análise, projeto e testes, enquanto que a LRqs não tem rastreabilidade nesses artefatos. Na nossa visão, o foco nos stakeholders e em seus objetivos, promovido pelos UCs, fez com que o modelo de UCs se tornasse o artefato central do ciclo de desenvolvimento de um sistema, referenciado e utilizado em todas as fases desse ciclo (Figura 2.4, traduzida de (JACOBSON, 2004)).

Figura 2.4 – UC como artefato central para o desenvolvimento

Durante as fases de análise e projeto do sistema, cada UC tem o comportamento modelado através da colaboração entre classes de objetos. Na fase de testes, cada UC resulta em um conjunto de casos de teste. Os UCs também são importantes para o projeto da interface com o usuário e na estruturação do manual do usuário. Por fim, eles também se inserem na modelagem de negócio, uma vez que são capazes de capturar processos de negócio (JACOBSON, 2004). Portanto, diferentemente do que acontece quando os requisitos são modelados na forma de uma LRqs, o artefato central do desenvolvimento é o caso de uso, e não um artefato de análise ou de projeto. Essa “promoção” do artefato de requisitos significa o encurtamento da distância representacional entre ele e os demais artefatos produzidos nas fases posteriores do desenvolvimento. Embora isso não dispense o tratamento específico usualmente dado

para se garantir uma adequada produção, captura e extração de rastros (PINHEIRO, 2004), o rastreamento de requisitos entre os artefatos tende a ficar facilitado.

A despeito das vantagens acima apresentadas da modelagem de requisitos utilizando UCs, é preciso reconhecer que, muitas vezes, os desenvolvedores (por exemplo, em fábricas de software) recebem uma LRqs pronta e, antes de mais nada, precisam validá-la. Embora essa validação possa ser feita elaborando-se o modelo de UCs do sistema pretendido, isso é custoso, principalmente se a qualidade da LRqs for baixa. Nesse caso, é preciso uma validação preliminar e expedita dessa lista, que pode ser feita, por exemplo, através de um processo de revisão ou inspeção (HE et al., 2008). A partir daí, durante a modelagem com UCs essa validação é retomada, e de forma mais efetiva, pois agora a compreensão do problema é maior, tanto por parte dos desenvolvedores quanto dos stakeholders.