Técnicas de Elicitação de Requisitos - Parte IV

Olá sejam bem-vindos ao canal engenharia de software com ênfase um ml eu sou o professor Janes Gets e o já tuu na área de engenheiro de software e modelagem de software há vários anos eu tenho quatro livos publicados sobre o assunto e eu já ministrei diversas palestras e cursos sobre modelagem de software utilizando a linguagem umé na aula de hoje eu vou dar continuidade ao tema sobre elicitação de requisitos dessa vez abordando técnicas de licitação como análise de documentos análise de regras de negócio e cenários Então vamos iniciar a nossa aula Então essa é a

quarta aula sobre técnicas de licitação como eu falei eu vou hoje explanar brevemente as técnicas de análise de documentos de regras de negócio e cenários Então vamos falar um pouquinho sobre análise documentos também conhecida como coleta de dados então nessa técnica se examinam documentos internos e documentos externos os documentos internos são aqueles disponíveis da empresa e os documentos externos são documentos relacionados ao domínio do problema sobre análise mas que não fazem parte do acervo da empresa O objetivo dessa análise documental é compreender o problema buscar por informações que levem à descoberta de requisitos e auxiliar

na na identifica ação de partes interessadas partes interessadas Como já foi dito em outras aulas são compostas por grupos de pessoas que têm interesse no desenvolvimento do software ou serão afetados por ele bom então os documentos que podem ser analisados durante a análise documental podem ser processos normas leis regimentos diretrizes padrões manuais memorandos gráficos relatórios informações financeiras pesquisas realizadas com clientes análise de dados do mercado produtos da concorrência entre outros possíveis documentos basicamente todo e qualquer documento interno ou externo que possa de alguma maneira auxiliar na compreensão do problema e na produção de requisitos ã

esse tipo de técnica também é útil para descobrir informações quando os usuários chave ou seja usuários que TM bastante conhecimento sobre o domínio do problema ou sobre um determinado funcionamento de um determinado setor ou departamento Eles não estão disponíveis isso é bastante comum porque esse tipo de usuário costuma ser caro para a empresa e muito requisitado Portanto o tempo des disponível para auxiliar os dinheiros e requisitos às vezes é escasso ã e a análise documental ela também serve para validar os requisitos que foram obtidos por outras técnicas eles tentam determinar se os requisitos que as

outras técnicas obtiveram realmente Corresponde à realidade porque às vezes eh os usuários entrevistados eles costumam eh dizer que se comporta de uma maneira para estar de acordo com que com a instruções que são normas da empresa mas que na prática agem de outra maneira por exemplo então às vezes os requisitos obtidos Não condizem realmente com a realidade ah a técnica de análise documental às vezes ela pode precisar adotar eh abordagem de miração de dados ou data mining eh então data mining são técnicas que podem auxiliar na de dados para categorizar esses dados determinar padrões que

são seguidos por esses dados determinar identificar tendências entre outros possíveis objetivos que serão influenciados pelo escopo da análise de documentos porém essa técnica de análise de documentos ela pode ser bastante cara e demorada então preciso tomar cuidado com o tempo e o custo que essa técnica demanda comparado com o benefício que poderá ser obtido por meio desse exame de documentos então Eh é necessário selecionar os documentos que são promissores que realmente aparentam ser válidos para identificar requisitos ou identificar partes interessadas e a responsabilidade do engenheiro de requisitos identificar Quais são os documentos promissores os que

deverão ser realmente analisados caso contrário ess o custo de aplicação dessa técnica pode ser ã impeditivo bom então a selecionar os documentos também eh inclui garantir a sua validade por quê porque pode existir documentos que estão desatualizados Então os requisitos obtidos por eles não serão válidos incorreto o que é pior ainda requisitos que não foram aliás documentos que não foram revisados que eram apenas rascunhos requisitos que no final não foram aprovados Então são documentos Inválidos documentos que não devem ser analisados porque ã além de eles não não serem úteis pelo contrário eles podem ser contraproducentes

eles podem produzir requisitos eh áridos incorretos bom falar um pouquinho sobre processo de análise de documentos então ele possui três etapas principais que são preparação revisão documental e fechamento na preparação na preparação se colecta e avaliam os documentos que estão disponíveis Então se considera a disponibilidade do documento a sua relevância a sua adequação a sua corretude ou seja se ele está correto se ele foi aprovado e a sua atualização se ele não está desatualizado é um trabalho um pouco difícil é é essa preparação já é uma prévia uma triagem prévia de quais documentos são promissores

