Elicitação de Requisitos - Introdução

Olá sejam bem-vindos ao canal engenharia de software com ênfase em uml Eu sou professor jis GES e eu já atuo na área de modelagem de software há vários anos eu tenho quatro Dios publicados sobre o assunto e eu já ministrei diversas palestras e cursos técnicos sobre modelagem de software utilizando a linguagem uml na aula de hoje eu vou dar continuidade ao tema sobre engenharia de requisitos dessa vez enfocando elicitação de requisitos eu vou nessa aula dar uma introdução inicial a respeito desse tema Então vamos iniciar o nosso vídeo então ah retomando a a inaria de

requisitos é na minha opinião a área mais importante da higiia de software por quê Porque ela estabelece o que precisa ser feito ela identifica o problema não é possível desenvolver uma solução correta E adequada sem conhecer o problema corretamente então por isso eu considero engen requisitos a mais importante de todas dentro da engenheria de software porque ela estabelece o alicerce a base a partir da qual todo o software será construído a higia de requisitos Como já falei em outras aulas ela se divide em quatro fases principais elicitação de requisitos análise de requisitos especificação de requisitos

e verificação de requisitos da El ação nós identificamos nós identificamos requisitos levantamos os requisitos descobrimos os requisitos necessários ao software na análise esses requisitos eles são como Rob já diz analisados ou seja ã os requisitos são transformados em requisitos de usuário e para requisitos de sistema e eu faço uma série de verificações para determinar se ã os requisitos estão corretos completos hã sem conflitos esse tipo de coisa Ah a especificação de requisitos ela funciona em paralelo Qual é licitação e comal a análise basicamente é a documentação dos requisitos que vão ser identificados e a validação

de requisitos eu faço uma última inspeção ou claro um conjunto de inspeções para determinar se realmente os requisitos estão corretos se eles não eh se eles não estão não t conflitos entre si se eles não têm ã seres estão consistentes se eles estão completos eles não contêm anomalias mas na aula de hoje eu vou iniciar a falar sobre elicitação de requisitos eu vou hoje dar uma introdução sobre licitação de requisitos e nas próximas aulas vou falar sobre H algumas das diversas técnicas de elicitação bom vamos iniciar nosso conteúdo então aqui eu inicio com uma pequena

historinha do Gilbert do criado pelo Scott Adams onde a Alice ela vai entrevistar um usuário ela fala eu preciso saber do seus requisitos antes que eu comece a projetar o software primeiramente o que você está querendo fazer aí o usuário fala eu estou tentando fazer você projetar meu software eu quero dizer o que você está querendo fazer com o software e ele responde eu não vou saber o que eu estou querendo fazer até que você me diga o que o software pode fazer e a fala isso na sua cabeça dura o software pode fazer qualquer

coisa que eu projete que ele faça aí tem alguns minutos de silêncio e o usuário fala você pode projetá-lo para que ele lhe diga os meus requisitos bom é claro que essa historinha é uma piadinha mas ela ilustra a dificuldade em descobrir os requisitos e levantar e elicitar os requisitos e destaca a ade que os usuários muitas vezes T de conseguir expressar as suas necessidades de conseguir comunicar o que eles precisam e alguns casos eles não nem mesmo conseguem conceber todas as possibilidades que o software poderia oferecer para eles bom Opa eu voltei uma lâmina

Então vamos falar sobre o que é elicitação na verdade a palavra correta seria eliciação que é uma palavra que já existe no português há muito tempo ela é obviamente derivada do latim como a maioria dos termos em português já que o português é uma língua neolatina acontece que elicitação com c com aliás com T ela veio da língua inglesa porque o inglês embora em Essência seja uma língua Germânica ele tem uma influência latina muito forte então eles pegaram o mesmo termo a mesma origem a mesma palavra Latina e criaram o termo elicitation e começaram a

utilizar esse termo para tratar de elicitação de requisitos da eles publicaram artigos esses artigos foram traduzidos em português e aí os tradutores talvez não conhecessem o termo iniciação porque era um termo Talvez um pouco arcaico talvez não muito utilizado então Eles resolveram criar o termo eles citação e entrou português então o termo mais comumente utilizado mas Nós criamos um termo novo do inglês para uma palavra que já existia em português que era até um pouco mais simples não era elicitação era iniciação Mas de qualquer forma o mais correto seria eliciação mas todo mundo ou quase

