Blog: O recomeço!

Reza a lenda que vinhos melhoram ao longo do tempo e eu acho que agora me sinto maduro o bastante para escrever algo relevante neste cyberespaço chamado blog.

Espero ter a oportunidade de escrever, semanalmente, sobre alguma atualidade da área de TI, negócios e afins, ou, algo que seja realmente relevante de ser compartilhado.

O texto que segue a seguir é o resultado de um trabalho que tive de fazer para o MBA e aborda ....

leiam e dêem vossas sinceras opiniões.

Os profissionais da área de desenvolvimento de software já devem, em algum momento de sua formação, ter se deparado com a disciplina de Engenharia de Requisitos.

Termos como Matriz de Rastreabilidade, Casos de Uso, Requisitos de Negócio e de Usuário, entre outros, soam com certa familiaridade para alguns e, mesmo sabendo da importância de se escrever bons requisitos, é fato que muitos projetos são guiados por pessoas que possuem pouco (ou nenhum) conhecimento em tais conceitos.

A partir da quarta edição do PMBok (2008), a área de Requisitos foi explicitamente incorporada no que pode ser considerada a “bíblia da gestão de projetos”.

Visando auxiliar aos gerentes, de diferentes tipos de projetos, este texto tem por objetivo abordar formas de se descrever bons requisitos. Mas, afinal, o que é Requisito?

Requisito pode ser descrito como sendo uma condição ou capacidade necessitada por uma entidade para resolver um problema ou alcançar um objetivo.

Em um contexto de projeto, requisitos são necessidades de stakeholders (envolvidos) que devem ser atendidas em prol da obtenção dos resultados esperados para o produto/serviço que será desenvolvido.

É consenso entre os especialistas que, um bom requisito especifica algo que é necessário, verificável e atingível, de forma clara.

Existem situações onde um requisito pode ser bem escrito e atingível, porém, se não for necessário, não deve ser considerado. Se o mesmo não puder ser avaliado, analisado ou demonstrado em decorrência de uma descrição subjetiva, ele será caracterizado como não verificável e, caso não seja atingível, nem deve ser escrito.

Quais seriam os problemas comumente encontrados na descrição de requisitos?

• Realizar pressupostos (assumptions) incorretos;
• Descrever o Escopo da Solução (O como?) ao invés do Escopo do Problema (O que?);
• Descrever operações ao invés de descrever requisitos;
• Utilizar termos incorretos;
• Não descrever de forma estruturada os requisitos ou utilizar termos gramaticais ruins;
• Esquecer requisitos; e
• Descrever informações em excesso.

Especificações de requisitos com qualidade são caracterizadas por serem completas (as informações são organizadas estruturalmente), consistentes (não há requisitos conflitantes), modificáveis (mudanças nos requisitos não devem ser onerosas) e rastreáveis (os requisitos devem ser ligados aos produtos/serviços do projeto).

Não há um formato universal para a descrição de bons requisitos, normalmente eles surgem de uma mistura de experiência e estudo de requisitos que foram problemas no passado. Abaixo, segue uma estrutura proposta por Karl E. Wiegers para a descrição e documentação de bons requisitos.

1. Mantenha frases e parágrafos curtos. Utilize a voz ativa. Utilize a gramática apropriada, a correta ortografia e pontuação. Utilize termos consistentes e os defina em um glossário.
2. Para saber se a declaração de um requisito está bem definida, leia-a sobre a perspectiva de que irá interpretá-la.
3. Autores de requisito lutam para encontrar o nível ideal de granularidade.
4. Evite utilizar uma narrativa com longos parágrafos que contenham múltiplos requisitos.
5. Descreva requisitos concisos ao longo da documentação.Evite a redundância de requisitos ao longo da criação e manutenção de requisitos.

Por hora é isso.

Aguardo comentários e até a próxima.