Você desenvolve Requisitos, certo?

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.