todo mundo na área de de gên de requisito fala em elicitação Então nós vamos trabalhar com esse tema então basicamente elicita significa elucidar ou trazer à tona algo que está latente ou que possui potencial também pode querer dizer tornar visível ou extrair algo como informação bom a elicitação de requisitos como eu falei ela também é chamada de levantamento de requisitos e descoberta de requisitos entre outros termos e ela tem por ob identificar as necessidades das partes interessadas partes interessadas são todas as pessoas que têm interesse no desenvolvimento do produto ou que serão afetadas por eles

Isso inclui até mesmo a equipe de desenvolvimento porque ela tem interesse no desenvolvimento só então a ilação de requisitos ela procura identificar os requisitos que o software deverá satisfazer e obviamente os requisitos eles precisam ser bem compreendidos e bem definidos porque senão o projeto muito provavelmente fracassará se os requisitos não forem bem compreendidos não tiverem sido bem definidos dificilmente o produto desenvolvido satisfará o cliente bom Ah então os erros de especificação de requisitos costuma implicar em retrabalho aumentos do orçamento e atraso do cronograma e dependendo do grau desses erros e do momento em que eles

forem descobertos impo pode ser muito alto e caro e pode causar até mesmo o fracasso do projeto então obviamente nós concluímos que ele citar requisitos é uma tarefa essencial deve ser muito bem feita Mas ela é uma tarefa um tanto difícil por qu o engiro de requisitos tem trabalho de transformar um conjunto de conceitos vagos nebulosos mal formulados em conceitos Concretos e compreensíveis isso não é uma tarefa fácil ah por quê por diversos motivos por exemplo os clientes eles não conseguem expressar as suas necessidades de forma Clara ah das muitas vezes eles nem ao menos

sabem ã nem ao menos conceberam essas necessidades completamente às vezes eles têm ideias vagas e não conseguiram formular não conseguiram pensar em todas as necessidades que eles poderiam ter então Existem várias situações em que as partes eh interessadas elas não têm certeza do que elas querem e elas não conseguem enxergar as possibilidades reais que o software poderia proporcionar a elas ao setor em que elas trabalham e a empresa como um todo então muitas vezes é necessário que o gen requisitos ele preste uma uma espécie de Consultoria ele precisa auxiliar as partes interessadas de forma que

elas possam definir as suas necessidades para isso se usa várias técnicas por exemplo tempestade cerebral grupo focal que a gente vai estudar mais mais para frente e o engo de requisitos muit às vezes ele precisa sugerir muitas funcionalidades para o software que vai ser desenvolvido funci idades essas que em geral não passaram pela pela cabeça do das partes interessadas eles não haviam concebido essas possibilidades Então como falei muitas vezes é preciso prestar uma espécie de consultoria ao cliente por quê Porque é necessário muitas vezes reestruturar e melhorar a forma como a informação é produzida e

gerida na empresa de forma a que a empresa ela se torne mais competitiva que ela tenha um tempo de resposta mais rápido que ela consiga apresentar que ela consiga trabalhar eh com informações que auxilie a a ela tomar decisões Ah então o Ino de requisitos ele tem que reformular a forma como essas informações são apresentadas produzidas e consumidas e pegar as informações combiná-las e apresentá-las de tal forma que elas possam ser melhor aproveitadas e que possam ser utilizadas por organização para que ela se possa ser mais competitiva Ah então por que é necessária essa consultoria

porque muitas vezes o cliente ele não possui conhecimento suficiente para conseguir conceber conseguir imaginar os benefícios que o software poderia proporcionar a ele e a empresa Ah então Eh essa consult na verdade em muitas situações é o que o cliente espera é o que as partes interessadas esperam que o g requisitos faça eles não esperam simplesmente uma informatização eles querem uma melhoria da forma como a um determinado setor da empresa funciona então eles muitas vezes aceitam a maioria das sugestões com bastante facilidade mas um outro extremo em que os clientes eles não aceitam essas sugestões

