Você desenvolve Requisitos, certo?
Os requisitos não vieram de hoje, a sua necessidade já foi confirmada a muito tempo, mas ainda é comum ver empresas que falam aos 4 ventos que trabalham com requisitos e na verdade não sabem diferenciar um requisito de uma Constraint.
Neste post 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 requisitos.
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:
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 fazer isso em outros posts.
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ê esta em um empresa 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 tera 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 ai o pensamento de que só quem é desenvolvedor tem que ser técnico, como se o o gerente e analistas não precisam ser técnicos. O Gerente tem que ser técnico em gestão e bem 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 que você obtém essas coisas, mas só com a prática que você aprende a usar 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ário 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 por que 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 em outros casos de projetos mais complexos pode gerar o muitos problemas e até mesmo o fracasso do projeto.
Telas são importantes, bem como boas amigas aliada 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 pre determinado para ser gasto com isso, se você trabalha de forma iterativa incremental essa questão não é um problema, agora 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 produto, ou seja, se referem a o que o sistema deve fazer em termos de funcionalidades para o negocio 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 facto.
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 ai. 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...
Analise, Desenvolvimento e Gestão de Requisitos é uma necessidade nas empresas que querem ter sucesso, isso é valido independente da tecnologia e 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, logo precisamos aliar os estudos a prática. Levantar requisitos não é fácil e não se aprende a fazer isso apénas ouvindo o usuário, tem que se perguntar os porques das coisas.
Abraços e até a próxima.
Neste post 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 requisitos.
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.
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 fazer isso em outros posts.
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ê esta em um empresa 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 tera 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 ai o pensamento de que só quem é desenvolvedor tem que ser técnico, como se o o gerente e analistas não precisam ser técnicos. O Gerente tem que ser técnico em gestão e bem 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 que você obtém essas coisas, mas só com a prática que você aprende a usar 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ário 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 por que 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 em outros casos de projetos mais complexos pode gerar o muitos problemas e até mesmo o fracasso do projeto.
Telas são importantes, bem como boas amigas aliada 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 pre determinado para ser gasto com isso, se você trabalha de forma iterativa incremental essa questão não é um problema, agora 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 produto, ou seja, se referem a o que o sistema deve fazer em termos de funcionalidades para o negocio 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 facto.
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 ai. 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...
Analise, Desenvolvimento e Gestão de Requisitos é uma necessidade nas empresas que querem ter sucesso, isso é valido independente da tecnologia e 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, logo precisamos aliar os estudos a prática. Levantar requisitos não é fácil e não se aprende a fazer isso apénas ouvindo o usuário, tem que se perguntar os porques das coisas.
Abraços e até a próxima.
