o Olá sejam bem-vindos mais uma vez sobre o Seu Jorge Oliveira professor de computação do Instituto Federal de Roraima e estamos falando nessa disciplina sobre o conteúdo de análise projetos temos ainda no conteúdo de engenharia de requisitos nós vamos fazer uma outra abordagem tá sobre o mesmo tema bom que que a gente precisa entender né O que que é agenda de requisitos então ele é um dos primeiros passos né no processo de desenvolvimento sistemas Onde você está fazendo levantamento fazendo a construção do sistema e você se preocupa especificamente em relação a Quais as quais as
quais as funcionalidades que aquele sistema vai ter para isso nós temos a chamada engenharia de requisitos né Ela é novamente um ramo da engenharia de software que se preocupa com todo o processo de descobrir analisar documentar ver e as funcionalidades então desde ela se preocupa desde o momento em em fazer isso levantamento EA Campo buscar as quais requisitos quase funcionalidades deve verão se implementadas durante todo o processo até a documentação e a verificação se essas funcionalidades Estão realmente sendo implantadas e de maneira correta Tá certo a que a gente precisa entender né quando a gente
fala em requisitos a gente tem que associar os requisitos com principalmente a questão de funcionalidades tá ações do sistema Mas se a gente for pegar e querer esmiuçar melhor a gente vai ver que são serviços que o nosso sistema fornece tá ou que presta aos nossos usuários e que eles vão refletir as necessidades dos clientes né então o meu cliente ele precisa de algo e eu preciso entregar uma funcionalidade para atender aquela necessidade e logo eu tô tratando de um requisito de uma necessidade tá certo e aí ela vai ser transformar em uma funcionalidade uma
ação do sistema algo que o sistema irá executar irá fazer tá bom aí eu posso começar a desenvolver eu posso sair à implementando soft e sem antes me importar com desenvolvimento dos requisitos Claro que não né então eu preciso entender esse processo entender essa essa as técnicas Quais são os como classificar para eu poder então dar continuidade a gente costuma fazer a divisão mais formal em dois duas maneiras né os requisitos funcionais que eles dizem a o comportamento sistema sistemas ações indivíduos características ali então como o sistema deve agir e os requisitos não-funcionais Lembrando que
eles não são opostos tá o funcional não é o posto de não funcionar quando eu digo que e funcional quer dizer que não vai ser uma funcionalidade diretamente específica Tá mas vai ter mais a ver com as restrições sobre a maneira como os serviços serão oferecidos fornecidos e a gente vai associar questões de performance arquitetura desenvolvimento questões genéricas tá então ali o que que o sistema cuidado com a gente ia ser o que que você ama não deve fazer não são opostos tá lembrando que eu posso ter um sistema eu posso ter uma descrição funcional
só que na negativa né então quando digo que um exemplo consulta de dados em histórico e diferentes graus de Privilégio de administrador tá então que os tratando de privilégios de acesso enfim um exemplo não funcional a o tempo de resposta não deve ser inferior a 5 segundos aí que eu tô já tá tão tratando da questão de disponibilidade da questão de performance é que eu tô tratando de marca a segurança de controle de acesso e secretário também às vezes não é tão claro Porque dependendo do sistema esse requisito não funcional vai virar um funcional então
quando eu digo por exemplo de um sistema de segurança né ou e o que eu faço a questão de controle de acesso eu vou pegar aquele a crise nacional e os meus salão em vários pedacinhos eles vão acabar de servir antes funcionais né um exemplo de sistema de banco em que a segurança é muito tá muito valorizada eu vou ter requisitos de segurança funcionais tá enquanto que eu tenho outros sistemas que são os temas mais genéricos que não vão ter tanto impacto na utilização do sistema como todo eles vão ficar e como requisitos não-funcionais uma
questão por exemplo o tempo de carregamento de uma página ou de um processamento se esse tempo varia um pouco mais um pouco menos não vai ter tanto Impacto tá e pode ser executado das continuidade no sistema e quais são as principais diferenças e que a gente vai ver que os requisitos funcionais eles são mandatórios eu o sistema deve fazer ou então ele não deve fazer tal coisa a gente consegue implementar com os casos de uso que é uma o outro componente a gente vai estudar eles tratam da funcionalidade do produto são mais fáceis de descobrir
descobrir estão Associados a um verbo e uma ação na que juntamente com um é um pronome ali de algo que deve fazer é consultar histórico de clientes é calcular imposto de renda enfim a gente tem esses verbos e uma são e uma especificação que que é eles estão atreladas a lei o negócio né que a gente vai utilizar Os nacionais geralmente Nossa mundo olhos são atributos características do Sistema como tudo são propriedades na e características do produto mais difícil descobrir de maneira geral que não são tão claros a gente precisa entender o sistema com tudo
e são expectativas algo que você Bom dia que o sistema fizesse uma maneira geral tá beleza então a gente tem um aqui uma outra maneira de classificar que é em relação ao nível de abstração como é que você vai especificar mais alto nível menos alto nível mais detalhado não tão detalhado quando a gente vai fazer mais detalhado menos detalhado uma linguagem natural que a gente também vai utilizar diagrama as outras questões de visualização a gente tá falando os requisitos Soares quando a gente está falando de um nível de especificação mais bem detalhado tá a gente
está falando do nível de sistema tá requisitos de sistema aí são funcionalidades serviços restrições operações que a gente vai identificar um exemplo aqui um exemplo de requisito em questão de nível de abstração tá até fácil amplificada como a curva de aprendizagem rápida linguagem de programação de hoje do programa em português em inglês então PC bom aqui que a gente tá falando e é de uma maneira que um usuário ele vai entender tem que ser rápido Tem que ser fácil tem que ser em português né então você é consegue dizer que isso daqui usuário Unique são
nível de abstração tá compreensível tá mais fácil então a leitura desse aqui ligando você é um nível de usuário não que os equipe desenvolvimento mas não posso usar mas quando eu falo por exemplo aqui ó sistema redundante contra a herança a falhas Raid 5 né utilização de código aberto pega p mais kellynox eu já tô com os colocando termos técnicos e especificidades que já são mais utilizadas para os desenvolvimentos aqui é a questão da redundância na redundância é quando a gente fala em desenvolvimento sistemas de bancos de dados é backups aí você ter sistemas de
recuperação de informação Ah beleza então a gente fala da análise de requisitos como nos primeiros passos para fazer esse levantamento né de dados ela que se preocupa com a com o estar tá não é do do desenvolvimento de sistema Tá certo então quando a gente vai se preocupar o analista de sistemas analista de soft ele vai se preocupar em ir atrás de grupo de pessoas né que precisam aprender é preciso ter suas necessidades atendidas tá então ele vai lá atrás entre em contato com cliente com stakeholders né que é a palavra que a gente vai
vir aqui na frente significado então dos mitos é que os requisitos ele se modificam continuamente isso é verdade mas as mudanças podem ser facilmente acomodados porque o soft soft flexível e isso a gente já viu que não é verdade né Quanto mais tarde a gente fizesse alterações o restante mais gostoso é para gente adaptar o sistema então quando a gente fizer isso antes que a gente fizer ainda numa fase de levantamento de requisitos onde gente não tem o soft implementado onde a documentação já não está definida não temos tantas reuniões a gente dá então no
nível de formulação de projetos a gente consegue adequar melhor essas mudanças então o impacto ele varia de acordo com o tempo né então mais cedo menos impacto em questão de custo questão de desenvolvimento e tudo e quanto mais tarde mas maior custo Tá bom então a gente vê que a definição de requisitos vai uma fase que acontece lá no início né segundo esse modelo tradição lá quem vê né o somerville aí depois vem as fases de desenvolvimento integração testes evolução e atualização tá bom steak roads que é uma palavrinha muito comum nessa parte de desenvolvimento
de projetos e engenharia de software que a gente vai dizer que são as partes interessadas tá então as partes interessadas a opção envolvidos dentro do processo envolvimento de software e que precisam ou que vão ter alguma alguma algum Impacto né seja de maneira direta ou indireta se eu te repente tenho que um software ele vai tratar por exemplo de recursos humanos em que eu vou atingir diversas classes ali dos membros da minha da minha empresa vai ser todos todas as pessoas envolvidas eu vou precisar fazer cálculos de salário vou precisar fazer cálculo de aposentadoria e
de férias contabilização eu vou ver quem são os envolvidos naquele processo para que eu possa implementar sistema tá então de repente é o pessoal da contabilidade o pessoal de Recursos Humanos administração e a diretoria que vai ter acesso aos relatórios Então vou verificando Quem são os interessados Tá bom quem são as pessoas que vão mexer no sistema que as pessoas que vão receber relatórios e são as pessoas que precisam dar algum grau de satisfação da hora de colher requisitos e na hora de testar o sistema Já pode subir de repente a pessoa lá da portaria
que respeita a recepção não é um stronghold né não é um possível ter que o rodo porque não vai atingir diretamente a mas eu vou mas vai mexer em todos os membros todos os funcionários da empresa ok Eles vão ser usuários indiretos mas eles não vão ser usuários diretos talvez a gente não precisa ouvir e eles porque eles também não vão ter informações relevantes para fornecer né a nós desenvolvedores tá bom então a gente sabe que é difícil estabelecer ali o que que o sistema deve fazer ainda mais todo o processo no início né Aí
o exemplo aí pesquisa revela é indecisão então às vezes o usuário não sabe o que quer não tem contato não Tem experiência com desenvolvimento sistema e cabe a nós desenvolvedores facilitar esse processo tá bom entendido isso um pouco né do tipo de êxitos como eles são classificados vamos aqui ver alguns exemplos e fazer uma prática tá então primeiro teste aqui o primeiro exercício são requisitos que se aplicam frequentemente é o sistema como um todo indicando a restrição sobre os serviços funções né oferecidos pelo sistema então a gente viu que o que são requisitos Ok mas
eles eles frequentemente são do sistema como um todo então a gente vê o que a gente tem funcionais não-funcionais usuários do sistema de domínio tá onde domínio a gente não trabalha nesse vídeo específico a gente sabe que existe né então quando a gente tô falando de serviços tô falando de restrições e geralmente são características do produto como todo eu tô falando de requisitos não-funcionais tá próximo é a qual é a opção incorreta né na levando em consideração engenharia de requisitos requisitos de usuário expressam as necessidades do usuário nível alto de abstração gente vê o que
tá certinho né eu vou colocar numa linguagem mais simples beleza Tá correto a engenharia de requisitos é uma das primeiras atividades do processo de construção do sistema dependendo do nível do modelo de desenvolvimento adotado é querendo ou não a gente vai precisar fazer essa coleta Vou precisar que trabalhar questão de requisitos eu posso tar com o nome é com outra nomenclatura mais aqui também tá correto né aparentemente tá correto os habilidade portabilidade performance são exemplos de requisitos funcionais sistema né Será que são deixar aqui na dúvida né a mais de requisitos compreende as etapas de
elicitação validação registro de requisitos a gente viu que quando a gente está trabalhando análise de requisitos que são outros nomes que podem ser dados a mesma coisa a gente vê que lembra lá no começo que a gente falou que é todo o processo que é desde o levantamento até entregue validação verificação então Aqui também está aparentemente correto não é registrada documentação e a lista de requisitos é importante para definição da viabilidade do sistema de onde tá dizendo que como é que a gente faz a viabilidade do sistema né como é que você sistema vai dar
certo ou errado eu preciso dessa lista de requisitos ela é importante para dizer sistema vai funcionar vai ser eficaz vai ser efetivo eu não sei o que critério de validade viabilidade está trabalhando que mais se eu tivesse a lista de requisitos eu vou ter uma viabilidade sofre eu vou conseguir analisar sua viabilidade de maneira mais efetiva Creio que sim então a alternativa que menos se encaixa aqui é os habilidades portabilidade e performance são requisitos não-funcionais tá então a alternativa incorreta é assim próximo tem um pouquinho mais grande mas a gente vai ver algum tipo de
requisitos tá Pergunta a fao seguinte ou é correto afirmar que vamos ver aqui o sistema deverá m os horários de compras A cada 15 dias Ok isso aqui ó deverá verbo ondulatória o sistema irá permitir a visualização do campo valor não é só irá permitir então vejam que já é uma restrição não é uma uma obrigação também né só irá permitir tá o sistema deverá fornecer diariamente relatórios o sistema não poderá então uma obrigação que também não poderá excluir um fornecedor de cadastros o sistema não permitirá acesso a registros após as dezessete horas uma questão
de segurança que mais vamos ver que as opções a 15 são requisitos não-funcionais a princípio são todos requisitos não-funcionais eu não tô enxergando aqui o requisito que vai se aplicar um sistema como um todo uma característica como tudo apesar da gente ter que questão de segurança que geralmente são encaixadas em requisitos não-funcionais mas são são coisas muito específicas né é o controle de acesso a uma data tá um específico ao usuário isso não não se encaixa como um sistema como todo são todos os requisitos funcionais a princípio sim somente o requisito de 5 e não
funcional não umas cinco são requisitos funcionais dois e três não são todas igrejas nacionais não então aqui a princípio são todos os requisitos funcionais são obrigações são limitações são mandatórios tá não vejo aqui característica do sistema como tudo por último a gente tem aqui também para gente fazer uma análise né são requisitos funcionais e vamos ver quais são os requisitos funcionais o sistema deve fornecer telas apropriadas para o usuário ler os documentos dos documentos no repositório de documentos isso daqui de tela apropriada parece que é uma questão de usabilidade Tá bom mas vamos vamos aguardar
que pode ser como ele é muito específico na tela no de reprodução de documentos pode ser pode ser um requisito funcional vejo que não é tão claro dizer o que que é nacional que que é funcional o usuário deve ser capaz de fazer uma busca então é uma ação né uma funcionalidade em todo o conjunto inicial de banco de dados ou selecionar um subconjunto na base deles então aqui parece um requisito funcionar vou botar letra aqui para a gente entender melhor o sistema a interface do usuário deve ser implementada com um simples HTML sem frames
ou applets Java uma tecnologia um pouco antigo essa questão né não se utiliza mais a questão de applets Java e como fosse um um pluguinho um é um Java scripts em uma situação né a gente já não utiliza mais daqui é um flash da vida antigamente Flash né dificilmente a implantação aqui mas veja o que a interface do usuário deve ser feita de uma maneira simples Então passa e adequando-os tema como todo então aqui não funcionar à base de dados deve ser protegida para acesso apenas a pessoas autorizadas a que a gente também não está
definido né Quais são as pessoas os critérios e que geralmente a questão de segurança segurança não funcional tá desde ontem que aqui ó essas telas aqui apesar das parecerem de usabilidade né que seria alguma opcional Mas elas estão sendo muito específica só em relação a onde as vezes implementados então isso aqui acaba entrando como requisito funcional Então são requisitos funcionais e itens 1 bom e dois tá certo é só para gente fazer alguns testes fazer algumas comparações aqui exemplos tarde como a gente utiliza os requisitos fazer a classificação de eles Muito obrigado ter assistido até
que e até a próxima
