PROF. HORACIO
Disciplina: REQUISITOS DE SISTEMAS Aula 07: ELICITAÇÃO DE REQUISITOS Introdução da aula Continuaremos imersos nos conteúdos sobre a engenharia de requisitos, tratando sobre o segundo dos quatros tópicos que começamos na aula anterior; nossa aula de hoje trabalhar sobre a elicitação de requisitos, destacando a importância no resultado de um software que atenda as necessidades dos usuários. Sob o escopo do analista de negócios, a elicitação (em inglês, “Elicitation”) é a atividade responsável em compreender as necessidades e preocupações das partes interessadas e os ambientes no qual elas trabalham ou operam. Portanto, é preciso saber que existe uma distinção entre “elicitar” e “levantar”, uma vez que o primeiro termo é mais abrangente é o foco na extração das necessidades verdadeiras, que podem ou não estar explícitas. Portanto, muitos dos conteúdos que estudamos na I Unidade serão reprisados na aula de hoje, mas agora visto sob a percepção do analista de negócios, na atividade da engenharia de requisitos.
Livro
SOMMERVILLE, I., Engenharia de Software, 9ª Edição. Pearson, 2011. Capítulo 4: Engenharia de Requisitos.
Seja bem-vindo a segunda etapa das nossas aulas sobre as atividades da área de requisitos. Continuaremos imersos nos conteúdos sobre a engenharia de requisitos; nossa aula de hoje trabalhar sobre a elicitação de requisitos, destacando a importância no resultado de um software que atenda as necessidades dos usuários. Revisando sobre as quatro atividades da área de engenharia de requisitos (principalmente se precisa revisar algum assunto), veja ordem abaixo: Aula 6 - Viabilidade. Aula 7 – Elicitação. Aula 8 – Validação.
PROF. HORACIO Aula 9 – Gerenciamento. Estas atividades fazem parte do que definimos como processo de engenharia de requisito. Lembre-se que não temos um comportamento e necessidade uniforme na área de software. Quando decidimos construir um sistema, certamente temos uma necessidade e um perfil que nos torna único, portanto, “em praticamente todos os sistemas os requisitos mudam.” (Sommerville, 2009). Com base nesse cenário, tornar-se necessário então a padronização o procedimento, para ter maior convicção da acertabilidade do que está sendo desenvolvido. Portanto, caso tenha o desejo em atuar na área de projetos, certamente lhe será requerido conhecer bem sobre as atividades inerentes a engenharia de requisitos, no tocante a entender o real problema do seu cliente. Tendo em mãos essa importante informação, terás grandes possibilidades de um resultado mais apurado e correto. Faça um bom proveito! Vamos lá!
PROF. HORACIO
Conforme tratamos no início do estudo da disciplina, é preciso saber e fazer saber a(s) finalidade(s) de um software. Portanto, um fundamental questionamento que precisa ficar bem esclarecido para todos os envolvidos é: O QUE REALMENTE QUEREMOS?
Figura 1. Fonte: http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/intro/processo.htm
A figura 1 demonstra um cenário que envolve dois fatores: céu com nuvens e uma grama verde. Apenas estes são substancialmente suficientes para diferentes interpretações, sujeitando a diversas soluções que não compreende a resolução efetiva do que se queria. Importante ver que nem mesmo o próprio cliente soube explicar com exatidão o que ele queria. Podemos então rapidamente transferir ao cliente a responsabilidade pela não conformidade do produto entregue; destituindo-nos de qualquer culpa, então friamente nos posicionamos: “lhe entregamos o que foi pedido!” Seria então esse o perfil mais adequado? Certamente que se queremos ser uma empresa de referência para segmentos de software e/ou engenharia de requisitos, definitivamente, NÃO! Vamos então imaginar um cenário em que o cliente esteja apresentando suas necessidades e seus objetivos para um sistema computacional. Lá estão alguns diretores e representantes da empresa contratada: - Queremos que o sistema faça: isso, isso, aquilo, isso juntamente com aquilo... - Também podemos então adicionar aquilo outro que vi no do meu colega, que pertence aquela empresa (detalhe: a empresa é de outro segmento comercial). Fonte: http://ogerente.com.br/rede/carreira/o-que-e-um-problema
Então, quando do uso da palavra (de terno e gravata), fala de maneira convincente: - Tudo anotado e esclarecido. Tenho certeza que ficará muito satisfeito com o que lhe entregaremos.
PROF. HORACIO
A diretoria reúne os usuários que serão “beneficiados” com o sistema; fala sobre como a vida deles mudará – inclusive já está levantando quantos deverão permanecer na empresa. Faz o convite para o representante da contratada prestar esclarecimento. Novamente (ainda com terno e gravata), ela faz uma apresentação do seu currículo e em quer resultará o projeto. Detalhe: alguns funcionários começam a especular perigo de demissão em massa. Então soa a pergunta: - Alguém tem alguma sugestão? O genro de um dos diretores levanta-se na platéia e saúda a iniciativa como sendo de tempos modernos para a organização, pedindo aos presentes uma salva de palmas. Depois de algum tempo de espera eis que o documento de requisitos de software está pronto. E é remetido para análise. Depois de 18 meses de trabalho, eis então o feedback: após a análise de um documento que julgamos muito difícil, chegamos a conclusão que NÃO FOMOS CORRETAMENTE ENTENDIDOS!
´´A parte mais árdua na construção de um software consiste exatamente em identificar o que construir. Nenhuma outra parte do trabalho compromete tanto o resultado do trabalho se elaborado de forma incorreta. Nenhuma outra parte oferece tanta dificuldade para efetuar correções posteriores. " — Fred Brook ELICITAR: descobrir, tornar explícito, obter o máximo de informações para o conhecimento do objeto em questão.
Sob o escopo do analista de negócios, a elicitação (em inglês, “Elicitation”) é a atividade responsável em compreender as necessidades e preocupações das partes interessadas e os ambientes no qual elas trabalham ou operam. Portanto, é preciso saber que existe uma distinção entre “elicitar” e “levantar”, uma vez que o primeiro termo é mais abrangente é o foco na extração das necessidades verdadeiras, que podem ou não estar explícitas. A atividade da elicitação dos requisitos não é habitualmente desenvolvida forma isolada, visto que a identificação de requisitos costuma aparecer de forma cíclica durante sessões tanto de levantamento quando de validação, portanto requer uma combinação de técnicas para que seja completa. Conforme estudamos na primeira unidade, as técnicas de levantamento de requisitos são: brainstorming, análise documental, entrevistas, observação, prototipagem, workshops de requisitos e pesquisa/questionários. No tocante as tarefas inerentes ao processo da elicitação dos requisitos, temos: a preparação, condução, documentação e confirmação dos resultados da elicitação. A elicitação de requisitos envolve o processo de identificar junto aos stakeholders, frente ao sistema ou produto, os seguintes pontos:
PROF. HORACIO
1. 2. 3. 4.
Os alvos a serem alcançados; Os pontos a serem acompanhados; Como se encaixa no contexto das necessidades do negócio; e O comportamento ou operacionalização da solução rotina da solução na rotina da empresa.
Mas então porque se apresenta como um processo extremamente complexo? Vejam: Problemas de escopo: excesso ou falta de detalhamento. Os clientes/usuários desconhecem o que é importante (ou até mesmo quer ocultar), inibindo os limites do sistema, o que dificulta uma definição completa. Problemas de compreensão: omitem informações que julgam óbvias; clientes/usuários desconhecem ou estão em dúvidas sobre as necessidades e como seu papel é fundamental; é leigo ou limitado no conhecimento de seu ambiente computacional ou do domínio do seu negócio e etc. Problemas de volatilidade: mudanças constantes nos requisitos.
A partir deste cenário, algumas ações são sugeridas para superar estes problemas, a fim de uma abordagem organizada para o processo da elicitação. São eles: Considerar a viabilidade técnica e de negócio para o sistema proposto; Identificar as pessoas que vão auxiliar a especificar os requisitos e incluir seus preconceitos organizacionais; Definir o ambiente técnico no qual o sistema será instalado; Ter domínio sobre o que é o sistema e o que ele realmente representa; Envolver um ou mais métodos de elicitação de requisitos; Sempre incentivar a participação de várias pessoas, possibilitando a concepção dos com a contribuição de diversos pontos de vista; Independente do tamanho do que esteja sendo construído, os produtos da utilização dos passos trabalho incluem:
Ter totalmente bem estruturadas as necessidades e viabilidade; bem como, a definição do limite de escopo do sistema ou produtos; A relação de clientes, usuários e outros stakeholders que participaram da atividade de elicitação de requisitos; Conhecimento descritivo do ambiente técnico do sistema; A lista de requisitos e suas respectivas aplicações regras de domínio. Cenários de uso que promovem uma concepção do uso do sistema sob diferentes condições de operação; Informação de um modelo que eventualmente tenha sido desenvolvido para melhor definir os requisitos. Revisões realizadas por todas as pessoas que tenham participado da elicitação de requisitos.
Leiam a matéria abaixo e observem algumas características importantes em um analista de negócios, a qual aponta adjetivos importantes para o responsável em atuar em qualquer uma das etapas da elicitação de requisitos (Fonte: http://imasters.com.br/artigo/17785/carreira/soft-skills_do_analista_de_negocios/): De acordo com o Babok, Análise de Negócios é: O conjunto de atividades e técnicas utilizadas para servir como ligação entre partes interessadas no intuito de compreender a estrutura, políticas e operações de uma organização e para recomendar soluções que permitam que a organização alcance seus objetivos. Recentemente tive que pensar, por motivos profissionais, sobre os skills necessários para um Analista de Negócios. Após muita pesquisa e conversas com colegas que já estão há um tempo trabalhando com isso, em suas diversas denominações (Além de Analista de Negócios, também Analista de Sistemas, de Requisitos, Funcional, entre outros), ficou claro que os soft skills necessários são:
PROF. HORACIO Ser bom ouvinte Ser um bom ouvinte é de extrema importância. Ajuda a evitar distrações enquanto o cliente está lhe explicando alguma funcionalidade/necessidade, a manter uma boa postura e contato visual diretamente com o cliente. Afinal, você precisa entender e tirar dúvidas sobre o que ele está dizendo. Sem ser um bom ouvinte, muitas coisas passarão despercebidas e seu levantamento poderá ter furos que só serão detectados em outro momento. Ser um bom questionador As maiorias dos requisitos saem de discussões com o cliente. É frequente a conversa com pessoas e até um grande grupo de pessoas para conseguirmos mais detalhes sobre determinado requisito. Estar atento e fazer perguntas-chave são de extrema importância para o levantamento de requisitos. É normal que, com o tempo, a experiência lhe proporcione a sabedoria necessária para fazer as perguntas corretas no momento certo. Ser observador Um analista observador percebe, em comentários e em outras situações junto ao cliente, sua real necessidade (cliente que, muitas vezes, não sabe do que está precisando), vê um novo requisito, vê uma nova oportunidade de negócio. Além disso, consegue oferecer um algo a mais no produto final, garantindo, além do real valor ao negócio do cliente, a satisfação e uma boa imagem junto aos usuários finais do sistema. Escrever bem Com certeza, um dos skills mais importantes, senão, o mais importante, é um analista que escreva bem, que consiga comunicar as necessidades do cliente em texto, em um formato que tanto os clientes, quanto a equipe de desenvolvimento, entendam sem dificuldade. Dominar o idioma na qual o requisito é escrito é de extrema importância. Infelizmente, muitas pessoas têm dificuldades com seu próprio idioma. Para aprimorar essa habilidade é preciso ler mais - livros, revistas, jornais - e também praticar, escrevendo. Ser organizado Como um analista trabalha com muitas informações ao mesmo tempo, ele deve ser organizado para que consiga passá-las de maneira correta. Saber estruturar muito bem suas informações, mesmo antes de serem passadas para o papel, é muito importante, pois elas podem ser solicitadas a qualquer momento por um gerente, ou por um cliente. Ser organizado também quer dizer organizar bem os e-mails. Afinal, recebemos vários e-mails dos mais variados assuntos. Montar uma estrutura básica, mesmo que apenas você vá cuidar dessas informações, ajudará em sua organização. Ser criativo "O melhor analista de requisitos inventa requisitos" (Robertson - 2002). Durante as conversas com o cliente, o analista descobre valores para o projeto que às vezes nem o próprio cliente conhece. Esse skill está muito relacionado com o terceiro, "ser observador". Um analista que é um bom observador, com certeza visualizará novos requisitos, mesmo sem a descrição direta, e conseguirá oferecer melhores soluções para seu cliente. Perguntei aos meus colegas, se existiam todos esses skills em um único profissional. A resposta, obviamente, foi negativa, mas uma coisa foi unanimidade: o profissional deve identificar quais são seus principais gaps, seus pontos a melhorar e ir atrás desses skills. Sei que todas as profissões têm suas dificuldades e seus méritos, porém há muitas atribuições que podem ser aprendidas através de cursos e estudo em livros, além de certificações. Porém, esses skills são características pessoais, que ou nascemos com elas e vamos aprimorando durante nosso crescimento, ou
PROF. HORACIO que não nos são natas e que precisamos nos esforçar muito para mudar e adquiri-las quando adultos. O melhor é que a maioria das características que listei trarão benefícios também para a sua vida como um todo, não apenas profissionalmente. Cientes que não é tão trivial e simples como demonstra ser, elicitar requisitos detém boa parte do tempo e considerável esforço, mas é uma etapa estratégica e fundamental para o desenvolvimento de um projeto tenha efetividade.