Artefatos fundamentais para registro de requisitos

1. Relação das necessidades dos stakeholders

O artefato, relação das necessidades dos stakeholders, é o documento em que se devem relacionar as necessidades dos usuários do software. Nesse artefato estarão identificadas todas as necessidades definidas pelos usuários, com indicação dos seus respectivos perfis e contatos. As necessidades devem se relacionadas já pré-classificadas como: necessidades funcionais, necessidades não-funcionais, necessidades negociais (regras de negócio). Além dessa classificação, deve ser informado qual são os usuários gestores da necessidade apontada. Necessidades afins devem ser apresentadas de forma agrupada. É importante indicar a referência sobre a identificação da necessidade, tais como, a ata e a reunião em que foi identificada, por exemplo.

2. Relação das funcionalidades do software

A partir da relação das necessidades dos stakeholders a equipe de analistas de requisitos responsáveis pela construção do software fará a identificação das funcionalidades (requisitos funcionais) a partir das necessidades classificadas como funcionais que foram definidas pelos usuários. A relação das funcionalidades deve conter, além da identificação da funcionalidade propriamente dita, as necessidades funcionais as quais estão relacionadas.

3. Relação dos requisitos não-funcionais

Da mesma forma que o procedimento anterior, deverá ser feito à identificação dos requisitos não-funcionais, a partir das necessidades classificadas como não-funcionais que, também, foram definidas pelos usuários. Os requisitos não-funcionais deverão ser classificados e agrupados por categoria, segundo a relação abaixo: Requisitos de sistemas, requisitos de desempenho, requisitos de ambiente, requisitos de usabilidade, requisitos de confiabilidade, requisitos de suportabilidade, requisitos de segurança, requisitos de documentação. Oportunamente, falaremos sobre cada uma dessas classificações.

4. Diagrama geral de relacionamento entre casos de uso

A UML (Unified Modeling Language) nos ajuda a descrever os relacionamentos entre os casos de usos envolvidos no desenho do software. Para se definir esse diagrama, inicialmente, é necessário definir cada um dos casos de uso do sistema. Um caso de uso se resume num conjunto (agrupamento) de funcionalidades que serão desenvolvidas no software para resolver cada uma das necessidades levantadas. Cada caso de uso, deve ser ater as suas responsabilidades específicas e, pelos relacionamentos com outros casos de uso, compor o conjunto de funcionalidades necessárias para o bom funcionamento do software. A boa arquitetura de cada um desses casos de uso desenhados definirá uma boa arquitetura final para o software em questão.
No diagrama de relacionamento entre os casos de usos deverão estar representados os relacionamentos entre os atores e os ‘seus’ casos de uso e entre os casos de usos relacionados.

5. Relação das regras gerais e específicas dos casos de uso

Um outro artefato muito importante no processo de gerenciamento de requisitos é a relação de regras gerais e específicas dos casos de uso para o software. É comum, encontrarmos as regras específicas para os casos de uso descritas na própria especificação de caso de uso. Pessoalmente, eu não gosto muito desse agrupamento, pois na minha visão pessoal a especificação de caso de uso não deve ser apenas um documento de negócio é sim, um documento fundamental para o processo de construção do software incluindo-se nesse artefato conceitos relacionados a navegabilidade quando necessário. Claro que, quando se trata de um projeto complexo, podemos optar por construir o artefato especificação geral de interfaces e, quando necessário, pode-se ter também a especificação de interface de um determinado caso de uso. Desta feita, o que deve ser validado pelo usuário, segundo o meu ponto de vista, são as regras de negócio, tanto as especificas (que dizem respeito a um caso de uso específico) quanto as gerais (que dizem respeito a mais de um caso de uso). Prefiro que a validação de navegabilidade seja feita diretamente por intermédio de um protótipo medianamente funcional. As regras gerais ou especificas devem ser listadas com seus respectivos identificadores (código, nome reduzido, nome completo), teor da regra (contendo inclusive as operações aritméticas quando necessário e, conseqüentemente, exemplos que esclareçam o texto), identificação do stakeholder responsável pela definição da regra.

6. Matriz de rastreabilidade entre funcionalidades x necessidades x regras gerais x casos de uso

A matriz de rastreabilidade é um artefato muito importante nesse processo e um dos mais trabalhosos, em razão, da exigência de atualizações a que estará submetido. Qualquer alteração deverá ser registrada assim que consolidada. As rasteabilidades fundamentais são as que relacionam funcionalidades com necessidades; regras com funcionalidades e necessidades; casos de uso com funcionalidades e necessidades e regras com casos de uso. Existem muitas formas de se manter esse relacionamento, sendo a mais simples o registro em células de planilhas eletrônicas.

7. Especificação de caso de uso

A especificação de caso de uso pode ser um documento muito importante e de muita utilização no processo de construção de software ou apenas um artefato alegórico e que não ‘serve pra nada’. Eu prefiro, trabalhar com especificações que documentem realmente o software que está sendo desenvolvido. Portanto, deve-se evitar construir um caso de uso puramente negocial para se validado pelo usuário como, normalmente, vemos. É comum, construir especificação de caso de uso com a finalidade de fixar os requisitos junto aos usuários. Porém, como a linguagem adequada ao artefato não é fácil ao usuário comum, muitas vezes obriga-se o mesmo a se qualificar na linguagem. Em minha experiência, alguns usuários perdem-se em discutir a forma do documento (o que é fluxo alternativo, fluxo de exceção, entre outros) e não discute o teor das informações que são importantes para a construção do aplicativo. Por isso, eu opto por registrar as regras em documentos próprios e na especificação teremos apenas a navegabilidade, que deverá ser empregada no sistema (desenho dos processos dos casos de uso de uma determinada interface). Portanto, meu conceito de caso de uso é o de caso de uso de implementação e não apenas um documento negocial.
Essa especificação pode ser classificada em caso de uso comum e caso de uso CRUD [agrupamento dos processos básicos: Create (Inserir), Retrieve (Consulta), Update (Atualização) e Delete (Exclusão)]. Pode-se definir no CRUD outros processos além dos acima citados.
Uma especificação deve apresentar os seguintes fluxos:
Fluxo básico;
Sub-fluxos;
Fluxo alternativo;
Fluxo de exceção.

8. Projeto de interfaces

Um projeto de interfaces bem elaborado pode facilitar o processo de construção, além de reduzir o próprio tempo, em termos de cronograma, nessa fase. Os usuários, muitas vezes têm dificuldade em validar texto, uma interface com navegação básica, facilitará sobremaneira essa processo. Eu sempre opto por construir protótipos medianamente funcionais utilizando-me de HTML (Hiper Text Markup Language), quando se desenvolve um aplicativo que deverá obedecer a um determinado padrão de interface, o melhor já será incorporar partes desses padrões ao projeto. O tempo consumido na construção de um bom projeto de interface reduzindo o retrabalho com testes funcionais e de navegabilidade e, também, o retrabalho.