Faltam 0 dias! Inscreva-se agora! O maior encontro de profissionais web da américa latina.

Os requisitos não vieram de hoje, a sua necessidade já foi confirmada há muito tempo, mas ainda é comum ver empresas que falam aos quatro ventos que trabalham com requisitos e, na verdade, não sabem diferenciar um requisito de uma Constraint.

Hoje vou falar mais de requisitos, dizendo o que são e o que não são requisitos, bem como qual a relação deles com as Constraints. Pretendo falar um pouco mais dos tipos de requisitos e quanto tempo devemos gastar com eles.

O que é um Requisito?

Um requisito tem que atender a duas premissas básicas, se você não atender a essas duas premissas, logo você não tem um requisito. Vamos então:

• Condição ou capacidade necessitada pelo usuário para realizar algum objetivo ou resolver algum problema. E o mais importante Desejado.
• O usuário tem que poder perceber, ou seja, Observado Externamente.

Se não satisfaz esses itens acima, não é um requisito. Infelizmente muitos analistas nem sabem o que é isso. Muitos vieram do velho modelo em que o analista de Sistemas era o "cara" e hoje em dia não é mais, alguns consideram que ele perdeu seu papel.

Os Requisitos não estão na sua cara...

Levantar requisitos não significa ouvir o usuário, não é simples assim. Na verdade você tem que descobrir o que o usuário deseja de verdade, e isso não é fácil. Existem algumas técnicas para você fazer isso, pretendo falar disso em outros artigos.

Muitas vezes o cliente não tem tempo para fornecer as informações necessárias ao analista de Requisitos, isso acontece mais ainda quando a sua empresa é de TI e o seu cliente não é de TI, em empresas onde existe um equipe de TI interna é mais fácil obter informações dos usuário.

Não é fácil levantar requisitos e um requisito mal levantando gera muita dor de cabeça e custos adicionais no futuro. Neste caso, se você trabalha em um equipe de TI interna, isso gera mais stress, agora se você está em uma empresa de TI e o seu cliente não é de TI, e você está em escopo fechado, em termos de custo não é um problema para sua empresa, mas para o cliente sim, isso ocorrendo com muita freqüência pode levar ao fracasso do projeto.

E não adianta ficar só reclamando do cliente, ele pode não colaborar 100% e ajudar na elicitação, logo seus requisitos seriam bem vagos, mas seu software terá que ser especifico e detalhado, logo é bom gastar o tempo suficiente nesta tarefa mesmo que isso signifique educar o cliente.

O Analista não tem que ser Técnico...

O Caramba!!! É comum ver por aí o pensamento de que só quem é desenvolvedor tem que ser técnico, como se o o gerente e analistas não precisassem ser técnicos. O Gerente tem que ser técnico em gestão, assim como o analista de Requisitos tem que ser técnico em Requisitos.

Ser técnico, nestes dois casos, significa conhecer práticas, técnicas, métodos, padrões, etc... Isso tudo não vem só com a prática, você precisa de estudo. Só estudando é possível obter essas coisas. Mas só com a prática que você aprende a usá-las da forma correta.

Requisitos não são a solução

Você não usa requisitos para definir a solução, ou seja, vai ser em Java, vou usar MVC básico e tudo vai rodar no JBoss 5. Se existem essas questões que falei agora, elas são tratadas como restrições e não requisitos, logo elas devem ser mapeadas como Constraints. Para poder lidar bem com essas questões junto com os requisitos, falando de gestão de requisitos, é necessária uma boa ferramenta de requisitos.

Requisitos como centro de tudo

Métodos de desenvolvimento de software como RUP e OpenUP são focados em requisitos através de Casos de uso. Utilizam casos de uso porque casos de uso são bons para representar a perspectiva do usuário e favorecem um contexto muito bom. O TOGAF, que é um método de Arquitetura Corporativa, também é focado em requisitos, tanto para o TOGAF como para o RUP/OpenUP a Arquitetura é construída a partir do Requisitos.

Arquitetura de Software que é construída sem requisitos não é arquitetura. Em projetos pequenos essa abordagem errante pode funcionar em alguns casos. Mas casos de projetos mais complexos podem gerar muitos problemas e, até mesmo, o fracasso do projeto.

Telas são importantes, bem como boas amigas aliadas as técnicas de prototipação para ajudar a validar e considerar informações com o usuário, mas telas e botões são solução, e não são requisitos.

Requisitos nunca são perfeitos, e não existe um tempo certo pré-determinado para ser gasto com isso. Se você trabalha de forma iterativa incremental. essa questão não é um problema, mas em um projeto de escopo fechado, com tempo e recursos fechados, isso pode ser um problema.

Tipos de Requisitos

Existem os dois tipos clássicos de requisitos que são os Funcionais e os Não-Funcionais. Os requisitos Funcionais são específicos dos produtos, ou seja, se referem ao que o sistema deve fazer, em termos de funcionalidades, para o negócio do seu cliente. Já os requisitos Não-Funcionais são as qualidades que o seu produto deve ter, ou seja, quanto tempo é aceitável para dar retorno ao usuário em uma consulta, qual a disponibilidade mínima do sistema, entre outras questões.

Outro tipo de requisito é o requisito Candidato, este tipo pode ser utilizado no processo de elicitação de requisitos, você pode tratar primeiramente todos os seus requisitos como candidatos e tempos da validação e aceite do cliente ele vira um requisito de fato.

Requisitos de Usabilidade, quase ninguém usa ou sabe o que são. Assim como a preocupação com usabilidade é quase nula nos sistemas que existem por aí. Existem vários outros tipos, inclusive existem diversos padrões de requisitos como por exemplo: Estrutura de Dados, Aprovação, Avaliabilidade, Relatórios, etc... Se você quiser saber mais sobre esses padrões, pode conferir este livro: Software Requirement Patterns.

Fechando...

Análise, Desenvolvimento e Gestão de Requisitos são necessidades nas empresas que querem ter sucesso. Isso é válido independentemente da tecnologia e da metodologia de sua empresa. Requisitos não significam burocracia ou página de MS Word sem valor, mas sim o que o sistema deve fazer e o que o cliente precisa.

Para isso é necessário analistas de requisitos com capacitação para o mesmo. Essa capacitação não vem só com a prática. Precisamos aliar os estudos à prática. Levantar requisitos não é fácil e não se aprende a fazer isso apenas ouvindo o usuário, é preciso se perguntar os porquês das coisas.

Abraços e até a próxima.