eles dizem não nós vamos informatizar mas a empresa vai continuar trabalhando do jeito que sempre trabalhou então eles não aceitam certas sugestões de mudança Então para que informatizar porque na verdade nós desenvolvemos software para tornar as empresas mais competitivas mais rápidas melhores nós desenvolvemos software de forma que a informação flua de maneira mais rápida seja combinada de maneira que ela possa auxiliar a empresa simplesmente informatizar mas continuar mantendo a forma como a informação é produzida ã não auxilia muito a empresa a informação vai est um pouco mais organizada Talvez os relatórios os resultados sai um

pouco mais rápido mas é somente isso a empresa não vai se tornar mais competitiva não vai não vai se tornar melhor só fazendo isso na verdade se for para fazer esse tipo de coisa nem precisa criar o software dá para fazer tudo com planilhas eletrônicas na maioria das vezes certo então o software ele tem que acrescentar é por isso que o ingiro de requisitos ele tem que extrair as funcionalidades dos das suas partes interessadas e sugerir muitas dessas funcionalidades a eles bom ah o outro grande problema que a elicitação de requisitos enfrenta é relativo à

comunicação Ah eu costumo dizer que nós não falamos a mesma língua nós falamos dialetos semelhantes por quê Porque os termos utilizados pelos profissionais de áreas distintas costumam ser empregados ter significados ã e sentidos bastante diferentes o exemplo compilar o que é compilar compilar é verificar se a síntese do código está correta é o Que Nós pensamos nós da área de computação Agora se vocês foram falar em termo compilar para editor de livros pro bibliotecário pro advogado ele vai tentar vai entender compilar como sendo a a criação de um livro O termo é utilizado de forma

diferente a mesma coisa a palavra servidor para nós servidor nós vamos pensar Opa é uma máquina que suporta o serviço que roda o software que oferece o serviço a outras máquinas clientes né né o servidor de arquivos o servidor de banco de dados o servidor web o servidor de comunicação eles servidores Ah mas para pessoas por exemplo que trabalham no serviço público eles podem entender servidor Como funcionário que o funcionário concursado por exemplo Então as palavras elas H podem ter vários significados dependendo da área dependendo do sentido que elas que elas forem empregadas na verdade

o português é uma língua muito rica então as palavras e já existe Há muitos séculos Então as palavras podem ter múltiplos significados dependendo do contexto dependendo da área que elas forem sendo utilizadas e isso é um problema para ineria requisitos Ahã aliás fazendo o adendo né muitas vezes essa questão eh também é verdadeira de acordo com a região onde as pessoas vivem e da sua faixa etária entre outros fatores o nosso país o Brasil é muito grande então e uma região determinado termo pode ter um significado e outra pode pode ser pregada num sentido bastante

diferente Ah mas então Eh o problema do ingiro de requisitos é que a maioria dos software são desenvolvidos para pessoas de áreas diferentes da computação e cada área ela costuma ah utilizar alguns determinados termos de maneira específica para aquela área Ahã então mesma Palavra ou expressão ela pode ser interpretada de maneiras diferentes por grupos de pessoas diferentes e isso é particularmente perigoso quando se emprega ou quando se utiliza as gírias o uso de gírias é muito perigoso na licitação de requisitos porque as gírias elas modificam muito o significado das palavras por exemplo a palavra curtir

Originalmente curtir seria esticar um couro ao sol para que ele não rachasse para que Ele pudesse ser utilizado eh com o tempo passou a ser utilizado como no sentido de Sofrimento tá Ah porque Teoricamente uma pessoa ficar esticada ao sol não é agradável Mas então o pessoal começou a falar o Fulano está curtindo uma ressaca o Fulano curtiu 10 dias de 10 anos de cadeia E aí depois eu não sei por que motivo exatamente a palavra passou a ter o sentido de gostar eu estou curtindo uma música Eu estou curtindo o livro eu estou curtindo