e quais devem ser desconsiderados depois vem a fase de revisão documental onde o material selecionado ir é estudado os detalhes do negócio são documentados e se elaboram perguntas que deverão ser ser eh feitas para os especialistas a respeito de dúvidas eh sobre determinados eh documentos para confirmação de informações esse tipo de coisa e no fechamento então após a análise dos documentos se validam os detalhes com os especialistas as perguntas que foram eh criadas elas vão ser eh esclarecidas as dúvidas serão esclarecidas com os especialistas e as informações serão organizadas na forma de requisitos de regras

de negócio de modelos entre outras possibilidades vantagens da análise documental não parte de uma folha de uma folha em branco antes de aplicar outras técnicas requisitos já se pode ter uma ideia eh bastante profunda do funcionamento da empresa eh e do domínio do problema e como funcionam determinados departamentos e setores também é uma forma de cruzamento e validação de requisitos que poderão ter sido obtidos por outras técnicas mas com foco nos clientes e nos especialistas de domínio porém tem algumas desvantagens H ela não não produz insights ela não produz não costuma produzir novas ideias ela

apenas identifica a situação atual ela está limitada à perspectiva do como está existe o problema dos documentos estarem desatualizados ou incorretos Isso aí é um risco que ã o engenheiro de requisitos corre ele tem que fazer uma análise profunda para determinar quais requisitos são quais documentos são válidos e ela pode ser trabalhosa pode ser tediosa porque ler muitos documentos é cansativo e podem consumir muito tempo então H Como já foi falado antes é preciso selecionar os documentos adequados e selecionar documentos suficientes para produzirem a informações válidas mas sem que o seu custo e tempo sejam

proibitivos bom vou falar um pouquinho sobre a técnica de análise de regras de negócio na verdade a técnica de análise de regras de negócio é uma variação da técnica de de análise documental A diferença é que ela se especializa em buscar por regras de negócio regras de negócio Como já foi falado antes estabelecem políticas normas restrições condições leis regras que precisam ser seguidas pelas funcionalidades do sistema Ahã então como eu falei essa técnica é um tipo de análise de documentos Mas ela é focada em regras de negócio porém durante a análise documentos que a gente

estudou agora a pouco nada impede que se examinem também regras de negócio Ah bom Por que se devem estudar as regras de negócio por quê Porque além de auxiliar na identificação de requisitos elas estabelecem senão todas a maioria das restrições que precisam ser aplicadas aos que foram identificados e elas também determinam uma parte bastante importante do comportamentos doos processos que irão implementar os requisitos e portanto elas são imprescindíveis para a construção dos cenários para a representação dos comportamentos das funcionalidades do sistema então durante a análise das regras de negócio é necessário Quem elaborou essas regras

e se essas pessoas ainda estiverem na organização elas são candidatas bastante sérias a fazerem a fazerem parte a comporem as partes interessadas E essas partes interessadas então deverão ser consultadas e envolvidas no processo de engenharia de requisitos Ok vou falar um pouquinho sobre a técnica de cenários na verdade é uma técnica eh bastante Ampla e que se estende durante análise e especificação de requisitos nós vamos voltar a nos aprofundar eh a sobre a técnica de cenários eh em outras áreas em outras aulas aqui nós vamos dar uma introdução a essa técnica então o cenário basicamente

descreve como uma funcionalidade irá se comportar em uma situação elas apresentam as ações que o usuário executa em durante nesse cenário e quais serão as respostas do sistema então basicamente um cenário é uma história ele descreve uma situação onde uma ou mais pessoas irão eh executar uma atividade um conjunto de passos no sistema então cenários costumam apresentar uma narrativa rica em detalhes contextuais e eles devem ter no mínimo um ator principal podem haver outros atores secundários e um objetivo um cenário ele pode É um cenário é basicamente texto em suas representações mais simples tá então

ele pode ter várias frases mas no seu formato mais básico ele é composto de um parágrafo único vamos ver exemplos disso então um cenário ele pode descrever um cenário principal um cenário alternativo um ou mais cenários alternativos e um ou mais cenários de excessão o cenário principal basicamente é o caminho ideal o comportamento ideal de uma funcionalidade cenários alternativos representam situações que podem ocorrer ou não de acordo com determinadas condições se essas condições forem satisfeitas ou não e o cenário de sessão descreve situações que não são bem-vindas que são indesejadas mas que precisam ser tratados

caso ocorram Ah então produzir cenários com a interação das partes interessadas ajuda a compreender Qual é o comportamento esperado para os requisitos funcionais que irão compor o sistema sobre as diversas situações pelos quais eles podem passar Além disso produzir cenários pode ser mais fácil para as partes interessadas por quê Porque elas terão de pensar sobre situações da vida real Que Elas costumam vivenciar ou que elas poderão vivenciar então isso pode ser mais fácil do que pensar em necessidades abstratas para o sistema além disso a o desenvolvimento de cenários auxilia as partes interessadas a pensar mais

