Antes de mais nada lembre-se que isso é apenas uma simulação, o cliente não existe, só vou usar essa metodologia de simulação por achar que ajuda muito o aprendizado, mesmo sabendo que esse programa será usado depois no meu trabalho. 
A DESCOBERTA DA NECESSIDADE
Nós do blog Saberprogramar.com fomos contactados por uma empresa chamada “Tudo é Festa” (que desenvolve software) para fazer um sistema de controle de manutenção, a primeira coisa que pensamos foi, se eles desenvolvem porque não fazem? a resposta foi simples, estão enrolados demais com as manutenções por isso não consegue fazer nada novo.
Resolvemos aceitar este projeto, depois de 3 reuniões para analisar o processo, ver como eles trabalham e ter certeza que não vamos fazer mais do que estão pedindo (acredite, nós desenvolvedores normalmente fazemos mais do que pedem), chegamos a documentação a baixo.
Obs. Se não entender como dividimos o desenvolvimento deste projeto no artigo Ciclo de Desenvolvimento está bem detalhado para você não se perder, ok!
ANALISE DE REQUISITOS
Tipo de requisitos não funcionais ou Analise do Cliente
Quem é Cliente e Sua Estratégia → a empresa “Tudo é Festa” já existe no mercado a 10 anos, tem 50 clientes que usam seu único software de Automação comercial feito no Visual Basic 6.0 
, tem interesse em fazer coisas novas com novas ferramentas porém a prioridade da empresa hoje é manter os clientes dando-lhes um serviço mais customizado, ou seja, adicionando tudo que o cliente pede para ser colocado no sistema, assim agregando mais serviços e deixando os clientes mais dependentes do software, por isso um sistema de controle de manutenção, hoje a manutenção ocupa 90% das atividades da empresa. 
Recursos Humanos → a empresa possui 4 desenvolvedores Visual Basic 6.0 e esses mesmo programadores também dão suporte aos clientes quando necessário ( 2 em 1 ).
O que o Cliente espera com este projeto → “Tudo é festa” espera com este projeto que suas manutenções sejam feitas mais rápidas, que a empresa tenha um maior controle do inicio e fim das manutenções e quem fez, já que hoje a empresa não consegue visualizar essas informações de maneira rápida e sem confusão entre os programadores do tipo “Foi ele” ou “Eu não sei quem fez não”…
Tipo de Requisitos Funcionais ou Mini-Mundo
Projetos → é necessário ter um cadastro de projetos a qual ele faz manutenção, além do cadastro também é necessário a opção de alteração e exclusão (esse só autorizado se não tiver nenhuma atividade em aberto para este projeto).
Grupos → Foi também pedido pelo cliente um cadastro de Grupos para que possa dividir dentro dos projetos os grupos onde estará os projetos, por exemplo:
Projeto → Site Batata123
grupo → Layout
grupo → Programação
…
Também será necessário a opção de alteração e exclusão (exclusão só autorizada se não tiver nenhuma atividade em aberto para este grupo)
Atividades → As atividades é onde vai registrar as manutenções que tem que ser feita, uma atividade sempre estará ligada há um projeto e grupo, mais nem sempre terá um programador especifico, isso porque tem algumas alterações que qualquer um pode fazer, assim deixando aberto para o programador que estiver a possibilidade no momento. Outra coisa que foi pedido nas atividades é que tenha um status algo como:
Em aberto → assim qualquer programador que estiver disponivel possa pegar a atividade para fazer.
Encaminhado → para poder encaminhar para um programador especifico.
Finalizado → quando atividade é finalizada.
Também é necessário a opção de alteração e exclusão de atividades.
Programadores → um cadastro dos programadores que faram as atividades, mais atenção, precisa ter dois níveis, nível 1: onde ele vai visualizar suas atividades e as atividades abertas nível 2: onde o programador tem acesso também para cadastrar projetos, grupos e atividades, e também tenha a opção de alteração e exclusão dos cadastros.
Observação: Outra coisa indispensável pedida é que seja tudo online, para que todos os programadores tenham acesso de qualquer lugar.
ATENÇÃO! Este documento serve também como um contrato entre os desenvolvedores e o cliente, no final ambos concordando, assinando e anexando em um contrato faz com que seja feito exatamente isso, qualquer coisa fora disso seja um novo projeto, um novo valor.
Resumo do aprendizado
Vimos aqui uma análise de requisitos bem simples e compacta, alias, o problema também é simples e é para resolver de maneira simples. No próximo artigo estarei mostrando nosso UML, onde começaremos a ver essa descrição do negócio (análise de requisitos) de uma forma mais Orientada a Objetos. Uma coisa que vocês podem ter sentido falta é dos relatórios, realmente não terá por enquanto a pedido do cliente para baratear o projeto, porém se este projeto dá o retorno esperado pela empresa é possível que façam os relatórios depois em um novo projeto.
Fiquem a vontade para comentar e opinar sobre o desenvolvimento deste projeto, estamos apenas começando e espero contar com a ajuda dos leitores
Bem, até a próx. Com UML.
Vlw!!!
Popularity: 4% [?]
