[Música] lomba lá o professor marcelo sant nato esta disciplina de engenharia de software do curso de engenharia da computação da univesp vamos começar agora com a aula número finco essa semana nós vamos tratar quatro aulas relacionadas ao tema engenharia de requisitos que é a primeira etapa primeira grande etapa dentro do processo de engenharia de software a nossa primeira aula nós vamos então começar com uma visão geral de requisitos de software basicamente nós vamos tratar então tipos de requisitos é bom a primeira coisa o que são requisitos de software a palavra requisitos é uma palavra genérica
nós usamos em diferentes contextos não falei em engenharia de software mas a gente usa como verbo requerer alguém quer alguma coisa pede um pedido requisitando um pedido uma requisição significa o que o cliente quer o cliente pede para que o software quer que que esteja dentro de um software por isso então a palavra é requisito e dentro da da engenharia de software como a primeira etapa tratar requisitos nós temos então que nós chamamos de engenharia de requisitos então percebi a gente está falando engenharia da computação dentro da engenharia de computação engenharia de software engenharia de
requisitos bom é e aí então pensando em termos de requisitos aqui só pra dar uma decisão um pouco mais sistemática são requisitos são definições do que o sistema ou software deve fazer oque serviços que ele oferece as restrições sobre seu funcionamento então três definições aqui que são complementares o que o software tem que fazer que ele tem que oferecer e também restrições sobre o seu funcionamento depois a gente vai ver que na verdade isso aqui pode ser dividido em duas coisas que a gente vai ver mais para frente o que ele deve fazer é oferecer
é uma coisa e as inscrições são outras coisas já adiantando é o que ele chama de funcional e não funcional evento funcional requisitado funcional bom uma outra definição aqui requisitos refletem as necessidades dos clientes que é o que já tinha adiantado que serve uma finalidade de determinada e aí então a gente tem a idéia de equipe engenharia de requisitos do inglês the guardian entende nível em que o processo de descobrir analisar e verificar e validar esses serviços ou restrições e aí o nível funcional e não funcionar a gente tem um nível de requisito de mais
alto nível e de mais baixo nível um requisito mais abstrato uma ideia bem geral do que é o que o cliente quer e um requisito mais detalhado uma coisa mais específica mais cuidadosa vai definindo com mais detalhes a ideia mais alto nível do usuário ea ideia mais baixo nível mais detalhado a gente chama de sistema o usuário normalmente é feito em linguagem natural ou seja português um texto escrito em português assim o cliente cliente em português mesmo pode até ter um desenho diagrama para ajudar a entender o que o cliente quer então basicamente quatro serviços
que o que o sistema deverá fornecer com as restrições é dito de restrições bom e aí mais detalhado que são requisitos do sistema já é oficialmente chamado da especificação de requisitos mas sendo mais por isso né deve definir exatamente o que deve ser implementado então o engenheiro o desenvolvedor ele deveria olhar para os requisitos do sistema e não os requisitos do usuário o usuário serve pra gente fazer o sistema mas é o sistema do sistema que vai ser usado para que o sistema seja projetado e depois de implementado e é esse requisito no sistema que
podem fazer parte do contrato claro o que o cliente quer ver o que vai ser desenvolvido então olha aqui para pegar um exemplo um pensando num sistema que vai ser usado vai aparecer como exemplo aqui mais para frente é um sistema que vai aparecer sempre com essa sigla em outras vídeo aulas ainda mh cpmf que é a sigla do sistema inglês que é um sistema de gerenciamento de pacientes em cuidados de saúde mental então vamos pensar que existe um sistema de um hospital uma clínica médica e esse tema faz o gerenciamento de pacientes que toma
faz uma clínica de tratamento de saúde mental desses clientes desses pacientes então pensando nesse sistema que vai fazer esse gerenciamento de pacientes um requisito de usuários seria o sistema deve gerar relatórios gerenciais mensais que mostrem o custo dos medicamentos prescritos por cada clínica durante aquele mês isso é um requisito alto nível agora vamos detalhar esse requisito o como é que o sistema vai fazer isso como é que o sistema vai gerar relatórios mensais que morre no custo dos medicamentos prescritos por cada clínica durante o mês aí olha que foi quebrado em cinco requisitos no último
dia de cada útil de cada mês deve ser gerado um resumo dos medicamentos prescritos e os custos e as prescrições após às 17 horas e 30 no último mês do último dia o sistema deve gerar automaticamente o relatório para impressão um relatório será criado para casa clínica e tanto os nomes dos medicamentos aqui falar medicamento que já está claro que é o nome do medicamento aqui falava que era mensal que já disse que no último dia às 17 30 o número total de prescrições número de doses prescritas do custo total dos medicamentos os medicamentos estão
disponíveis em diferentes unidades de dosagem por exemplo 10 miligramas 20 miligramas devem ser criados relatórios separados para cada unidade o acesso aos relatórios de custos devem ser restritos aos usuários automatizados por uma lista de controles gerenciais de acesso enfim uma coisa que parecia ser muito simples quando o cliente pediu na verdade conversar melhor com ele tirando mais informação entrevistando olhando o detalhamento virou isso aqui olha e isso então é o que realmente precisa fazer então isso é o que ele chama de um detalhamento maior que é o que a gente chama de requisitos do sistema
o requisito de usuário e ele vai servir pra uns gerente um cliente o usuário final quem está contratando um arquiteto de sistema alguns papéis que querem ter uma visão alto nível do sistema agora o requisito do sistema ele vai servir principalmente para um desenvolvedor de software ou alguns outros papéis que precisam ter um detalhamento do sistema então ambos os tipos de requisitos são importantes porém para diferentes tipos de papéis o outro tipo de classificação já havia adiantado são requisitos funcionais e requisitos não funcionais tanto requisitos do usuário quanto de sistemas podem ser funcionais ou não
funcionais eu já havia adiantado mas requisitos funcionais é o que o sistema deve fazer ok então a quais as funcionalidades quais os serviços como o sistema deve reagir a entrada se você dá a tal informação é um sistema o que ele deve retornar à então se você tem uma função que calcula uma função que vai tratar da previsão do tempo então se você diz qual é o dia que você quer a prisão ela vai retornar a previsão em termos de chuva de umidade do ar vai tentar ou não como vai estar o índice uv ao
bebê enfim qual a funcionalidade qual serviço que ele vai fazer ok então isso é o que ele chama de requisitos funcionais são a declaração de como o sistema deve se comportar com o comportamento em determinadas situações inclusive você pode dizer o que o sistema não deve fazer então é a funcionalidade propriamente dita do sistema quais são as funcionalidades que ele te dá agora os requisitos não funcionais são restrições a esse serviço não funções ou seja ok uma coisa é o que o sistema vai saber mais sobre quais restrições por exemplo em termos de tempo eu
quero que o sistema mmi de a previsão do tempo em no máximo três segundos isso é um requisito não funcional uma restrição de tempo ou uma restrição no processo de desenvolvimento o sistema tem que ser desenvolvido necessariamente usando orientação a objetos é um outro tipo de restrição ou uma reflexão em porta em porta por normas o sistema tem que ser necessariamente tem que necessariamente pegando o exemplo que eu pensei aqui na hora mas necessariamente ele tem que dar a informação em graus celsius e em faro e night porque são as duas internacionalmente aceitas por exemplo
chegaria ser uma norma mas uma norma de fato geralmente ela se aplica um sistema como um todo por exemplo o sistema tem que ter um nível x e segurança às pessoas é preciso autenticar para usar o sistema como um todo geralmente então esses requisitos não funcionais ele se aplica um sistema como um todo pegando aqui de novo aquele exemplo do sistema que faz o gerenciamento de pacientes alguns exemplos de requisitos funcionais daquele sistema o usuário deve ser capaz de pesquisar as listas de agendamentos para todas as clínicas então usuário no caso o secretário ele deve
ser capaz de pesquisar lista de agendamento isso é uma capacidade uma funcionalidade um serviço que o sistema deve oferecer um outro o sistema deve a gerar a cada dia para cada clínica a lista dos pacientes para as consultas naquele dia um outro cada membro da equipe que usa a o sistema deve ser identificado apenas por seu número de oito dígitos então são alguns requisitos funcionais para aquele evento especificamente aqui falando sobre requisitos não funcionais a gente tem dado algum evento lá tempo requisitos legais mas na verdade existem diversos tipos de requisitos não funcionais o de
tem porque eu tinha falado ele é um requisito de desempenho ok que por sua vez é um requisito de deficiência que por sua vez é um requisito de produto mas um outro tipo de produto e eficiência é do espaço você pode ver que o sistema tem preocupado o máximo tanto de espaço no no sistema um arquivo os arquivos produzidos para aquele sistema tem que ocupar no máximo tanto de espaço você pode ter um produto organizacionais externo de produtos habilidade então dizer que um que o sistema tem que ser desenvolvido seguindo uma determinada norma de usabilidade
por exemplo externo você pode ter um requisito ético você pode ter um requisito legal por exemplo tem que necessariamente estar de acordo com uma do banco central por exemplo enfim aqui tem alguns exemplos é não é uma uma listagem exaustiva você pode ter outro tipo de requisitos não funcionais que eles dizem como os requisitos funcionais algum tipo de restrição em relação aos requisitos funcionais e não funcionais em cima do sistema de gestão de pacientes então por exemplo um requisito não funcional de produto o sistema deve estar disponível para todas as clínicas durante as horas normais
de trabalho de segunda festa do avante 30 17 30 período de na operação dentro do horário normal de trabalho não pode exceder cinco segundos em um dia isso é um requisito de disponibilidade está sendo dito que em horário de trabalho no horário é de dia útil horário útil o sistema pode ficar no máximo 5 segundo fora do ar não funcional um outro requisito requisito não funcional organizacional usuários do sistema devem se autenticar com seus cartões de identificação da autoridade da saúde é o tema é um requisito não funcional de segurança e um requisito não funcional
externo o sistema deve implementar as disposições de privacidade dos pacientes tal como estabelecido nessa norma que existe uma norma h traço de privacidade alguma regulamentação que diz que os pacientes têm direito à privacidade do sistema tem que garantir algumas métricas funcionais em geral funcionais eles são em termos de uma métrica por exemplo o tamanho que eu falei o tamanho do sistema o que o arquivo vai ocupar no sistema por exemplo em megabytes por exemplo algum tipo de deficiência velocidade você vai medir em transações por segundo em tempo de atualização da tela em termos de usabilidade
e facilidade de uso quanto tempo você precisa de treinamento do usuário quantos você precisa de métricas para alguns eventos de funcionalidade de um funcionário com isso então a gente viu uma visão geral sobre requisitos vimos alguns requisitos de mais alto e mais baixo nível que são requisitos de usuário requisitos de sistema e também requisitos funcionais e requisitos não funcionar a partir da próxima aula então a gente começa a ver as etapas de da engenharia de requisitos desde a espécie da da licitação descoberto requisitos passando pela especificação e chegando na validação do requisito obrigado [Música] [Música]
[Música] [Música]
