PROF IOHORAC
Disciplina: REQUISITOS DE SISTEMAS Aula 04: IDENTIFICAÇÃO DOS STAKEHOLDERS. TÉCNICAS DE LEVANTAMENTO DE REQUISITOS
Introdução da aula
Nesta aula, vamos aprender sobre os indivíduos que estão relacionados direta ou indiretamente com um software. Iremos perceber que eles, por exemplos, nem precisam fazer uso do sistema, mas mesmo assim, ele é afetado em algum aspecto. A estes, denominamos stakeholders. É é sobre ele que vamos iniciar nossos estudos. Também teremos a oportunidade de aprender sobre o levantamento de requisitos, o qual sempre está associado a algum ou vários stakeholders. Vamos entender então como nem sempre é uma atividade fácil conseguir identificar o que realmente deve ser um requisito funcional ou não funcional. Por fim, você terá a oportunidade, ao término da aula, de identificar modelos e/ou formas para atingir o objetivo da área de requisitos: entregar o produto com um alto grau de satisfação do cliente.
Uma vez que já definimos uma estrutura e classificação para o desenvolvimento de um projeto de software com controle e garantia da qualidade, vamos na aula de tratar de identificar e detalhar sobre as pessoas que tenham e/ou sejam afetados por um software. Porque, também independente de tecnologia, certamente um projeto que atua na
área
da
software,
engenharia
contemplará
de a
participação direta ou indireta, ativa ou passiva, de pessoas. E justamente nesse perfil de um indivíduo que em algum momento influiFigura algum1 tipo de interesse, participação, determinado
etc.,
software,
caracterizamos stakeholder.
sobre como
a
um este um
PROF IOHORAC Antes de levantarmos as considerações específicas da engenharia de software, vamos buscar um entendimento mais amplo do que vem a ser um stakeholder, permitindo assim que possamos compreender, por exemplo, que não é somente na Computação que existem, mas em todo em qualquer sistema (computacional ou não), sempre teremos agentes diretos ou indiretos, que irão compor ou sofrer das suas características. Acompanhando a Figura 1 (fonte: http://cnx.org/content/m26195/latest/), tente identificar a atividade da empresa que possa conter todos os usuários com base nos “pensamentos” citados nas caixas. Também procure distinguir quais deles seriam colaboradores e quais representam o(s) cliente(s), e, principalmente, sinalize quais serão os stakeholders desse cenário. Deixe anotada a sua resposta para verificar se está correta ou completa. Com foco então em um ciclo de vida do software é possível claramente saber que ele é composto por diversas e distintas responsabilidades que estão vinculadas as pessoas, grupos e entidades. Dentre essas responsabilidades que podemos aqui elucidar, são exemplos: o responsável pelo financiamento, o projeto, o desenvolvimento, o teste, o uso e a manutenção do software. A todos estes chamamos de stakeholder. A palavra vem de da seguinte composição: •
Stake: interesse, participação, risco.
•
Holder: aquele que possui.
Portanto, todos aqueles que de alguma maneira é afetado pelo software, é um stakeholder (reveja sua resposta da questão vinculada a Figura 1). Então é correto afirmar que toda a preocupação no tocante ao correto desenvolvimento de um sistema e demais recursos de infra-estrutura, por sua vez, tem o duplo objetivos de facilitar o cumprimento das responsabilidades dos stakeholders, quanto atender às suas necessidades (voltando a Figura 1, temos: a urgência por desempenho; os aspectos de segurança e usabilidade). Segundo Summerville (2009), podemos definir da seguinte forma: “Um stakeholder em uma arquitetura de software é uma pessoa, grupo ou entidade com um interesse ou preocupações sobre a realização da arquitetura.” Com base então no que já aprendemos, podemos então relacionar os seguintes exemplos e atribuições de stakeholders no desenvolvimento de um projeto de sofware: Gerente de Projeto – Responsável em organizar e conduzir as equipes em suas responsabilidades. Como gestor, precisa manter harmonia no desenvolvimento do projeto,
PROF IOHORAC supervisionando a execução das tarefas, observar os processos, sustentar e fomentar o equilíbrio entre os stakeholders, etc. Analista de Sistema – Responsável em analisar quais as características o que deverá ter o produto a ser desenvolvido para atingir o objetivo final, ou seja, o que o cliente espera. Para isso, busca analisar as especificidades inerentes ao determinado software. Programador – São os responsável em efetivamente desenvolver do software. Cabe a ele a implementação das linhas de códigos que construirão a identidade lógica do software. Patrocinador – Popularmente é quem “paga a conta”. É aquele que libera os recursos, custeia a produção do projeto. Ele será o responsável por prover financeiramente a arquitetura necessária para o desenvolvimento de software. Cliente (usuário) – É aquele que, a partir de uma necessidade, faz a encomenda de um software. Portanto, é quem vai usufruir do produto a ser entregue; seja ele apenas um ou um grupo de usuários. Contudo, além destes supracitados, podemos ter muitos outros stakeholders – que não são tão elementares, mas possuem algum tipo de interesse. Por exemplo: •
Poder público
•
A comunidade
•
Concorrentes
•
Fornecedores
•
Investidores e acionistas
•
As famílias da equipe de projeto
Para contextualizar melhor, acompanhe o exemplo abaixo: •
No contexto da Figura 1 tratado no início dessa aula, podemos dizer que uma pessoa qualquer que ficou no carro aguardando o amigo ou parente devolver um filme, tem grande interesse no desempenho do sistema utilizado pela locadora; caso contrário, o tempo de espera será maior do que o previsto. Portanto, tanto que está no carro aguardando, como quem está na locadora para devolver o filme, são stakeholders.
São outras características dos stakeholders:
PROF IOHORAC 1) São específicos para cada projeto; 2) Possuem anseios e objetivos distintos em um projeto; 3) São atores fundamentais para detalhamento do que deve ser desenvolvido. Mediante então a todos esse envolvimento, fato que pode atrapalhar consideravelmente o êxito de um projeto de software é a ocorrência de uma falha no levantamento dos stakeholders. Tal realidade pode representar que o gerente de projeto não estará pensando nas necessidades de todos os envolvidos; como conseqüência, podemos ter um software que não atende aquilo que o cliente esperava, e de que deverá ser revisto e ajustado posteriormente. Portanto, gerará desgastes de recursos, além da insatisfação daquele que encomendou o sistema. Entretando, o gerente de projeto deve observar bem seus objetivos e não procurar stakeholders por todos lados, o que culminará em um cenário difícil de gerenciar. Deve haver limitação no escopo daqueles que afetam e/ou serão afetados pelo projeto. Caso contrário, com um pouco de imaginação, pode-se considerar stakeholder até a mulher do gerente de projeto que deixará de sair com o marido no fim de semana porque ele terá que trabalhar! Concluindo essa primeira etapa de nossa aula, esperamos que você possa ter entendido toda o envolvimento e influência dos stakeholders em um projeto de software, suas relações e inter-dependência na concepção e uso de um determinado sistema. Técnicas para levantamento de Requisitos Diferentemente do que pode representar a melhor das iniciativas, acionar os programadores para começarem a escrever linhas de códigos não deve ser o foco de atenção para o projeto de software, a abertura para toda a atividade de desenvolvimento de software deve ser o levantamento de requisitos. Como já sabemos, a fonte das informações inerentes ao que queremos automatizar está com os futuros usuários, os quais atualmente já desenvolvem as mesmas tarefas, de forma manual ou automática. Além que o cliente não estabelece claramente todas as regras relativas ao negócio; e quem está sendo contratado desconhece as especificidades referente ao processo que atualmente está em execução. Sommerville (2009) propõe um processo genérico de levantamento e análise que contém as seguintes atividades: 1) Compreensão do domínio: Os analistas devem desenvolver sua compreensão do domínio da aplicação; 2) Coleta de requisitos: É o processo de interagir com os stakeholders do sistema para descobrir seus requisitos. A compreensão do domínio se desenvolve mais durante essa atividade;
PROF IOHORAC 3) Classificação: Essa atividade considera o conjunto não estruturado dos requisitos e os organiza em grupos coerentes; 4) Resolução de conflitos: Quando múltiplos stakeholders estão envolvidos, os requisitos apresentarão conflitos. Essa atividade tem por objetivo solucionar esses conflitos; 5) Definição das prioridades: Em qualquer conjunto de requisitos, alguns serão mais importantes do que outros. Esse estágio envolve interação com os stakeholders para a definição dos requisitos mais importantes; 6) Verificação de requisitos: Os requisitos são verificados para descobrir se estão completos e consistentes e se estão em concordância com o que os stakeholders desejam do sistema. Apesar de aparentemente parecer elementar, o problema de não saber especificar corretamente o que o sistema deverá fazer é muito rotineiro. Realidades como: (a) de um usuário principal do sistema não saber o que quer que o sistema faça ou sabe e não consegue/quer transmitir para o analista; ou (b) requisitos identificados, mas que não exprimem a realidade; e (c) não estão em concordância com os requisitos informados por pessoas diferentes, são constantes na elaboração dos requisitos. Um stakeholder ou informação errada afetará em perda de tempo e dinheiro para ambas as partes envolvidas no desenvolvimento do sistema. É preciso aferir e revisar os requisitos. No tocante ao do analista responsável pelo levantamento dos requisitos, dois fatores contribuem para o baixo grau de satisfação dos usuários, o que aumenta consideravelmente a perspectiva do erro. São eles: •
Não utiliza uma técnica adequada para extrair os requisitos do sistema;
•
Descrever os requisitos do sistema de modo pouco claro, com ambigüidades, sem consistência com todos os aspectos significativos do sistema proposto.
Como contramedida para atacar primeiro item acima destacado, vamos agora estudar sobre as técnicas de levantamento de requisitos, detalhando seu conceito e suas respectivas vantagens e desvantagens, que podem ser utilizadas em conjunto pelo analista. Etnografia A etnografia é caracterizada como uma técnica de observação, aonde o analista buscar uma familiarização do cliente, seus valores, sua história. Ela pode ser utilizada para compreender os requisitos sociais e organizacionais, que facilitem compreensão da política organizacional e da sua cultura. Nesta técnica, o analista é inserido no ambiente de trabalho em que o sistema será utilizado, aonde diariamente são realizadas anotações das tarefas observadas, e que serão incorporadas no sistema a ser utilizado. Esta técnica tem por principal objetivo em auxiliar na descoberta de requisitos de sistema implícitos, que refletem os processos reais, em vez de os processos formais, onde as pessoas estão
PROF IOHORAC envolvidas. Portanto, tem eficácia em atuar na descoberta da maneira como as pessoas realmente trabalham, em vez da maneira pelas quais as definições de processo dizem como elas deveriam trabalhar, além do contexto de integração e colaboração entre o stakeholder e os demais vinculados a ele. São ações consideradas importantes que devem ser executados antes, durante e depois do estudo de observação: •
Antes, é necessário identificar as áreas de usuário a serem observadas; obter a aprovação das gerências apropriadas para executar as observações; obter os nomes e funções das pessoas chave que estão envolvidas no estudo de observação; e explicar a finalidade do estudo;
•
Durante, é necessário familiarizar-se com o local de trabalho que está sendo observado. Para isso é preciso observar os agrupamentos organizacionais atuais; as facilidades manuais e automatizadas; coletar amostras de documentos e procedimentos escritos que são usados em cada processo específico que está sendo observado; e acumular informações estatísticas a respeito das tarefas, como: freqüência que ocorrem, estimativas de volumes, tempo de duração para cada pessoa que está sendo observada. Além de observar as operações normais de negócios acima é importante observar as exceções;
•
Depois, é necessário documentar as descobertas resultantes das observações feitas. Para consolidar o resultado é preciso rever os resultados com as pessoas observadas e/ou com seus superiores.
Mediante suas características, a análise de observação tem algumas desvantagens como, consumir bastante tempo, além da possibilidade do analista ser induzido a erros em suas observações, mediante anomalia no comportamento dos stakeholders. Mas em geral a técnica de observação é muito útil e freqüentemente usada para complementar descobertas obtidas por outras técnicas. Workshops Trata-se de uma técnica de elicitação desenvolvida em grupo, usada em uma reunião estruturada. São integrantes do grupo que participaram do workshop: 1) Equipe de analistas. 2) Seleção dos stakeholders mais envolvidos no contexto em que o sistema atuará. A principal estratégia do workshop tem é acionar o trabalho em equipe. Há um facilitador neutro cujo papel é conduzir a workshop e promover a discussão entre os vários mediadores. As tomadas de decisão são baseadas em processos bem definidos e com o objetivo de obter um processo de negociação, mediado pelo facilitador.
PROF IOHORAC Uma vez encerrado, serão produzidas documentações que refletem os requisitos e decisões tomadas sobre o sistema a ser desenvolvido. Aspectos considerados importantes para o sucesso são: 1) A postura do condutor do seminário - mediador e observador; 2) Deve possuir dia, hora, local, horário de início e de término; destacando o assunto a ser debatido e sua documentação. Entrevistas A entrevista também é uma das técnicas de levantamento de requisitos. Tradicionalmente mais simples de utilizar, produz bons resultados na fase inicial de obtenção de dados. Sobre a entrevista, deve-ser considerar: 1) O entrevistador dê margem ao entrevistado para expor as suas idéias. 2) Ter um plano de entrevista para que seja mantido o foco no cerne do assunto principal. 3) Evita que a entrevista fique longa, deixando o entrevistado cansado e não produzindo bons resultados. Representam boas práticas de auxilio na direção de entrevistas: 1) Desenvolver um plano geral de entrevistas; 2) Certificar-se da autorização para falar com os usuários; 3) Planejar a entrevista para fazer uso eficiente do tempo. Previamente o analista que fará a entrevista deve procurar está bem contextualizado, sendo mais assertivo e produtivo do que será tratado na entrevista. Para tanto, o planejamento deve envolver um momento para coleta e estudo todos os dados pertinentes à discussão, como formulários, relatórios, documentos e outros. Ao término, é necessário validar se o que foi documentado pelo analista está de acordo com a necessidade do usuário, que o usuário não mudou de opinião e que o usuário entende a notação ou representação gráfica de suas informações. São exemplos de como aferir a veracidade das informações levantadas na entrevista: Faça uma explanação sobre o relacionamento entre o que está em discussão e as demais partes do sistema; Informe do ponto de vista de outros usuários em relação ao item que foi discutido; Descreva informalmente a narrativa do item em que o analista deseja obter informações;
PROF IOHORAC O analista deve dizer ao usuário o que acha que ouviu ele dizer. Neste caso, o analista deve utilizar as suas próprias palavras em lugar das do entrevistado e solicitar ao entrevistado confirmação do que foi dito. Questionários Existem vários tipos de questionários que podem ser utilizados. Entre estes podemos listar: múltipla escolha, lista de verificação e questões com espaços em branco. São aspectos relevantes no uso dessa técnica: Um ambiente oportuno para o uso de questionário é quando há diversos grupos de usuários que podem estar em diversos locais diferentes do país. Neste caso, elaboram-se pesquisas específicas de acompanhamento com usuários selecionados, que a contribuição em potencial pareça mais importante, pois não seria prático entrevistar todas as pessoas em todos os locais. 1) Identifique todos os destinatários que o receberão. 2) Realize a distribuição junto com instruções detalhadas sobre seu preenchimento. 3) Defina e informe o prazo para devolução do questionário. 4) Documente o resultado da análise e consolidação das respostas dos participantes. 5) Envie uma cópia com as informações levantadas para o participante, como sendo uma forma de agradecimento e consideração pelo tempo dedicado a pesquisa. Brainstorming Brainstorming é uma técnica para geração de idéias. Uma idéia preliminar gerada serve como incentivo para que outras apareçam, sejam concordantes ou não, propiciando um aprimoramento e compartilhamento de todos os envolvidos. Pode ser estabelecida uma ou várias reuniões. O número de idéias geradas deve ser bem grande, pois quanto mais idéias forem propostas, maior será a chance de aparecerem boas idéias. Os participantes também devem ser encorajados a combinar ou enriquecer as idéias de outros e, para isso, é necessário que todas as idéias permaneçam visíveis a todos os participantes. Uma vez definido que esta é a técnica mais apropriada para determinada situação, as próximas etapas necessárias para conduzir uma sessão de brainstorming são: Seleção dos participantes ou grupo de trabalho: Estes devem ser selecionados em função direta com as contribuições que possam oferecer durante a sessão. É aconselhável sempre a presença de pessoas que estejam sempre bem informadas, sejam de diferentes grupos; Prepara a sessão: Duração e local do encontro, bem como o que será tratado.
PROF IOHORAC Explicar a técnica e as regras a serem seguidas: Definir os conceitos básicos de brainstorming e as regras a serem seguidas durante a sessão; Gerar ou produzir uma boa quantidade de idéias: Os participantes geram tantas idéias quantas forem exigidas pelos tópicos que estão sendo o objeto do brainstorming. Os participantes são convidados, um por vez, a dar uma única idéia. Se alguém tiver problema, passa a vez e espera a próxima rodada. Analisar as idéias: Revisar a produção de idéias, destacando as mais valiosas definidas pelo grupo e classificando-as com prioridades. Prototipagem Protótipo tem por alvo explorar requisitos vinculados a um produto que possua aspectos críticos, implementando de maneira mais rápida um pequeno subconjunto de funcionalidades deste produto. O protótipo é aconselhado para: 1. Estudar as alternativas de interface do usuário; 2. Problemas de comunicação com outros produtos; e 3. A viabilidade de atendimento dos requisitos de desempenho. As técnicas utilizadas na elaboração do protótipo são várias: interface de usuário, relatórios textuais, relatórios gráficos, entre outras. Um dos principais benefícios que podemos relacionar são as reduções dos riscos na construção do sistema, pois é possível detectar se o usuário chave já verificou o que o analista captou nos requisitos do produto. São elementos para o sucesso na elaboração dos protótipos: 1. Seleção do ambiente de prototipagem; 2. Compreender os objetivos do protótipo por parte de todos os interessados no projeto; 3. Focar em áreas que estejam com maior dificuldade na compreensão; e 4. Rapidez na construção. JAD Por fim, não menos importante, vamos apresentar uma técnica de grande adesão pelos analistas a fim de realizar o levantamento de requisitos: JAD (Joint Application Design). É uma técnica destinada a principalmente
promover
cooperação,
entendimento
e trabalho
em
grupo entre os usuários
desenvolvedores. Com a intenção de facilitar a criação de uma visão compartilhada do que o produto de software deve ser, ela ajuda os usuários e desenvolvedores a formular problemas e explorar soluções, no escopo do projeto a ser desenvolvido. Tal fato estabelece sentimento de envolvimento, posse e responsabilidade com o sucesso do produto.
PROF IOHORAC Possui quatro princípios básicos: Dinâmica de grupo: são realizadas reuniões com um líder experiente, analista, usuários e gerentes, para despertar a força e criatividade dos participantes. O resultado final será a determinação dos objetivos e requisitos do sistema; Uso de técnicas visuais: para aumentar a comunicação e o entendimento; Manutenção do processo organizado e racional: o JAD emprega a análise top down e atividades bem definidas. Possibilita assim, a garantia de uma análise completa reduzindo as chances de falhas ou lacunas no projeto e cada nível de detalhe recebe a devida atenção; Utilização de documentação padrão: preenchida e assinada por todos os participantes. Este documento garante a qualidade esperada do projeto e promove a confiança dos participantes. E um total de seis tipos de participantes – levando em consideração quem nem todos participam de todas as fases. São eles: Líder da sessão: É um facilitador dos encontros. Deve ser competente, com bom relacionamento pessoal e qualidades gerenciais de liderança. Engenheiro de requisitos: É um participante experiente nas questões técnicas, diretamente responsável pela produção dos documentos de saída das sessões JAD. Executor: É o responsável pelo produto sendo construído. Representantes dos usuários: São pessoas na empresa que terão incumbência de utilizar o produto de software. Representantes de produtos de software: São pessoas que estão familiarizadas com as capacidades dos produtos de software, capazes de mediar os usuários na compreensão entre o que é possível e razoável no sistema. Especialista: é a pessoa que pode fornecer informações detalhadas sobre um tópico específico.