Estruturando Requisitos – Parte 2

No artigo anterior vimos a estruturação de requisitos em 4 níveis (ou tipos). Hoje mergulharemos um pouco mais no desenho, mostrando atributos que devem caracterizar todos os requisitos. Para isso vamos pegar todos os tipos de requisitos…

… e tratá-los como uma coisa (!) só:

Apresentarei os atributos em sentido anti-horário, começando pelo Tipo. O Tipo aparece aqui apenas para fins ilustrativos. A informação já apareceu no diagrama anterior. Um requisito sempre terá um dos seguintes tipos:

• Um objetivo do Negócio;
• Objetivos ou metas mais específicos, atribuídos a um único processo de negócio;
• Um requisito do Usuário;
• Um requisito Funcional; ou
• Um requisito Não-funcional.

Todo requisito possui uma única Fonte. Trata-se da pessoa que manifestou aquela necessidade. Em alguns casos bastará o registro do nome. Outros podem preferir uma ficha mais completa, com cargo, departamento, formas de contato etc. De qualquer maneira, o Ponto de Vista desta pessoa deve ser registrado em separado. É uma informação que ajuda muito no processo de tomadas de decisão sobre o escopo do projeto, por exemplo. No nível mais simples e genérico, o Ponto de Vista pode ser:

• Estratégico: é o dono do negócio, ou a alta direção. Desnecessário dizer que, na maior parte das vezes, seus requisitos têm um peso consideravelmente maior que os demais.
• Tático: é um gerente, coordenador ou supervisor. Ou seja, todo o escalão que fica entre a alta direção e o pessoal
• Operacional: que é quem realmente executa o trabalho. É interessante alertar que, dependendo do projeto, esses três níveis podem ser usuários do sistema. Esta delimitação aparecerá de maneira mais clara nos Casos de Uso. Além deles há também um 4º ponto de vista, o
• Técnico: que pode representar, por exemplo, o pessoal de TI da empresa. Neste caso, eles são a origem de muitos requisitos não-funcionais. Sobre arquitetura tecnológica, por exemplo.

Não é bom confundir a estrutura com o processo de desenvolvimento dos requisitos, mas aqui cabe uma exceção. É muito importante que, no momento do registro de um requisito, a Fonte indique qual é o Grau de Importância que ela lhe atribui. Neste ponto estamos distantes do processo de priorização, mas esta informação será de muita relevância lá e em várias outras decisões tomadas pela equipe no decorrer de um projeto. Por isso é importante que esta classificação seja simples e objetiva:

• Fundamental: ou seja, o projeto será considerado falho se este requisito não for atendido. Soou um tanto “dramático” mas é assim mesmo que estes requisitos devem ser vistos: cruciais para o sucesso do projeto.
• Importante: o cliente não abre mão da implementação deste requisito, mas saberá aguardar sua satisfação caso o projeto enfrente algum problema ou se surgirem outros requisitos Fundamentais no meio do caminho.
• Opcional (ou Acessório): como o próprio nome indica, a não satisfação deste requisito não comprometerá em nada o projeto. São os tradicionais “badulaques” (ou “perfumaria”) que devem ser relegados para quinto plano (dos infernos) tão logo o projeto tenha seus prazos desafiados. Falando sério: há um lugar muito nobre para requisitos não satisfeitos. Uma seção do documento de visão chamada “Idéias para Versões Futuras”.

Os dois últimos atributos, ao contrário dos anteriores, nascerão ou serão amadurecidos em momentos posteriores ao registro do requisito. O primeiro deles é o auto-relacionamento entre os requisitos (representado pela elipse no canto inferior direito da classe Requisito no diagrama acima). Faz parte da análise de requisitos, além da validação de sua acuracidade, o “confronto” com outros requisitos. Existem 4 tipos de relacionamentos possíveis:

• Dependência: por exemplo, “a satisfação do requisito ‘A’ depende da satisfação do requisito ‘B'”. Esta relação pode ser descoberta bem cedo no ciclo de um projeto, mas é mais comum que ela só seja percebida no momento do desenho da solução.
• Complementariedade (ou Facilitação): “a satisfação do requisito ‘A’ é facilitada pela satisfação anterior do requisito ‘B'”. Na relação de dependência, se o requisito ‘B’ não for satisfeito, torna-se impossível a realização do requisito ‘A’. Aqui apenas indicamos que se o requisito ‘B’ for atendido antes, a satisfação do requisito ‘A’ é facilitada. No entanto, em ambos os casos estamos indicando claramente uma seqüência de desenvolvimento.
• Substituição: pois é, assim registramos uma mudança. Afinal, uma mudança nada mais é do que um requisito “atrasado”. É uma boa prática a decisão de nunca “deletar” um requisito. Assim mantemos todo o histórico de um projeto. Por isso é necessário que registremos toda e qualquer alteração sofrida por um requisito como um novo requisito, que *substitui* o anterior.
• Conflito: sendo direto, “a satisfação do requisito ‘A’ impede a realização do requisito ‘B'”. Ou seja, é obrigatória uma tomada de decisão: qual requisito será excluído do escopo do projeto? É o primeiro ponto em que a informação sobre o Ponto de Vista da Fonte do requisito pode ser útil: qual pesa mais? A exemplo dos demais tipos de relacionamentos, as vezes um Conflito só é detectado em estágios avançados do projeto. No entanto, assim como os riscos e bugs, quanto antes eles forem identificados, melhor. Aliás, ele é um bug!

Por fim temos o Status do requisito. Registramos aqui o seu ciclo de vida. Todos nascem com o estado “Pendente”. Após um primeiro ciclo de validação eles são “Aprovados” ou “Recusados”. Os “Aprovados”, no decorrer do projeto, podem assumir 1 de 3 estados possíveis: “Substituído”, “Excluído” ou “Implementado”. Nos dois primeiros encerrou-se o ciclo. Aos “Implementados” falta um último estado: “Verificado”. Consideramos que todos os requisitos marcados como “Veficados” estão devidamente satisfeitos. Esta seqüência pode ser estendida, para contemplar eventos e resultados de testes, por exemplo.

.:.

Assim encerramos o “básico do básico” sobre estruturação de requisitos. Estranho, mas se trata de um “básico” que raramente percebemos em projetos e até mesmo nas ferramentas utilizadas para o gerenciamento de projetos (ou de requisitos).Sim, a estruturação proposta resulta em um grande volume de informações. Mas, na realidade, o que ela faz é nos dar a exata noção da quantidade de informações que lidamos ao desenvolver e gerenciar requisitos. Tais informações já existem em qualquer projeto. A diferença aqui é que elas não ficam “soltas”. Não há burocracia nem redundância. Os modelos propostos consideraram apenas as informações mínimas necessárias para uma correta e precisa engenharia de requisitos.

Encerrei o artigo anterior prometendo falar sobre análise e rastreabilidade dos requisitos. A análise, apesar de não explicitamente descrita, está na apresentação de todos os atributos dos requisitos. O registro de cada um deles é resultado da análise. Aliás, isso é Análise de Requisitos.

Já a rastreabilidade ficou implícita, escondida nos dois diagramas apresentados. Imaginando os modelos como uma base de dados, não é fácil perceber como podemos “rastrear” os requisitos “na vertical e na horizontal”? Um breve checklist (surrupiado do SEI – Software Engineering Institute):

• Qual meta ou objetivo de negócio é atendido pelo requisito?
• Este requisito é realmente necessário?
• Como eu devo interpretar este requisito?
• Quais decisões de projeto afetam a satisfação deste requisito?
• Qual teste de aceitação será utilizado para validar o requisito?
• Qual o impacto gerado pela mudança deste requisito?
• Todos os requisitos foram atendidos?
• O projeto acabou??

Para encerrar, uma provocação (sem ironia) ao amigo agilista. Saca só o segundo diagrama. Troque “Requisito” por “User Story”. E se usarmos as cores dos post-its para diferenciar os tipos de requisitos? Fica bem legal, não acha?