o filme esse tipo de coisa então a a gíria modificou completamente o sentido da palavra Ah então não se deve empregar gírias porque isso causa pode causar incompreensão pode eh causar ambiguidade e também não se emprega gírias porque em alguns ambientes isso pode causar uma má impressão as pessoas podem não te ver com seriedade se eh Se empregar giras constantemente poem não não não considerar a pessoa uma pessoa profissional bom mas então uma maneira de contar esse problema utilizar glossários a elicitação de requisitos deve produzir um glossário neste glossário cada termo que é utilizado pelas

partes interessadas principalmente os termos técnicos mas não limitados a esses precisa estar contida no glossário deve ter uma definição que Estabeleça o significado de cada termo de cada de cada expressão para o domínio do problema e que se está enfocando e somente aquela definição deverá ser aceita por todas as partes interessadas por todos os envolvidos no projeto então cada definição de glossário deve Obrigatoriamente ser única e passível de somente uma interpretação ela não pode ser ambígua ambiguidade significa que uma expressão pode ser interpretada de mais uma maneira então o glossário ele tem uma única definição

passível de somente uma interpretação e nenhum outro significado pode ser aceito no contexto do produto sobre desenvolvimento ambiguidade é algo muito perigoso na higiia de requisitos ambiguidade é algo inaceitável que não pode passar não pode ir não pode seguir para as outras fases do desenvolvimento porque pode acarretar ã o desenvolvimento errôneo de funcionalidades e que não satisfaçam o cliente então todas as partes interessadas utilizando um glossário terão um único entendimento sobre cada um dos requisitos el citados bom agora nós vamos falar sobre identificação das partes interessadas que deve ser uma das primeiras tarefas ah a

ser realizadas durante a igia de quisitos antes mesmo de se aplicar a maioria das técnicas de licitação então identificar as partes interessadas é uma tarefa essencial Isso inclui também quais os papéis que essas partes interessadas desempenho no processo de desenvolvimento ah como como eu falei a identificação das partes interessadas da maioria das vezes precisa ser feito antes de aplicar técnicas de licitação de requisitos Ah claro existem algumas técnicas que não não necessariamente exigem que tu interaja com as partes interessadas mas a maioria das técnicas de licitação exige essa interação Então muitos dos requisitos serão obtidos

através de conversas através de interações com as partes interessadas então identificar essas partes interessadas é muito importante para geria de requisitos como um todo Ahã Então eu preciso identificar as partes interessadas Isso inclui Quais são os papéis que elas desempenham dentro da empresa dentro da organização os departamentos onde elas trabalham Como Elas serão afetadas pelo produto isso é bastante importante as pessoas que serão bastante afetados pelo produto é importante trazer elas pro nosso lado mesmo que se se trata de usuários finais que vão poder ã que tem pouca ã poder tem pouco poder de decisão

Mas eles irão utilizar o software Então é bom trazer essas essas partes interessadas pro nosso lado porque muitas vezes elas não gostam do do software novo sobre desenvolvimento elas podem já estar utilizando o software antigo que mesmo que que tenha erros elas já sabe como ele funciona e elas não gostam da ideia de ter que aprender um software novo elas sab sabe que vai demorar para aprender que no começo ocorrerão Possivelmente ã alguns problemas ela sabe que elas vão ter que sacrificar Talvez um final de semana para aprender a utilizar o software e então elas

podem não gostar da ideia do software novo então é importante identificar essas partes interessadas e tentar convencer elas de que o software vai melhorar a vida delas e ajudar a expressar que elas expressem as necessidades que elas têm E também o que poderia ser melhorado em relação ao software antigo mesmo que elas tenham pouco poder de decisão identificar essas pessoas é muito importante também eu preciso saber qual é o conhecimento que essas partes interessadas possuem sobre o determinado setor ou determinado processo eu preciso identificar usuários Chaves ou seja usuários que T bastante conhecimento sobre um

determinado setor sobre um determinado processo determinado departamento da empresa muitas vezes esse tipo de parte interessada tem mais conhecimento que o próprio chefe que o próprio presidente que o próprio dono da organização sobre aquele setor específico dela eu também tenho que identificar a capacidade que essa parte interessada tem de decidir sobre questões relativas ao produto quem decide quem tem poder de ã dar o voto de Minerva de aprovar isso é importante e principalmente como essas partes interessadas elas podem auxiliar e Influenciar no processo de desenvolvimento Além disso eu não posso me ater somente às partes

