1. Analisar Dados
2. Entender Risco
3. Dominar Robótica
4. Garantir a Segurança da Informação
5. Gerenciar a Rede

Desses, alguns chamam mais a atenção, e neste caso acho que são os itens 2 e 3, entender risco é uma coisa fundamental, essa é uma daquelas partes da TI em que o analista se aproxima mais do administrador de empresas, é uma habilidade mais relacionada ao negócio do que à técnica, no entanto, mesmo no desenvolvimento de sistemas temos que estar cientes das modificações que fazemos e entender os riscos disso. Risco não está relacionado apenas a problemas catastróficos ou eventos de desastre que podem ocorrer, podemos pensar também em quando não atingimos um prazo e temos que pagar uma multa, ou se o desenvolvedor chefe da equipe sofre um acidente e precisa ficar fora por um tempo.

Já a robótica é um assunto que me interessa muito! Isso pode ser visto pela quantidade de posts que coloco aqui sobre robôs. É fato que nós não temos mais como pensar em não conviver com os robôs, mas o profissional de TI deve saber como usá-los como ferramentas, e como programá-los também. As soluções do futuro vão contar com requisitos de robótica, e portanto devemos nos preparar para poder colocar robôs nas arquiteturas de sistemas e soluções propostas.

Mas resolvi falar disso hoje, porque ontem eu fui tentar tirar dinheiro em um caixa eletrônico da rede 24horas (aqueles vermelhos) e passei por um grande problema. Quando escolhi o saque e informei o valor o sistema começou a proceder a operação de saque, que é composta de várias etapas. Quando a maquineta foi colocar o dinheiro para fora, travou tudo e reiniciou. Me vi naquela situação esdrúxula assistindo ao Windows XP reiniciar (não estou dizendo que seja culpa do sistema dessa vez.)

Uma das moças que trabalham na loja disse “Ah essa máquina aí toda hora faz isso” foi quando me ocorreu, e claro gerou um bate-boca com o responsável do horário, porque não colocam um cartaz dizendo que a máquina está ruim e porque não ligam para a operadora (Tecban) para ir dar manutenção? Mas o rapaz só me disse “nós não somos responsáveis por isso não, o senhor tem é que ligar aí para o 0800″ não me convence de qualquer forma, porque se tem um equipamento dentro da loja, e sabe-se que não está bom, acredito que seja responsabilidade deles SIM colocar um aviso.

Em todo caso liguei para a Tecban e fui bem atendido, a moça foi muito solicita (e eu preocupado porque a bateria do celular já estava apitando) e me explicou que quando isso acontece existem duas situações:

1. O equipamento NÃO consegue fazer a atualização na sua conta, nesse caso, quando a máquina volta a transação é cancelada
2. O equipamento consegue fazer a atualização debitando o valor, mas não liberando o dinheiro, nesse caso o banco recebe no seu relatório a informação que houve a falha e volta o saldo da sua conta, em todo caso acho que é uma boa tirar um extrato e ligar para a operadora da máquina para poder um protocolo de atendimento

Achei interessante porque inclusive ao final da ligação ela falou que iria desligar o equipamento remotamente, ou seja, bastava alguém ter ligado antes de mim para evitar muita dor de cabeça.

Quando o sistema falhar (neste caso foi o equipamento + sistema) tenha sempre a mão um processo que contorna a situação, isso pode ser descrito até nos casos de uso porque tem a ver com processo de negócio, principalmente quando envolve coisas que precisam de garantias como operações financeiras.

Atualmente, o desenvolvimento de sistemas evoluiu muito e chegou ao artesanato de software (embora algumas pessoas preguem a engenharia…) o que também nos leva a desenvolver sistemas maiores e aí começamos a ter problemas com nossos clientes e usuários. Isto porque para fazer um sistema corporativo não podemos simplesmente sentar e sair programando. Precisamos identificar o que deve ser feito. O primeiro passo é identificar o problema, em seguida precisamos descrever o problema detalhadamente para então, tendo vislumbrado a solução do problema, consultar o nosso cliente/usuário para listar tudo que deve fazer parte do sistema (assumindo que a solução do problema realmente é um sistema.)

Essa lista que descreve o que deve estar no sistema é a lista de requisitos. Basicamente existem duas categorias principais de requisitos:

1. Requisitos Funcionais – como o próprio nome sugere, representam as funcionalidades do sistema. Cadastros e relatórios são exemplos típicos de requisitos funcionais. Outra dica é que estão diretamente relacionados a atingir o objetivo organizacional do cliente. Por exemplo, segurança nas transações não tem influência direta sobre o objetivo organizacional, sejam seguras ou não, se as transações estiverem programadas elas serão executadas.
2. Requisitos Não-Funcionais – são os itens de software e/ou hardware que devem dar suporte aos requisitos funcionais. Esta é basicamente uma simplificação, dentro dos requisitos não-funcionais também podemos incluir características de desempenho, qualidade, tempo de resposta do sistema e necessidades de acessibilidade. Continuando o exemplo das transações seguras, aqui não importa como as transações são programadas e sim como fornecer a segurança necessária, se possível de forma transparente.

Existem muitos livros sobre o assunto, embora ainda não se tenha chegado a um consenso real sobre o que, como e de que forma identificamos e documentamos os requisitos.

Para fins didáticos costumo simplificar e dividir da seguinte forma:

• Requisitos Funcionais – para cada um deles deve existir pelo menos um Caso de Uso, servem também como uma lista que nos mostra o andamento do desenvolvimento do sistema, o percentual de itens já desenvolvidos até o momento.
• Requisitos Não-Funcionais – representam os itens técnicos e de infraestrutura que vão guiar as decisões sobre a arquitetura do sistema e portanto não têm um artefato específico associado. Em geral são trabalhados pelo arquiteto do sistema.

Dadas as simplificações, costumo então trabalhar os requisitos no formato de lista, isso facilita até mesmo para identificarmos as prioridades e as dependências. Tipicamente os cadastros básicos precisam ser feitos imediatamente para dar apoio as principais regras de negócio.

Na maior parte dos livros sobre engenharia de requisitos são apresentados documentos extensos e complexos para relacionar os requisitos, o que percebi na prática de desenvolvimento de sistemas corporativos é que esse formato de documento complexo não é ágil o suficiente para acompanhar o dinamismo dos requisitos, sim, porque eles mudam ao longo do desenvolvimento do projeto. Quando dizemos que as necessidades do cliente vão mudando ao longo do projeto, estamos falando dos requisitos funcionais que vão sendo adequados as dinâmicas impostas pelo mercado.

Acredito que os requisitos devam ser apresentados de forma simples, e não em um documento a parte da documentação do projeto. Uma lista funciona bem, em casos em que o requisito é muito complexo cabe um parágrafo para descrição, se isso não for suficiente possivelmente aquele requisito pode ser dividido em mais de forma a trabalhar uma quantidade maior de requisitos mais simples.