Este é o nosso segundo FAQ (Perguntas e Respostas) sobre Engenharia de Software.
Mensalmente os membros da nossa lista VIP poderão enviar Perguntas que eu mesmo responderei, sobre quaisquer assuntos no campo da Engenharia de Software.
A seguir, as perguntas dos leitores, com as respectivas respostas.
Leitor: Aline Rodrigues
Gostaria que você comenta se sobre o papel do analista de requisitos trabalhando em conjunto com User Experience.
• Definição de papel no projeto;
• Limite entre áreas.
• E qual sua opnião sobre esse UX na analise de resquisitos.
/* Abaixo meus comentários. */
Analista de Requisitos x Profissional de UX
Em linhas gerais, vamos analisar o papel de ambos os profissionais citados:
- Analista de Requisitos: responsável por entender o problema de negócio, junto ao usuário definir a solução que será aplicada para resolver tal problema, e projetar esta solução em software. Precisa entender o negócio (operacionalmente falando) do cliente, entender de modelagem de requisitos, e saber correlacionar ambos, ou seja “traduzir” a solução para o problema de negocio, para software. Precisa ser hábil em comunicação e interpretação.
- Profissional de UX: responsável por definir a experiência do usuário no uso do software. É importante que tenha conhecimento do negócio (operacionalmente falando – mas em nível mais superficial), pois a operação do cliente define muito sobre como o software deverá ser, em termos de usabilidade, por exemplo. Precisa entender de usabilidade, lógicas de tela, tecnologias de front-end e relacionados. Precisa ser hábil em comunicação e interpretação.
São definições “macro”, mas que nos mostra que, sem dúvida, há relação entre a atuação de ambos os profissionais.
Mas, uma mesma responsabilidade na mão de duas pessoas acaba sendo responsabilidade de ninguém…
Definição dos papéis no projeto
O Analista de Requisitos deve ser responsável por definir o escopo do software.
/* Em projetos de software, considerando contextos de projeto, o software é um dos produtos do projeto. Quando falamos “escopo do software” nos referimos ao escopo de um dos produtos do projeto (no mesmo projeto podem ter outros softwares, estudos, migração de dados etc.). Escopo do Projeto abrange, dentre outras coisas, os produtos que fazem parte da empreitada como um todo. */
A responsabilidade pelo escopo do projeto é do Gerente de Projetos (ou profissional equivalente).
Para a definição do escopo do software, o Analista de Requisitos, conforme já citado, precisa entender o negócio do cliente, entender as dores do cliente (o problema), e definir junto ao cliente a solução que será aplicada.
Esta solução será materializada em um software, que será uma ferramenta de trabalho do cliente. Vamos pensar nisso como o “conteúdo”.
O Analista de UX deve ser o responsável, do ponto de vista funcional do software, por garantir que a parte “visual do software”, a que o usuário “interfaceia” diretamente com ela, seja a mais aderente, fluente, rápida, concisa e confortável possível. Esta solução deve visar eficiência e eficácia no uso do software.
Este profissional não deve interferir (lógico, pode sugerir, comentar, mas não direcionar) no escopo do software do ponto de vista de negócio. Mas, do ponto de vista de navegação, uso, interfaces gráficas etc., é quem deve definir como será feito, e (em algumas empresas), colocar a mão na massa na execução disso.
Vamos pensar nisso como o “forma”.
Por exemplo:
- Uma padaria tem um problema, que é a falta de controle no caixa. Esta controle é feito manualmente, através de recebimento de dinheiro, anotação das vendas, recebimentos e troco, direto em bloco de papel.
- A solução para este problema é automatizar o caixa da padaria, através de um software que vá fazer todo o controle automático das vendas, entradas de dinheiro, troco, gerar relatórios etc.
- O Analista de Requisitos deverá junto ao cliente (100% do tempo de forma propositiva) definir o formato (em termos de escopo – requisitos, funcionalidades etc.) da solução em termos de software. Deverá estabelecer as funções do software, as regras de negócio (cálculos a serem aplicados, processo de sangria de caixa, leitura de código barras, taxas cobradas por forma de pagamento etc.), os requisitos não funcionais (integração com máquinas de impressão e leitura de código de barras, integração com operadoras de cartão etc.).
- O Analista de UX deverá, (também) junto ao cliente entender como sua operação ocorre no dia a dia. Quanto tempo dura cada atendimento no caixa, quais os problemas mais comuns nos caixas (em termos de operação), questões ergonômicas (em projeto deste tipo entender a questão da ergonomia é fundamental, influencia muito no melhor design para este tipo de software), fazer pesquisa com os operadores de caixa, testes A/B com protótipos etc.
Porém, uma coisa é forma, outra é conteúdo. E quando falamos de requisitos não funcionais, realmente há um espaço para ambos os profissionais, Profissional/Analista de UX e Analista de Requisitos, trabalharem juntos.
Limite entre as Áreas
Nos requisitos não funcionais devemos definir os padrões a serem seguidos em termos de Usabilidade. Padrões estes que, em alguns contextos, são definidos pelo Profissional de UX, ha partir de suas definições, oriundas de seu expertise técnico e do seu entendimento da operação do usuário.
Penso que a confluência está aí.
Opinião sobre UX na Análise de Requisitos
Atualmente estamos indo na direção em que um mesmo profissional deva ter várias habilidades, ao invés da existência de vários profissionais especializados trabalhando juntos.
Mas ainda existem empresas, principalmente as de maior porte, que possuem papeis bem separados. Já em startups, por exemplo, o inverso tem se aplicado.
Penso que o ideal é ter um único profissional com ambos os perfis, o que é factível.
Entretanto, se houver separação de responsabilidades de fato (se não houver, é confusão na certa), podem trabalhar juntos, mas deixando claro o campo de atuação de cada um, conforme o que falamos anteriormente.
Resposta: contexto muito interessante. Quando um não quer, dois não brigam, a união faz a força, e é necessário dividir para conquistar 🙂
Leitor: Izael Silva
Quando se inicia um projeto de software webservice visando a recepção de arquivos de base cadastral, qual melhor modelo? Como definir a linguagem, ferramentas de desenvolvimentos necessárias, plataformas, modo on LINE ou batch, pra grandes volumes de arquivos/dados o que é mais indicado? Por onde se começa?
Motivo: sempre me deparo com situações de grande volume de dados cadastrais para processamento e busco alternativas para realizar processamento com alto volume de dados/registros?
/* Abaixo meus comentários. */
Nem tudo que funciona é bom
Podemos ter um ERP rodando todo em Console Application, um sistema financeiro todo em VBA num Excel, ou um processo complexo de ETL todo rodando através de webservices.
Vai funcionar? Sim.
Será a melhor solução? Não.
Antes de definir a arquitetura técnica de uma solução e quais ferramentas serão utilizadas na implementação, é imperativo entender as restrições envolvidas. Para isso, recomendo sempre a boa análise e especificação dos requisitos não funcionais do escopo.
Uma vez definidos os requisitos não funcionais de performance, integração, segurança etc., fica mais tranquilo perceber qual a melhor arquitetura a ser adotada, e analisar a tecnologia que pode ser aplicada para viabilizar isso.
Online, Batch, Síncrono e Assíncrono
Operações online demandam respostas no ato, quando síncronas, e “quase no ato”, quando assíncronas.
Operações batch são processos pré-agendados, executados geralmente ha partir de malha de execução, e que lidam com volume maior de transações, ou então, transações em menor volume, porém mais onerosas, que podem comprometer a performance de um sistema online.
/* Há muita confusão sobre o que é batch e o que é online. Batch é todo processo agendado, que roda em horário específico (mas nem sempre), que geralmente executa tarefas envolvendo grandes volumes de dados (processamento em lotes por exemplo), mas que pode lidar com pequenos volumes também. Online é algo executado em tempo real, mesmo que assíncrono, há partir de uma ação específica de um ator (sistêmico ou humano). Assíncrono pode ser != batch, e síncrono != online. */
Salvo raras exceções, quando definimos uma operação online, esta deve ser síncrona, leve, em tempo real, e não deve comprometer a estabilidade do sistema em modo online e seu bom uso.
Para qualquer operação que possa comprometer a estabilidade do sistema em modo online e seu bom uso, a operação deve ser batch, síncrona ou assíncrona (se assíncrona , demanda maior controle sobre sua execução).
Usar ou não webservices para processamento batch?
Se houver outra opção, analise. Webservices não foram feitos para processos que envolvam grandes volumes de dados, na minha opinião.
É importante pensarmos na pilha de protocolos TCP/IP. Quando falamos de tráfego de um webservice, temos SOAP sob HTTP (hoje JSON ajuda muito nisso), temos o overhead de um servidor web, e ainda, o I/O do servidor.
Isso onera a performance da operação (mais camadas, mais dados, mais controle), além de gerar complexidade adicional ao cenário (quanto mais complexidade, mais bugs, mais pontos de falha, mais tempo para análise de problemas etc.).
Mas existem cenários onde não tem outro jeito.
Eu por exemplo tenho um cliente, onde dou manutenção em um software dele, em que tive que fazer integração com plataforma de terceiros via webservices (ainda com SOAP) para envio diário de dezenas de milhares de registros, mas foi uma imposição arquitetural de um fornecedor.
Mas se eu pudesse, não faria.
Bancos e empresas de Telecom por exemplo, usam e abusam e arquivos texto para carga e descarga de grandes volumes de dados. Uma ponta produz o arquivo, joga para FTP, outra coleta, processa, devolve no mesmo local, e quem produziu pega lá o resultado. Simples e eficiente, e só consome tráfego ridículo de envio via FTP, e I/O para processamento.
Outras empresas integram banco a banco (conectam bancos de dados diretamente), outras via arquivos .csv etc.
Resposta: se tiver outra opção, analise. Todavia, tudo vai depender dos seus requisitos não funcionais, restrições de segurança, arquitetura etc.
Leitor: Luciana Queiroz
Em alguns diagramas é exigido definir um ponto de início e de final, porém minha aplicação roda em loop infinito (como um serviço do sistema operacional), como devo proceder perante esses casos?
/* Abaixo meus comentários. */
Imagino que esteja se referindo a diagramas comportamentais da UML, talvez até mesmo o diagrama de atividades.
Vou assumir que é este diagrama, mas se não for, fique à vontade para informar nos comentários do post, que prontamente a responderei.
Num diagrama de atividades temos três elementos pertinentes: Initial, Final, e Flow Final.
Initial define o início da execução do que está no diagrama. Final define o fim da execução. E Flow Final define o fim de um fluxo específico dentro da execução do diagrama.
Imagino que não esteja se referindo a um loop infinito (imagino que foi força de expressão), pois processos com loop infinito de fato, quebram qualquer sistema. Todo loop é finito.
Porém, este loop finito pode se repetir à exaustão. 🙂
A conclusão de cada repetição do loop sempre estará amarrada a alguma condição.
Por exemplo: você tem uma lista que é alimentada ha cada 10 segundos (seu serviço do SO administra isso), e para cada “alimentação da lista” você roda seu loop, variando de 1 a N (onde N é a quantidade de itens na lista).
Neste contexto, seu diagrama de atividades abordaria todo o processo, e em parte dele, você teria um fluxo para isso, que terminaria sempre que o loop terminasse, e recomeçaria quando a lista fosse novamente alimentada.
Abaixo uma imagem, para ilustrar a ideia.
Resposta: depende do diagrama da UML que está utilizando. Se for diagrama de atividades, pode ser algo como o que fiz acima. Mas talvez fique melhor se utilizar diagramas de sequência, ou de estados.
Leitor: Wilson Araujo
Eu tenho vontade de trabalhar com requisitos e posteriormente com análise de negócios, pois tenho a capacidade de saber ouvir. Trabalhei como programador e analise de sistemas, mas confesso que não tenho mais prazer em escrever códigos de programa. No meu último emprego, fiz levantamento de requisitos e estou procurando emprego nessa área, porém sei que preciso conhecer algumas técnicas como Scrum(estou fazendo curso), UML dentre outros. Eu tenho procurado emprego como analista de requisitos, mas não tenho encontrado. O que posso fazer para deixar o CV mais atraente?
/* Abaixo meus comentários. */
Evidencie o que tem de melhor
O fato de você ter background de Programação é um grande diferencial na competição por uma vaga voltada para Requisitos, na minha opinião.
O profissional de modelagem que entende de construção, sabendo casar ambos os mundos, tende a possuir uma visão mais plausível dos requisitos, ou seja, quando elabora um modelo de um sistema, já correlaciona as necessidades de negócio com aquilo que realmente é viável tecnicamente. (1)
/* Não fale que não tem mais prazer em escrever código. Isso pode soar como “fraqueza”. Alegue que quer mudar de área para evoluir na profissão, por exemplo. Analistas de RH, por razões diversas (algumas justificáveis) tendem a ser precipitados no julgamento. */
Conhecer como funciona o Scrum é legal, é um plus. Isso lhe dá condições de trafegar bem em times que se orientam a esta framework de trabalho.
Mas melhor que conhecer modelos de processo ou frameworks de trabalho, é fundamental desenvolver habilidades técnicas (Engenharia de Requisitos) e comportamentais (boa comunicação – saber ouvir, ler bem, escrever bem, interpretar muito bem etc.) inerentes ao que busca, principalmente a paciência e firmeza. (2)
Destaquei dois pontos (1 e 2).
Em reação ao ponto 1, acho que deve evidenciar no seu curriculum e entrevistas, que está totalmente focado em análise, e que o fato de você ter experiência com programação lhe concede um diferencial competitivo, pois (tomando o devido cuidado) será mais assertivo na modelagem do escopo do software, por saber o que realmente “dá para fazer”.
Idem ao ponto 2, pois possuindo já habilidades de comunicação, precisa deixar isso claro também, no curriculum e na sua postura nas entrevistas.
Um programador pode trabalhar “meio isolado”, um analista de requisitos, não. Conversa o tempo todo (sobre trabalho, claro), pois seu objetivo é, dentre outras coisas, ser ponte, facilitador, entre o cliente e a equipe de construção, por exemplo.
E em relação à busca de vagas, depende do método que está aplicando. Muitas empresas descrevem uma coisa na vaga, e na hora de ver “o que realmente é”, a posição de trabalho nem sempre condiz com o enunciado.
Talvez pensar nisso e tentar atingir mais vagas.
Dois procedimentos que usei muito na busca por emprego
Sempre que tinha dúvida sobre alguma vaga, ligava no RH da empresa para peguntar detalhes, e em alguns casos, pedia para falar com o Gestor da área, para entender melhor sobre.
Isso já clareava mais as coisas, já estreitava os laços e me ajudava a demonstrar interesse.
E também, sempre que enviava o curriculum, ligava depois para saber se receberam.
Depois, me oferecia para ir à empresa me apresentar pessoalmente (isso faz muita diferença).
Demostre interesse, pró-atividade (algo essencial para um analista de requisitos). Nem sempre há tal abertura, mas nunca tive vergonha e sempre tentei (nunca fiquei mais de 2 meses sem trabalho, e credito isso muito a essa postura).
Resposta: evidencie os pontos citados, e tente estreitar o contato para mostrar que realmente está com “sangue nos olhos”. Se não estiver com sangue nos olhos, se motive para tal! Caso queira discutir mais, por ser uma pergunta um tanto macro, estou à disposição!
Leitor: José Armando
Uma dúvida que eu nunca consegui esclarecer é sobre a Engenharia de Requisitos no contexto ágil.
Em um contexto tradicional, a gente tem aquela documentação extensa com “declaração de escopo, objetivos, pré-condições, pós-condições, etc etc etc.”.
No ágil há uma diretriz muito forte sobre documentar o necessário. Não é “não documentar”, mas sim documentar aquilo que é relevante pro projeto. Então prega-se eliminar esse tipo de documentação extensa.
Eu nunca consegui entender como criar um documento de requisitos pensando num contexto ágil. Como entregar um documento de requisitos (template mesmo, layout) para uma sprint dentro de um contexto SCRUM, o que escrever no documento, o que não escrever, formato, etc…
/* Abaixo meus comentários. */
O Manifesto Ágil deve ser visto sempre como a base, neste contexto. Não trata-se de uma metodologia, framework etc., é uma espécie de “filosofia” a ser aplicada.
O Scrum é um framework de trabalho, que se orienta pelo manifesto ágil. Scrum não necessariamente é ágil. Pode-se ser ágil sem Scrum, e rodar Scrum ser ser ágil. 🙂
O grande lance do Scrum, no contexto que está citando, é documentar apenas o necessário. Isso refere-se a duas coisas:
1) Documentar as funcionalidades prioritárias para o negócio, que geram mais valor (geralmente conforme definição de um PO [Product Owner]).
2) Documentar de maneira objetiva, clara e enxuta, provendo assim condições para que se desenvolva (construa) a funcionalidade (ou feature, termo mais utilizado em times Scrum) com a qualidade e produtividade necessárias.
Atendendo aos dois pontos acima, tem-se uma documentação “menor” e “melhor”.
Porém, o que é essa documentação? Aí depende do que for adotado na organização.
O Scrum não restringe isso, e nem deve fazê-lo.
Atualmente fala-se sobre estórias de usuário em times Scrum, mas esse formato é uma questão de opção (que eu particularmente não gosto).
Você pode usar casos de uso com requisitos de software, pode usar prototipação, pode ser até “papel e lápis”, se quiser.
O que muita gente esquece, quando fala-se de ágil, e sobre como o escopo do projeto será definido.
Em projetos de Escopo Fechado, impossível não ter boa (não extensa) documentação, senão será prejuízo na certa (geralmente o prejuízo é do fornecedor).
Em projetos de Escopo Aberto, dependendo do contrato não precisa documentar, pois o risco é todo do cliente (ao menos na teoria).
/* A agilidade foi pensada principalmente para projetos de escopo aberto, onde com o emprego dos valores e princípios do manifesto ágil, as coisas fluem bem. Mas isso ainda é utopia no mercantilismo em que vivemos, salvo raras exceções. */
Se usar estórias, documente as funcionalidades priorizadas pelo PO. Se usar requisitos e casos de uso, idem. Se usar papel e lápis, idem.
Fazendo assim, não se documenta aquilo que não é prioritário, e não se documenta de um jeito em que haverá mais “regras e protocolos técnicos” do que detalhes do escopo que de fato de será produzido num Sprint, por exemplo.
Resposta: agilidade é um padrão de cultura, um “modus operandi”. Scrum é excelente pois prega entregas pequenas, contínuas, e feedbacks constantes (mas não é algo novo). Para conseguir isso, é necessário priorizar sempre, conforme o que gera mais valor para o negócio do cliente. E documentar é fundamental, mas da maneira mais eficiente e eficaz, que atenda à dinâmica que o projeto exige.
Continuous Discovery
Finalizando
Agradecimentos sinceros aos leitores que enviaram suas perguntas! 🙂
Lembrando que não é possível esgotar muitas das questões aqui, pela amplitude destas. E que, ainda, trata-se da minha opinião, que pode ser revista à medida que vou me tornando menos ignorante.
Em breve o próximo FAQ, e faça parte da nossa lista VIP para enviar suas perguntas que estamos à disposição!
Grande abraço!