[Música] o olá sobrou para marcelo fantinato esta disciplina de engenharia de software do curso de engenharia da computação vamos agora para a aula sete tratar de licitação e análise de requisitos dentro do processo de engenharia de requisitos da licitação e análise de requisitos são duas etapas a primeira etapa dentro do processo de engenharia de requisitos a etapa de descoberta dos requisitos para que baseado nesse quisito eles sejam analisados e sejam sejam usados para que seja composto o documento de especificação de requisitos e depois este documento ele é validado para isso então os engenheiros de software
ou mais especificamente nesse caso os analistas de requisitos eles vão trabalhar com os clientes e usuários finais os clientes são aqueles que contrataram a empresa de desenvolvimento de software e usuários finais são aquelas pessoas que vão realmente usar o sistema o software no final quando o sistema estiver desenvolvido então tanto os clientes quanto os usuários finais serão envolvidos nessa actividade né de licitação de requisitos ou descobertos requisitos ele não ser usados para que se obtenha informações sobre o domínio da aplicação os serviços que o sistema deve oferecer o desempenho do sistema outro tipo de restrição
de hardware enfim requisitos funcionais requisitos não funcionais requisitos do usuário e depois os requisitos do sistema então a e licitação de requisitos é descoberta dos requisitos a partir das informações dos clientes e dos lados nós temos uma série de desafios relacionados a atividades de e licitação de requisitos primeiro gente de usuários costumam não saber exatamente o que querem eles têm uma visão muito abstrata do sistema que eles querem em geral têm dificuldade de articular e se essas informações de explicar o que o sistema realmente tem que fazer e às vezes eles podem acabar fazendo exigências
que são enviável eles pedem algumas coisas que eles não têm noção do quão difícil ou inviável pode ser o desenvolvimento é daquele tipo de funcionalidade além disso os clientes e usuários acabam usando alguns termos que são próprios daquela área que não funcionando dos vagões e também algum conhecimento implícito que um quando eles usam algum tipo de palavreado algum tipo de revisão já existe um conhecimento em cristo da área ali que os analistas de requisitos não necessariamente conhecem eles acabam não abstraindo a informação que o usuário acha que está é claro enquanto não está claro é
e aí o analista de requisitos acaba não entendendo o que eles deveriam ter entendido além disso diferentes 500 diferentes usuários eles podem expressar requisitos diferentes formas às vezes eles estão falando a mesma coisa de diferente forma eo analista de requisitos entende coisas diferentes ou às vezes os clientes usuários acham que tem que ser diferente cada um fala de uma forma e o o o analista de requisitos fica sem saber exatamente qual é a forma correta então juntando tudo isso o analista de requisitos acaba tendo que lidar com esse tipo de problema quando ele está tentando
fazer a descoberta e análise de requisitos além disso nós temos mais fatores políticos podem influenciar o equilíbrio do sistema gerentes podem exigir requisitos específicos para quê requisitos lhe permitam aumentar sua influência na organização então um determinado gerente pode falar eu quero que o sistema faça dessa forma porque ele sabe que num determinado momento e isso pode beneficiar de alguma forma o ambiente econômico empresarial no qual a análise ocorre é muito dinâmico então claro que mudanças vão ocorrer que é um tema que a gente já tratou em aulas anteriores é então claro que os requisitos a
prioridade importante do requisito vai acabar mudando novos requisitos podem surgir então nós acabamos tendo uma série de dificuldades nessa etapa de e licitação e análise dos requisitos bom os problemas existem nós temos que lidar com eles da melhor forma possível mas que os problemas existem que a gente fecha a empresa e vai para casa porque não dá para desenvolver software nós vamos tentar fazer da melhor forma possível obviamente para isso que existem as técnicas aos métodos ferramentas de apoio e aqui nós temos um modelo é de de processo para especificamente para a licitação e análise
de requisitos para essa primeira etapa da da engenharia de requisitos vamos tentar descobrir os requisitos e aí nós vamos analisar esses requisitos não é por isso que chama que de análise para classificados em organizá los uma vez que nós analisamos os requisitos que nós descobrimos classificamos organizamos vamos priorizar priorizá los e vamos fazer uma negociação desse que vídeos com os clientes que alguns podem ser inviáveis outros muitos custos com muito custo e aí sim uma vez que alguns requisitos podem até ter sido excluídos aqueles requisitos que foram mantidos e até mesmo priorizados vão passar para
a etapa seguinte que é a especificação de requisitos então se nós estamos falando da e licitação e análise de requisitos que a etapa número 1 podemos dizer que a e licitação propriamente ditta está aqui seria a 1.111 a análise está aqui seria a 1.2 e depois nós passamos para a próxima etapa que é a especificação e depois nós vamos ter a 3 que é a validação ok então por isso eu já falei para vocês antes que cada figura apresenta nomes diferentes organizações diferentes modelos diferentes e eu tento fazer um mapeamento para vocês mas nem sempre
isso é possível justamente para mostrar que nem sempre as mesmas etapas mesmas fases mesmos nomes são dados bom então a licitação a descoberta os requisitos propriamente dito a quem só está formalizado aquilo que eu já havia adiantado a descoberta em que eu já cheguei a comentar que nós podemos fazer por exemplo entrevista com os clientes usuários então o cliente usuário é a fonte da informação e pra eu obter a informação eu fui uma entrevista como uma ferramenta como uma técnica mas o cliente usuário não é única fonte de informação eu posso usar alguma documentação o
cliente usuário cliente me dê a documentação é um sistema bancário que um monte de documentação que o banco funciona a informação do do banco central como o banco funciona e eu vou estudar a documentação por exemplo eu vou alterar o sistema eu vou eu vou construir um sistema novo para substituir um outro sistema eu vou estender um sistema anterior pode pode ter documentação eu estudar essa documentação ou uma especificação de sistemas similares por exemplo então eu posso ter diferentes fontes de informação que vou me basear para descobrir os requisitos do sistema que eu vou over
ou estender e eu posso é ter diferentes técnicas e ferramentas a entrevista eu posso desenvolver protótipos para baseado nesses protótipos mostrar para os clientes e para usuários para obter mais informações eu posso escrever cenários que é muito parecido com a ideia do das histórias de usuários desse pew eu escrevo um cenário uma historinha falo e mostro para outro usuário e o usuário fala não quando tal coisa acontece então nesse caso tal coisa teria acontecido e não isso que você colocou nesse cenário é uma ideia de protótipo mas não é uma coisa executável é uma coisa
escrita atenas e evite a idéia também da observação ou a uma forma mais metodológica de dizer é democracia e mensal é exatamente a mesma coisa observação significa você e observar o trabalho da pessoa então do cliente o usuário então se você vai automatizar o processo que hoje é manual você vai lá observar como manualmente efeito você fica lá observando para saber como manualmente está sendo feito para daí você saber como você vai ter que automatizado que você vai desenvolver um sistema que automatiza aquilo a etnografia imersão é um pouco mais do que aquilo você vai
lá fazer o trabalho como se você fosse um dos funcionários um usuário que fazem aquilo seja manualmente já usando o sistema que você vai substituir são diferentes formas de alguma forma você conseguir descobrir conseguir levantar absorver os requisitos do sistema que você vai desenvolver então você vai tentar diz consultar diferentes clientes e usuários e não apenas um obviamente mais do que isso diferentes partes interessadas não apenas cliente usuário mas você pode ter você pode acabar conversando com pessoas que nem vão usar o sistema mas que conhece algum tipo de informação que ele é que ele
será útil no caso do sistema que ele está usando como exemplo é um sistema de gerenciamento de pacientes próprios pacientes de alguma forma podem ter alguma informação útil e é claro que você teria que ter muito cuidado em como abordar como conversar com esses pacientes principalmente porque eles são pacientes de saúde mental então você teria que ter um cuidado muito grande para abordar esses pacientes e conseguir informação a respeito disso aí teria uma questão ética da profissão enfim os médicos eu nem sei qual o médico talvez tivesse um acesso limitado ao sistema mas a parte
que ele tem você conversaria com eles enfermeiros recepcionistas são diferentes tipos de usuários usam diferentes partes do sistema a própria equipe do ipi que vai ser responsável por implantar e e e da manutenção desse sistema diferente de ética médica gerente de saúde que não vão usar o sistema mas que são responsáveis por parte do sistema tem que necessariamente ter como alguma regulamentação externa enfim são diferentes tipos de partes interessadas ou de uma palavra em inglês que às vezes a gente não traduzimos quando registrado no chão de partes interessadas bom há aqui um evento de um
cenário para a coleta do histórico médico nesse sistema basicamente um requisito que foi coletado é parecido com a história de usuário é dodô métodos ip mas que que pode ser feito também numa engenharia tradicional já era feito né não é exatamente a história do usuário mas é muito parecido então por exemplo aqui uma posição inicial paciente atendido em uma clínica médica por uma recepcionista ela gera um registro no sistema de coleta suas informações pessoais nome endereço idade etc como enfermeiro é conectado ao sistema de coleta histórico médico do paciente e aí se tudo der certo
nós temos um fluxo normal a enfermeira busca o paciente pelo sobrenome se houver mais de um paciente com o mesmo sobrenome enfim de tudo mas é alguma coisa pode dar errado prontuário do paciente não existe não pode ser encontrar ver o que ela vai fazer e aí em paralelo enquanto a informação está sendo inserido registro pode ser consultado e aí no final usuário está conectado prontuário do paciente é inserido no banco de dados enfim você tem aqui uma situação do que pode ser feito um determinado cenário inclusive se tudo der certo ou alguma coisa que
pode dar errado é uma forma de você representa um requisito do sistema é uma outra forma que são os casos de uso da um dos diagramas da linguagem 1 ml que eu já havia adiantado lá atrás eu acho que inclusive em outra aula que é um dos primeiros diagrama da linguagem ml que tem mais de 10 diagramas nós vamos usar muito por ser a linguagem padrão de fato usada pra a especificação de requisitos análise e modelagem e análise de projeto de engenharia de software tradicional e esse basicamente é o tipo de diagramas que vocês vão
usar para essa primeira parte do projeto da disciplina de vocês vocês vão encontrar mais informações no sistema água aqui é um modelo bastante simplificado vou colocar mais informações no sistema e vocês vão ter acesso para pra poder a estudar mais a respeito desse tipo de diagrama mas enfim basicamente você tem os atores que são os papéis quem pode usar o sistema exemplo aqui não vai ter sistema que vocês vão trabalhar aqui é o evento então quem pode usar o o sistema de gerenciamento de pacientes enfermeira recepcionista médico e os gerentes o que cada uma quais
são as funcionalidades que cada uma dessas pessoas fazem o recepcionista pode registrar paciente o recepcionista pode ver informações pessoais que o gerente também pode o gerente além de informações pessoais pode reportar estatísticas gerar relatórios que é algo que o relato médico também pode tanto o médico quanto enfermeira o euro pode ver regista registro mas só um médico pode agendar consulta enfim uma forma de representar de uma forma alto nível através de um diagrama quem são os papéis e o que quais são as funcionalidades que eles podem fazer existem outros elementos neste diagrama que não estão
representados aqui já adiantando vocês existem alguns tipos de de funcionalidades que há alguns elementos que são algumas algumas ligações são pontilhadas que indicam extensões inclusões que é um tipo de reuso de de caso de uso esses são os casos de uso que dá o nome ao diagrama e é uma forma de reaproveitar a informação sem ter que duplicar é uma coisa muito usado na área de computação e vocês vão poder ter acesso a mais detalhes a respeito desse diagrama e depois cada um desses casos de uso aqui por exemplo de registro como é que detalha
o registro aí você faz um documento à parte que é chamado a especificação de caso de uso para você fazer esse documento cada um desses vai ter um você faz através de um documento com portuguesa estruturado esse documento com portuguesa estruturado eu vou passar também o template pra vocês verem o documento basicamente o trabalho de vocês do projeto primeira parte do projeto vai ser eu vou passar um sistema para vocês vocês vão saber especificação de requisitos usando o diagrama de casos de uso ea educação de casos de uso para cada caso de uso que vocês
vão desenvolver uma definição do caso de uso agendar consulta que é esse aqui então isso que eu falei que vocês vão fazer aqui o que é um documento um português estruturado aqui está muito mais simplificado no projeto de vocês vai ser mais estruturado mais completo aqui é basicamente um documento muito uma decisão muito simples pode poderia ser uma possibilidade do projeto de vocês vai ser mais detalhado aqui um modelo de como pode ser feita então a etnografia que é a ovelha que se ficou a imersão total atenção e inclusão a inversão envolver tanto a imersão
quanta prototipação então você faz uma análise etnógrafo você se envolve faz uma imersão depois que em algum momento você faz é antecipação do sistema envolve faz as duas coisas e fica um tempo imerso na organização você usa essa informação para depois desenvolver um protótipo do sistema usando duas coisas para tentar coletar os requisitos do sistema bom com isso então nós finalizamos essa parte de a especificação de requisitos ou desculpa é e licitação de requisitos e análise de requisitos nós já tínhamos na anterior coberto a especificação de requisitos que a etapa que vêm na seqüência na
próxima aula a gente fecha com avaliação de requisitos uma vez que a gente coletora e vídeos com o cliente agente especificou colocando isso em um documento as mostras sobre o cliente que o cliente vai nos ajudar a validar aquilo e de ver oque é isso ou não precisa de ajustes obrigado [Música] a mãe [Música] [Música] [Música] [Música]
