terça-feira, 7 de julho de 2009

Carreira em TI: Software / Analista de Requisitos



Assine o conteúdo do Blog Sua Carreira

[ O que faz? ]

Metodologias como o XP - Extreme Programming - têm práticas diferentes para lidar com o problema dos requisitos, criando user stories ao invés de grandes documentos de especificação com requisitos e casos de uso. Elas estão no meio do caminho entre funcionalidades e a formalidade dos requisitos, dado que são escritas pelos próprios usuários do sistema tentando explicitar ao máximo o que precisam. Já quando se usa RUP ou processos adaptados dele - que são o foco deste artigo, por enfatizarem muito na análise de requisitos - o Analista de Requisitos é peça principal no sucesso do projeto.

Em projetos como esses, um Analista de Requisitos trabalha para levantar, analisar, documentar e validar as necessidades do cliente dentro de um projeto de software. Essas necessidades são inicialmente ouvidas do cliente como funcionalidades - ou seja, idéias ou desejos de como o sistema deve funcionar - e normalmente são transformadas em requisitos funcionais e não-funcionais.

Podemos dizer que um requisito funcional é uma funcionalidade reescrita para ter três características: clareza de conteúdo, ausência de ambiguidade e em linguagem mais formal. Em outras palavras, um requisito deve ser claro, formal e não-ambíguo.

Vamos supor que o cliente diga “Quero que o sistema gere um relatório de vendas por período”. Veja a diferença abaixo:

■ Funcionalidade: “Gerar relatório de vendas por período”
■ Requisito funcional: “Dentro do módulo de Relatórios, o sistema deve permitir a geração de um relatório com todas as vendas ocorridas entre duas datas informadas pelo usuário. Como datas default, o sistema deve sugerir o primeiro dia do mês corrente e a data atual.”

Mas o cliente também pode falar “Por falar nisso, nós não usamos Windows por aqui. Todo mundo vai usar Linux nas máquinas que acessam o sistema”. Nessa hora, o Analista de Requisitos ouve um *DING* e percebe que apesar de não estarem ligados às funcionalidades (telas, formulários, relatórios) do sistema, essas informações também são requisitos para o projeto. Então ele:

1) Anota um requisito não-funcional (RNF) “O sistema será hospedado em servidores Linux”
2) Descobre um pouco mais e anota outro RNF “Mesmo não tendo sido definido o SGBD para o sistema, o cliente já possui pessoal especializado em MySQL.”
3) Pergunta ao cliente “Que browsers vocês costumam usar? E qual versão? Existe alguma perspectiva disso mudar?” e com a resposta escreve mais um RNF: “O sistema deve ser acessível a partir do browser Firefox 1.5 ou superior”.



Se você é um Analista de Requisitos e quer garantir que um requisito está bem escrito, leia-o novamente como se OUTRA pessoa o estivesse vendo pela primeira vez. Tente ver se alguém além de você consegue captar 100% do texto, sem duplo-sentido ou interpretações diferentes. Se isso acontecer, pode pular para o próximo requisito.

O RUP sugere também modelar casos de uso, de forma a estruturar as funcionalidades e atores do sistema usando notação UML. Segundo o RUP, isso contribui com mais um passo na direção do software mais robusto: os requisitos são expandidos e pensa-se tanto na sequência de ações e respostas do sistema (fluxo principal) quanto em potenciais situações adversas (fluxos alternativos).

[ Gestão do escopo ]

O conjunto de requisitos - funcionais e não-funcionais - irá determinar o escopo do projeto. O escopo é tudo que o software deve implementar, e será a referência para todo o time de desenvolvimento. E aí vem o segundo trabalho do Analista de Requisitos, que é a gestão de requisitos ao longo de todo o projeto.

Inicialmente, ele participa do processo de estimativa. Consultando arquitetos, analistas e desenvolvedores, ele deve estimar o esforço para implementar cada requisito definido. Isso será a base do planejamento de prazos e custos do projeto! Além disso, se um requisito mudar, ele pode ter impacto em diversas coisas: custos, prazo e qualidade. Para garantir que isso acontece de forma controlada, estabelece-se alguma forma de implementar a rastreabilidade dos requisitos - ou seja, rastrear como eles se relacionam entre si e com o restante dos itens de projeto (código, casos de teste, defeitos, entre outros). Por isso, o Analista de Requisitos deve sempre participar de reuniões de mudanças em projetos, e suas recomendações sempre devem ser respeitadas para aceitar ou não uma mudança no escopo.

[ Conclusões ]

Para ser um bom Analista de Requisitos, é preciso ser organizado e às vezes até metódico. Para ser um excelente Analista de Requisitos, é preciso saber ouvir e escrever bem. Essa é uma das especialidades mais recomendadas na área de TI para mulheres, e os motivos são vários:

■ Elas sabem ouvir melhor do que os homens
■ São mais empáticas e percebem melhor as sutilezas do comportamento humano
■ Costumam ter mais horas de leitura (tanto revistas quanto livros) e também costumam ter maior experiência em escrever (quantos garotos de 12 anos você já viu escrevendo diariamente no “querido diário”?)
■ Têm um talento natural para conversar sem precisar ir direto ao ponto, facilitando a comunicação e envolvendo os outros participantes da reunião.
Não é necessário um curso de Ciência da Computação, Sistemas da Informação ou similar para ser um bom Analista de Requisitos. Até mesmo pessoas da área de Comunicação podem desempenhar esse papel, contanto que entendam o mínimo de UML ou técnicas similares para registrar seu trabalho. Até mesmo usuários mais experientes podem se tornar excelentes especialistas em Requisitos na área de conhecimento das empresas em que atuam.

Não são muitas as empresas que contratam especificamente Analistas de Requisitos. Esse papel é normalmente acumulado por um Desenvolvedor ou Analista de Sistemas, dando origem aos famosos “Analistas Desenvolvedores”. Mesmo assim, o mercado procura cada vez mais esse tipo de profissional.

Score - Requisitos:

■ Empregabilidade: de baixa (grandes empresas) a média (empresas de TI)

■ Perenidade: alta

■ Remuneração: média a alta

■ Mercados: da pequena à grande empresa de TI, ou grandes empresas que possuam equipes próprias de software.
Fonte:

http://mundo.it/blog/2007/09/29/carreiras-em-ti-software-analista-de-requisitos/


Share this post
  • Share to Facebook
  • Share to Twitter
  • Share to Google+
  • Share to Stumble Upon
  • Share to Evernote
  • Share to Blogger
  • Share to Email
  • Share to Yahoo Messenger
  • More...

0 comentários:

Postar um comentário

TRANSLATOR (TRADUTOR)

Tags

Administração Administração do Tempo Administração e Negócios Ambiente de Trabalho Ano Novo Aprendiz Apresentação Atendimento ao Cliente Aumento Salarial Autoconhecimento Autodesenvolvimento Avaliação de Desempenho Baby-Boomers Blog Boas Festas Caráter Caridade Carreira Carreira Saudável CHA Chiavenato Cidadania Cintya Faccioli Cláudio Tomanini Coaching Comédia Corporativa Competência Competências Comportamento Comprometimento Comunicação Comunicador Corporativo Concentração Concurso Público Consultoria Coragem Crescimento Profissional Criatividade Cultura Organizacional Currículo Cursos Daniel Godri Demissão Desenvolvimento Dinâmica de Grupo Disciplina Diversidade E-Learning Economia Educação Educação a Distância Efetividade Eficácia Elegância Empreendedorismo Empreendedorismo Digital Emprego Empresa Ideal Endeavor Entrevista Esperança Estágio Estilo no Trabalho Ética Eventos ExameTV Excelência Facebook Faculdade Família Fator de Sucesso Feedback Felicidade Feliz 2012 Férias Filmes Recomendados Finanças Pessoais Flexibilidade Frases Geração X Geração Y Geração Z Gestão de Pessoas Gestão do Tempo Google Adwords Grandes Líderes Hobby Home Office HSM - Multimídia Humildade iJumper Inclusão Social Independência Financeira Infoproduto Iniciativa Inovação Inspiração Integração Escola de Negócios Inteligência Internet Lição de Vida Liderança LinkedIn Links Patrocinados Livros Recomendados Loite Career Luiz Marins Márcio Mussarela Mário Persona Marketing Marketing Digital Marketing Multinível Marketing Pessoal Maurício Seriacopi Max Gehringer Medo Meio Ambiente Mercado de Trabalho Metas Metodologia MMN Motivação Mudança Negócios Networking Novo Emprego Novo Facebook Oportunidade Oratória Otimismo Paixão Palestras Pão e Circo Parábolas Paradigmas Parceiros Perfil Profissional Persistência Peter Drucker Planejamento Plano B Plano de Ação PNL Polishop Política Primeiro Emprego Problema Processos Produtividade Prof. Menegatti Professor Menegatti Profissões Programa do Jô Projetos Promoções Psicologia Publicidade Qualidade de Vida Qualitymark Recrutamento e Seleção Recursos Humanos Redes Sociais Reflexão Reforma Ortográfica Resiliência Respeito Responsabilidade Social Roberto Shinyashiki Rogerio Martins Saia do lugar Salário Saúde Show Business Sidnei Oliveira Sociedade Solidariedade Solução Sucesso Suely Pavan Superação Sustentabilidade Talento Teatro Tecnologia Teleton201​1 Terceira Idade Tom Coelho Tomada de Decisão TopBlog Trabalhar em Casa Trabalho em Equipe Trainee Treinamento Twitter Vagas Valores Vendas Vida e Carreira Vida no Futuro Vida Pessoal Vida Profissional Vídeos Recomendados Vocação Você Hightech Web 2.0 Workshop