interessadas internas eu tenho que investigar o domínio do negócio para que eu possa identificar possíveis acionistas fornecedores clientes que irão eh que poderão utilizar o meu software também ou ser afetado pelo produto que eu estou desenvolvendo órgãos governamentais que estabelecem leis que precisam ser seguidas leis regras do negócio entidades reguladoras do mesmo sentido órgãos de controle associações sindicatos e outras possíveis instituições é importante identificar esse tipo de parte interessada então a identificação da parte das partes interessados exige que nós analisemos a estrutura da organização os processos organizacionais e as necessidades do negócio aqui eu tenho

uma figurinha sobre a análise da das partes interessadas então A análise das partes das partes interessadas é o processo de compreender quem tem o interesse real e uma um esforço de mudança e trabalhar com essas pessoas para garantir sucesso então algumas perguntas que devem ser feitas quem tem o interesse real nesse projeto ah essas essas pessoas Elas irão nos apoiar o que H há nesse software nesse produto que seja do interesse delas que irá afetá-las de alguma maneira e como eu me mantenho conectado com elas são algumas perguntas que tem que se fazer durante a

análise de das partes interessadas bom H falar um pouquinho sobre técnicas de modelagem organizacional uma forma de identificar as partes eh interessadas e compreender a organização como um todo é trabalhar com técnicas de modelagem organizacional e de processos algumas delas são organogramas matrizes de partes interessadas ou matrizes de stakeholders stakeholder é o termo inglês para parte interessado diagramas de cebola diagramas BPMN e diagramas de atividade nós vamos estudar algumas dessas técnicas dessa aula então falar um pouquinho sobre organogramas os organogramas essencialmente eles demonstram como a organização está estruturada hierarquicamente Então ela apresenta os setores as

divisões os departamentos da da organização ah e também destacam quais divisões podem ter alguma predominância sobre outras então produzir o orgama ajuda a identificar onde estão as partes interessadas mais importantes ou seja as que têm maior poder de decisão e também quais partes interessadas TM mais influência sobre produto ou sobre outras partes interessadas Então os fatores que precisam ser considerados para cada parte interessada Qual é a influência da parte interessada com relação ao projeto com relação à organização com relação a outras partes interessadas e qual é a autoridade da parte interessada para aprovar entregas entregas

de do do software e mudanças dos seus requisitos bom Aqui nós temos o exemplo de organograma aqui eu eu estou identificando uma empresa de entregas mundiais que eu vou utilizar em alguns em algumas aulas como estudo de caso então é uma empresa que garante entregar Encomendas em qualquer parte do mundo então ela possui filiais espalhados por diversos países e vários países terão várias filiais e quando ela não cobre uma região ela tem eh contatos com distribuidoras parceiras então esse organ esse organograma ele é formado da seguinte forma nós temos uma divisão que representa a presidência

Ah uma alta diretoria e um conjunto de secretárias de alto nível que apoia a presidência e essa alta diretoria depois nós temos três eh gerências principais ou três departamentos principais ou três divisões principais que são a gerência de comendas a gerência administrativa e a gerência financeira a gerência de comendas obviamente trabalha com o Ah o serviço que é ofertado paraa empresa que é a entrega de encomendas propriamente DIT bom a gerência de encomendas ela se divide em departamento de filiais e o departamento de distribuidoras parceiras Porque como falei em algumas situações é necessário ã estabelecer

parcerias com outras distribuidoras e o departamento de filiais ela Gere uma série de filiais cada filial tem um setor de encomendas o setor de entregas e encaminhamentos o setor de RG de recursos humanos e o setor sa já gerência administrativa ela tem o departamento de R principal departamento de recursos humanos e Departamento de Tecnologia de Informação ela gera esses dois departamentos e a gerência financeira ela trabalha com o departamento de contabilidade bom então isso aqui é o organograma simples de uma empresa para auxiliar identificar as partes interessadas uma outra forma que pode ser utilizada em