profundamente mais detalhadamente sobre os requisitos eles ajudam a que as partes interessadas descrevam melhor as suas necessidades e também permitem identificar regras de negócio cenários eles podem ser descritos de forma textual de uma forma textual livre de uma forma textual mais estruturada ou por meio de casos de uso entre entre outras possibilidades nós vamos ver agora alguns exemplos de cenários descritos de forma textual não vamos abordar nessa aula caso de uso principalmente porque caso de uso embora descrevam cenários Eles já são um produto da análise de requisitos então nós iremos abordar casos de uso mais

profundamente no futuro em outras áreas outras aulas bom então Aqui nós temos um exemplo deen textual aqui eu estou enfocando a funcionalidade postar e encomenda do sistema de Entregas de Encomendas Mundial que nós estamos utilizando como estudo de caso então Aqui nós temos o primeiro cenário que é o cenário principal que identifica o caminho feriz o caminho ideal da dessa funcionalidade então o cenário um a encomenda atende às condições de envio Então vamos lá aqui nós temos a descrição do cenário o cliente ele se dirige ao atendente e apresenta a encomenda o atendente Toma os

dados do cliente e do destinatário pergunta sobre o conteúdo da encomenda mede suas dimensões ou seja altura e largura bem como seu peso e insere esses dados no software o software ele calcula o preço do envio o atendente informa o valor para o envio E caso o cliente aceite ele coloca a encomenda na esteira para que se seja para que encomenda seja analisada empacotada etiquetada e despachada enquanto isso ocorre o cliente paga pela encomenda e o atendente registra o pagamento o sistema então emite o recibo e o código de rastreamento da encomenda Então esse O

caminho feliz tudo correu perfeitamente bem o cliente conseguiu ã realizar conseguiu postar a encomenda na empresa aqui nós temos um outro exemplo é o segundo um cenário que representa uma uma um cenário alternativo que não deveria ocorrer mas que eventualmente pode acontecer então esse cenário identifica uma situação em que a encomenda ela possui um item roubado ou ilegal não necessariamente o cliente sabe disso apenas o seu conteúdo é roubado ou ilegal então durante o escaneamento da encomenda quando a encomenda ela é é posta na esteira o sistema ele escaneia de forma utilizando técnicas avançadas escaneia

encomenda para determinar o seu conteúdo o atendente Ele pergunta ao cliente Qual é o conteúdo da encomenda mas ele não abre isso é feito durante a o escaneamento da encomenda na esteira então durante o escalamento o sistema detecta a presença de Um item roubado ou ou ilegal como drogas ou armas por exemplo então o sistema em resposta ele aciona a polícia sem que o cliente fique sabendo disso Avisa o atendente do ocorrido e fotografa o cliente a encomenda fica retida e não é despachada Então esse é o segundo cenário bom E aqui nós temos um

terceiro cenário que identifica uma situação em que a encomenda ela possui um item proibido ou que a empresa não aceita enviar e que não necessariamente o cliente saiba que o item é proibido então ao escanear a encomenda o sistema detecta a presença de Um item cujo envio é proibido no país de origem ou de destino ou de itens que a empresa se recusa a enviar como itens contendo líquidos porque eles podem derramar elementos perecíveis porque eles podem estragar ao longo do envio itens frágeis porque eles podem quebrar itens vivos por uma questão ética ou semente

porque enviar sementes pode ser perigoso Às vezes as sementes elas entram em um bioma diferente que não que ao qual elas não pertenciam elas podem causar muitos problemas então o sistema Informa a atendente que não é possível enviar encomenda e dessa vez o atendente informa o cliente que a encomenda foi recusada e a devolve ao cliente no caso não é exatamente um crime simplesmente ente a empresa não pode enviar o conteúdo então o atendente tem que recusar a encomenda e explica ao cliente O porquê disso então aqui nós vimos três cenários um cenário ideal um

cenário alternativo e um cenário de exceção exemplos de cenários textuais como eu falei existem cenários estruturados ainda textuais cenários também podem ser representados por meio de casos de uso mas nós vamos detalhar isso melhor em outras áreas em outras aulas ente quando nós entrarmos em análise de requisitos porque na verdade casos de uso representam já requisitos do sistema então nós terminamos mais essa aula sobre técnicas de licitação eu espero que essa aula tenha sido considerada adequada por vocês se vocês gostaram desse vídeo eu peço que vocês curtam e Se vocês souberem de pessoas que T

interesse sobre esse tema eu peço que vocês compartilhem esse vídeo com elas obrigado pela atenção nós nos vemos em outras áreas outras aulas