Análise Funcional – Navegando até ao objetivo
Depois de mergulharmos nos básicos sobre este tema, que podem consultar aqui , que tal navegar no dia-a-dia com mais um pouco de perícia por este mar de transformações digitais?
Como os hábeis marinheiros nas viagens dos descobrimentos, munidos de astrolábios, mapas e sextantes, também um analista deve ter ao seu dispor diversas ferramentas e práticas para se orientar na sua busca de respostas, na sua função de transformador. É isso que vos proponho para este artigo.
Grande parte do trabalho de um analista funcional desenrola-se à volta de requisitos, a sua identificação, a sua classificação e consequente apresentação aos diferentes intervenientes da equipa ou do projeto.
Mas afinal o que é um requisito?
É uma condição necessária de se realizar, para se obter um determinado objetivo. Se pensarmos bem, este conceito não é só usado em desenvolvimentos digitais. Existem outros aspetos da nossa sociedade que usam o conceito de requisito para atingir o sucesso, áreas como a medicina, ou até mesmo a legislação e o direito. Podem existir requisitos de tipos diferentes. Vou referir apenas requisitos funcionais e requisitos não funcionais, de forma simples. Funcionais são aqueles que detalham o que um sistema/aplicação/iniciativa deve conseguir fazer. Não funcionais são aqueles que detalham características de qualidade do sistema/aplicação/iniciativa, aspetos como o desempenho, usabilidade, confiabilidade.
De forma geral e, focando em IT, podemos dizer que um requisito serve para descrever e esclarecer as necessidades de um, ou mais utilizadores no projeto. De acordo com os objetivos definidos previamente. No entanto, um requisito nem sempre implica o desenvolvimento ou a codificação de uma nova funcionalidade em sistemas ou aplicações. Por exemplo: se o objetivo do projeto passa por garantir que os operadores de caixa reduzam o tempo de atendimento ao cliente. Um requisito pode perfeitamente ser desenhar/identificar um plano de formação para estes operadores, reforçando assim os seus conhecimentos do sistema e o seu manuseamento. Sem necessidade de desenvolvimento de uma nova ferramenta. Assim, cabe ao analista identificar estas alternativas e apresentá-las aos intervenientes do projeto responsáveis por tomar a decisão. Um bom requisito deve ser S.M.A.R.T. (especifico – Specific, Mensurável, Atingível, Realista, oportuno – Timely).
Exemplos de algumas Ferramentas-chave de trabalho
Existem atualmente inúmeras práticas e ferramentas que podem ser uteis, tanto para o levantamento de requisitos junto dos diferentes stakeholders – intervenientes, como para a sua análise. Assim, vou deixar-vos apenas alguns exemplos disponíveis. Apenas referir que nenhuma é perfeita, cada uma terá sempre os seus pontos fortes e pontos fracos, poderei entrar em maior detalhe sobre isso mais tarde.
- Análise SWOT (S- Strength – pontos fortes, W- Weakness – fraquezas, O- Opportunities – oportunidades, T- Threats – ameaças)
Permite analisar a informação recolhida em 4 quadrantes ou categorias. É uma técnica que pode ser utilizada em várias fases de um projeto. Muitas vezes, numa fase inicial de projeto: os fatores internos são considerados como pontos fortes ou fraquezas, já os fatores externos podem ser classificados como oportunidades ou ameaças.
- Brainstorming
Normalmente é uma atividade de grupo e talvez das práticas mais conhecidas. Funciona através da estimulação da criatividade dos elementos do grupo. O grupo interagindo, procura gerar ideias, encontrar a origem dos problemas e propõe soluções para os mesmos. Muitas vezes é usada numa fase mais embrionária dos projetos e pode servir para alimentar técnicas mais complexas ou simplesmente para identificar requisitos e/ou funcionalidades.
- User Stories
Esta é uma prática mais recente e usada maioritariamente em metodologias Agile. Aqui, os requisitos são identificados partindo do ponto de vista do utilizador final, com o objetivo de construir a melhor solução possível no projeto. Uma vantagem clara é a elevada eficácia do resultado da análise, pois esta é muito focada no utilizador. Resumidamente devem seguir o formato: as (role) I can (ability), so that (receive benefit). Daqui, podem ser identificadas as capacidades e diversas funcionalidades necessárias para se atingir o sucesso nesse projeto.
Exemplo simples de uma user story – Como utilizador do sistema eu quero pedir um esclarecimento à empresa para que as minhas dúvidas sejam retiradas.
- Business Process Modelling (BPM)
É uma técnica de representação e modelação de processos em diagramas ou fluxogramas sequenciais. Quer seja para simplesmente mapear procedimentos ou, para permitir fazer uma análise mais profunda, procurando possíveis melhorias. Normalmente é utilizada na fase de análise de um projeto para compreender, estudar/ilustrar, identificar e posteriormente recomendar as alterações, de forma, a se atingir os objetivos pré-definidos. A notação mais conhecida para a construção destes mapas/fluxos é a UML (Unified Modeling Language), mas existem outras.
Espero ter conseguido ajudar-vos a desmitificar um pouco mais as funções e o papel de um analista funcional, neste nosso mundo em constante transformação. Muito há ainda a dizer sobre o tema, pelo que futuramente pretendo abordar mais profundamente como tudo se pode encaixar, de uma ponta à outra, num dos muitos projetos de povoam a nossa realidade digital. Até lá!
Mais de Carlos Sanches:
What's Your Reaction?