Lalo de Almeida/The New York Times
Alguns podem pensar "pé sujo". Outros podem pensar "original".
Tá, o que isso tem a ver com requisitos? Devo levar o cliente para o bar e embebedá-lo antes das reuniões?
É uma tática eficaz, mas um tanto anti-ética. Ao invés disso, peço que pense no bar do ponto de vista funcional. O que o cliente espera de um bar? Resumidamente, que venda bebidas. Mas apenas vendê-las é suficiente para satisfazer o cliente? Não.
Trazendo a analogia para software, apenas atender as necessidades funcionais do cliente não basta. É preciso levar em conta características que tornem o seu software em algo agradável de se usar.
Invista tempo nas fases iniciais do projeto para conversar com o patrocinador e os futuros usuários do sistema sobre o que eles esperam de um bom software. Tente obter pistas sobre experiências passadas em outros projetos softwares. O que eles gostaram, o que eles não gostaram, características que eles consideram interessantes e defeitos irritantes. Não é díficil, basta dar abertura. Se tem uma coisa que quase todo mundo gosta, é reclamar do trabalho. Ignorar essas questões pode ter um impacto muito alto no sucesso de um projeto.
Então, preste atenção nos requisitos não-funcionais. Pode significar a diferença entre um software que acumula poeira nos confins de um HD ou um contrato de manutenção evolutiva.