para é produzir matrizes de partes interessadas aqui eu tenho uma um exemplo de matriz de uma estrutura de Matriz de partes interessada inspirada no babo onde eu represento uma matriz considerando ã dois itens que é a influência da parte interessada que vai de baixo a alto e o impacto sobre a parte interessada a o impacto do software ã sobre a parte interessada que também irá de baixo a alto então nós temos a primeira divisão eh contei a as partes interessadas que tem inf pouca influência eh sobre o o produto que está em desenvolvimento e que

não vai sofrer um impacto muito grande então deve se monitorar se essa influência ou o impacto da parte interessada não vai se alterar nós temos pessoas nós temos partes interessadas com alta influência mas que serão pouco impactadas então tenho que garantir que a parte interessada vai permanecer satisfeita eu tenho partes interessadas com alta Ah que vão sofrer um alto impacto mas que tem pouca influência Então são basicamente os os usuários finais que vai utilizar vai utilizar o software quando ele estiver pronto então tenho que tentar manter essas pessoas informadas sobre a evolução do projeto de

tal forma que eu consiga evitar que elas se sintam ansiosas ou menosprezadas pela falta de controle e nós temos asos interessados que T alta influência e que terão um alto impacto sofrerão um alto impacto do produto Então essas são as pessoas que eu tenho que trabalhar o mais próximo possível para garantir que elas estejam de acordo com o que está sendo desenvolvido que apoia as mudanças e que nos forneçam informações e pareceres feedbacks Aqui nós temos o exemplo de aplicação dessa Matriz de partes interessadas eh para o sistema de empresas de entregas mundiais então aqui

eu identifiquei que as partes interessadas com baixa influência e baixo Impacto que sofreram baixo Impacto são os funcionários que terão pouco ou nenhuma interação com o software como os funcionários trabal das gerências administrativas e financeiras as partes interessadas que terão que terão alta influência mas que sofrerão pouco Impacto são essencialmente o presidente e os membros da alta diretoria as pessoas que terão pouca influência mas que sofrer um alto impacto serão as secretárias os funcionários menores dos departamentos de encomendas e dos departamentos de distribuidoras parceiras e a lei é claro das pessoas que trabalham nas diversas

filiais da empresa e as pessoas que terão ah forte influência e que sofrerão os um forte impacto do produto são o gerente de encomendas e e os funcionários experientes dos departamentos de encomendas de distribuidoras parceiras e das diversas filiais da empresa ah existe aqui também o diagrama de cebola aqui nós temos um exemplo de estrutura do diagrama de cebola H inspirado do babo então nós temos quatro camadas desse diagrama de de cebola A primeira é a entrega da solução que é formada pela equipe de desenvolvimento propriamente dita e outras partes interessadas envolvidas diretamente com o

desenvolvimento do produto nós temos a unidade organizacional afetada que era o setor departamento que será mais afetado pelo produto quando implantado essencialmente é formado por usuários finais que terão seu trabalho afetado pelo produto a organização ou Corporação Ah eu vou identificar então aqui os patrocinadores executivos especialistas do assunto e outras pessoas que vão ã interagir com o grupo afetado e nós temos as partes interessadas externas que vão ser afetadas que são os clientes os fornecedores reguladores e partes interessadas AF fim e afins Ah aqui nós temos um exemplo simples de diagrama de cebola que identifica

as partes interessadas para o sistema de entrega de comentos então na camada mais profunda nós temos a equipe de desenvolvimento propriamente dito ah e uma segunda camada nós identificamos os usuários finais da da gerência de encomendas do setor do da divisão de direço de encomendas que vai incluir os departamentos de eh encomendas e de eh parceiras tribuidoras parceiras bem como os usuários finais das diversas filiais a organização é a Organização das entregas mundiais então aqui eu tenho o presidente alta diretoria e na última camada nós temos as entidades externas que vão ser os clientes que

serão apitados pelo software as distribuidoras parceiras e os fiscais dos diversos países ou de a a empresa atua e a isso nós terminamos mais essa aula eu espero que essa aula tenha sido ah adequada terha sido útil para vocês eu agradeço a atenção e se vocês gostaram desse vídeo eu peço que vocês curtam e compartilhem com que possa ter interesse e se ainda não estiver inscritos eu peço que se inscreva obrigado pela atenção nós nos vemos na próxima aula