·
Análise de Sistemas ·
Outros
Send your question to AI and receive an answer instantly
Preview text
Senac Modelagem de Sistemas de Informação Bacharelado em Sistemas de Informação Profª Claudia Bianchi Progetti claudiabprogettispsenacbrclaudiaprogettihotmailcom Aula Engenharia de Requisitos de sistemas Requisitos Funcionais e NãoFuncionais Requisitos Requisitos Engenharia de requisitos Requisitos de sistemasoftware Descrições do que o sistemasoftware deve fazer os serviços que ele oferece as restrições sobre seu funcionamento Refletem as necessidades dos clientes que servem a uma finalidade determinada Engenharia de requisitos Requirements engineering processo de descobrir analisar documentos verificar e validar esses serviços e restrições Níveis de requisitos Nível de requisito varia Declaração abstrata alto nível requisito de usuário Definição detalhada baixo nível requisito de sistema Níveis de requisitos Requisito de usuário Linguagem natural podendo ser apoiado por diagramas Quais serviços o sistema deverá fornecer a seus usuários Quais restrições com as quais o sistema deverá operar Requisitos de sistema Costuma ser chamado de especificação de requisitos Deve definir exatamente o que deve ser implementado Pode ser parte do contrato entre compradordesenvolvedores Sommerville 2019 MHCPMS Mental Health Care Patient Management System FIGURA 42 Leitores dos diferentes tipos de especificação de requisitos Tipos de requisitos Requisitos funcionais Requisitos não funcionais Tipos de requisitos Requisitos funcionais Declarações de serviços que o sistema deve fornecer Declarações de como o sistema deve reagir a entradas específicas Declarações de como o sistema deve se comportar em determinadas situações Declarações do que o sistema não deve fazer Tipos de requisitos Requisitos não funcionais Restrições aos serviços ou funções oferecidos pelo sistema Incluem restrições de tempo restrições no processo de desenvolvimento e restrições impostas por normas Geralmente aplicamse ao sistema como um todo Requisitos funcionais Exemplos sistema MHCPMS Um usuário deve ser capaz de pesquisar as listas de agendamentos para todas as clínicas O sistema deve gerar a cada dia para cada clínica a lista dos pacientes para as consultas daquele dia Cada membro da equipe que usa o sistema deve ser identificado apenas por seu número de oito dígitos TIPOS DE REQUISITOS NÃO FUNCIONAIS Exemplos de possíveis requisitos não funcionais do sistema Mentcare Requisito do produto O sistema Mentcare deve ficar disponível para todas as clínicas durante o expediente normal segundasexta 8h3017h30 O tempo que o sistema pode permanecer fora do ar no expediente normal não deve ultrapassar 5 segundos em qualquer dia Requisito organizacional Os usuários do sistema Mentcare devem se identificar usando o cartão de identificação de autorização de saúde Requisito externo O sistema deve implementar providências para a privacidade do paciente conforme estabelecido em HStan032006priv Métricas para especificar requisitos não funcionais Propriedade Métrica Velocidade Transações processadassegundo Tempo de resposta do usuárioevento Tempo de atualização da tela Tamanho Megabytesnúmero de chips de ROM Facilidade de uso Tempo de treinamento Número de quadros de ajuda Confiabilidade Tempo médio até a falha Probabilidade de indisponibilidade Taxa de ocorrência de falhas Disponibilidade Tempo para reiniciar após a falha Porcentagem de eventos causando falhas Probabilidade de corromper dados em uma falha Robustez Porcentagem de declarações dependentes do sistemaalvo Número de sistemasalvo Processos de Engenharia de Requisitos Sommerville 2019 Documento de requisitos Especificação de requisitos de software Declaração oficial do que os desenvolvedores devem implementar Essenciais em caso de empresas contratadas para desenvolvimento de software não aplicável em métodos ágeis Focar no O QUE e não no COMO Usuários de um documento de requisitos Estrutura de um documento de requisitos Estrutura de um documento de requisitos Especificação de requisitos Especificação de requisitos pode se referir a Documento de requisitos Atividade de elaboração do documento de requisitos FIGURA 411 Notações para escrever requisitos de sistema Notação Sentenças em linguagem natural Descrição Os requisitos são escritos usando frases numeradas em linguagem natural Cada frase deve expressar um requisito Linguagem natural estruturada Os requisitos são escritos em linguagem natural em um formulário ou template Cada campo fornece informações sobre um aspecto do requisito Notações gráficas Modelos gráficos suplementados por anotações em texto são utilizados para definir os requisitos funcionais do sistema São utilizados com frequência os diagramas de casos de uso e de sequência da UML Especificações matemáticas Essas notações se baseiam em conceitos matemáticos como as máquinas de estados finitos ou conjuntos Embora essas especificações inequívocas possam reduzir a ambiguidade em um documento de requisitos a maioria dos clientes não compreende uma especificação formal Eles não conseguem averiguar se ela representa o que desejam e relutam em aceitar essa especificação como um contrato do sistema discuteir essa abordagem no Capítulo 10 que aborda a dependabilidade do sistema FIGURA 412 Exemplos de requisitos do sistema de software da bomba de insulina 32 O sistema deve medir o nível de açúcar no sangue e fornecer insulina se for necessário a cada 10 minutos As variações do açúcar no sangue são relativamente lentas então é desnecessário medir com uma frequência maior a medição menos frequente poderia levar a níveis de açúcar sanguíneo desnecessariamente elevados 36 O sistema deve executar uma rotina de autoteste a cada minuto com as condições a serem testadas e as ações associadas definidas na Tabela 1 do documento de requisitos Uma rotina de autoteste pode descobrir problemas de hardware e software e alertar o usuário de que a operação normal pode ser impossível FIGURA 413 Especificação estruturada de um requisito para uma bomba de insulina Bomba de insulinaSoftware de controleSRS332 Função Computar a dose de insulina nível de açúcar seguro Descrição Computa a dose de insulina a ser fornecida quando o nível de açúcar atual estiver na zona segura entre 3 e 7 unidades Entradas Leitura atual do açúcar r2 as duas leituras anteriores r0 e r1 Fonte Leitura atual de açúcar do sensor Outras leituras da memória Saídas DoseComp a dose de insulina a ser fornecida Destino Laço de controle principal Ação DoseComp é igual a zero se o nível de açúcar estiver estável ou caindo ou se o nível estiver aumentando mas a taxa de crescimento estiver diminuindo Se o nível estiver aumentando e a taxa de crescimento também então a DoseComp é obtida pela divisão por 4 da diferença entre o nível atual e o nível anterior arredondando o resultado Se o resultado for arredondado para zero então a DoseComp é definida como dose mínima que pode ser fornecida ver Figura 414 Requer Duas leituras prévias para que a taxa de variação do nível de açúcar possa ser calculada Précondição O reservatório de insulina contém pelo menos a dose máxima permitida Póscondição r0 é substituída por r1 então r1 é substituída por r2 Efeitos colaterais Nenhum FIGURA 414 Especificação tabular do cálculo em uma bomba de insulina Condição Nível de açúcar em queda r2 r1 Ação DoseComp 0 Condição Nível de açúcar estável r2 r1 Ação DoseComp 0 Condição Nível de açúcar em alta e taxa de crescimento em queda r2 r1 r1 r0 Ação DoseComp 0 Condição Nível de açúcar em alta e taxa de crescimento estável ou em alta r2 r1 r2 r1 r1 r0 Ação DoseComp arredondar r2 r1 4 Se resultado arredondado 0 então DoseComp DoseMínima Sommerville 2019 Trabalho em Grupo 1 Com base na aula 3 que aborda os requisitos funcionais e nãofuncionais na Engenharia de Requisitos especifique um requisito funcional na abordagem tradicional do sistema trabalhado no exercício anterior 2 Pesquise sobre a modelagem ágil e especifique outra funcionalidade do sistema trabalhado no exercício anterior Histórias de usuário Desmistificando a escrita de User Story httpswwwdtidigitalcombrbloghistoriasdeusuario Bibliografia da Aula MEDEIROS E Desenvolvendo software com UML 20 definitivo Pearson 2004 SOMMERVILLE I Engenharia de software 10 ed São Paulo Pearson 2019 PFLEEGER S L Engenharia de software teoria e prática 2a ed Pearson 2004
Send your question to AI and receive an answer instantly
Preview text
Senac Modelagem de Sistemas de Informação Bacharelado em Sistemas de Informação Profª Claudia Bianchi Progetti claudiabprogettispsenacbrclaudiaprogettihotmailcom Aula Engenharia de Requisitos de sistemas Requisitos Funcionais e NãoFuncionais Requisitos Requisitos Engenharia de requisitos Requisitos de sistemasoftware Descrições do que o sistemasoftware deve fazer os serviços que ele oferece as restrições sobre seu funcionamento Refletem as necessidades dos clientes que servem a uma finalidade determinada Engenharia de requisitos Requirements engineering processo de descobrir analisar documentos verificar e validar esses serviços e restrições Níveis de requisitos Nível de requisito varia Declaração abstrata alto nível requisito de usuário Definição detalhada baixo nível requisito de sistema Níveis de requisitos Requisito de usuário Linguagem natural podendo ser apoiado por diagramas Quais serviços o sistema deverá fornecer a seus usuários Quais restrições com as quais o sistema deverá operar Requisitos de sistema Costuma ser chamado de especificação de requisitos Deve definir exatamente o que deve ser implementado Pode ser parte do contrato entre compradordesenvolvedores Sommerville 2019 MHCPMS Mental Health Care Patient Management System FIGURA 42 Leitores dos diferentes tipos de especificação de requisitos Tipos de requisitos Requisitos funcionais Requisitos não funcionais Tipos de requisitos Requisitos funcionais Declarações de serviços que o sistema deve fornecer Declarações de como o sistema deve reagir a entradas específicas Declarações de como o sistema deve se comportar em determinadas situações Declarações do que o sistema não deve fazer Tipos de requisitos Requisitos não funcionais Restrições aos serviços ou funções oferecidos pelo sistema Incluem restrições de tempo restrições no processo de desenvolvimento e restrições impostas por normas Geralmente aplicamse ao sistema como um todo Requisitos funcionais Exemplos sistema MHCPMS Um usuário deve ser capaz de pesquisar as listas de agendamentos para todas as clínicas O sistema deve gerar a cada dia para cada clínica a lista dos pacientes para as consultas daquele dia Cada membro da equipe que usa o sistema deve ser identificado apenas por seu número de oito dígitos TIPOS DE REQUISITOS NÃO FUNCIONAIS Exemplos de possíveis requisitos não funcionais do sistema Mentcare Requisito do produto O sistema Mentcare deve ficar disponível para todas as clínicas durante o expediente normal segundasexta 8h3017h30 O tempo que o sistema pode permanecer fora do ar no expediente normal não deve ultrapassar 5 segundos em qualquer dia Requisito organizacional Os usuários do sistema Mentcare devem se identificar usando o cartão de identificação de autorização de saúde Requisito externo O sistema deve implementar providências para a privacidade do paciente conforme estabelecido em HStan032006priv Métricas para especificar requisitos não funcionais Propriedade Métrica Velocidade Transações processadassegundo Tempo de resposta do usuárioevento Tempo de atualização da tela Tamanho Megabytesnúmero de chips de ROM Facilidade de uso Tempo de treinamento Número de quadros de ajuda Confiabilidade Tempo médio até a falha Probabilidade de indisponibilidade Taxa de ocorrência de falhas Disponibilidade Tempo para reiniciar após a falha Porcentagem de eventos causando falhas Probabilidade de corromper dados em uma falha Robustez Porcentagem de declarações dependentes do sistemaalvo Número de sistemasalvo Processos de Engenharia de Requisitos Sommerville 2019 Documento de requisitos Especificação de requisitos de software Declaração oficial do que os desenvolvedores devem implementar Essenciais em caso de empresas contratadas para desenvolvimento de software não aplicável em métodos ágeis Focar no O QUE e não no COMO Usuários de um documento de requisitos Estrutura de um documento de requisitos Estrutura de um documento de requisitos Especificação de requisitos Especificação de requisitos pode se referir a Documento de requisitos Atividade de elaboração do documento de requisitos FIGURA 411 Notações para escrever requisitos de sistema Notação Sentenças em linguagem natural Descrição Os requisitos são escritos usando frases numeradas em linguagem natural Cada frase deve expressar um requisito Linguagem natural estruturada Os requisitos são escritos em linguagem natural em um formulário ou template Cada campo fornece informações sobre um aspecto do requisito Notações gráficas Modelos gráficos suplementados por anotações em texto são utilizados para definir os requisitos funcionais do sistema São utilizados com frequência os diagramas de casos de uso e de sequência da UML Especificações matemáticas Essas notações se baseiam em conceitos matemáticos como as máquinas de estados finitos ou conjuntos Embora essas especificações inequívocas possam reduzir a ambiguidade em um documento de requisitos a maioria dos clientes não compreende uma especificação formal Eles não conseguem averiguar se ela representa o que desejam e relutam em aceitar essa especificação como um contrato do sistema discuteir essa abordagem no Capítulo 10 que aborda a dependabilidade do sistema FIGURA 412 Exemplos de requisitos do sistema de software da bomba de insulina 32 O sistema deve medir o nível de açúcar no sangue e fornecer insulina se for necessário a cada 10 minutos As variações do açúcar no sangue são relativamente lentas então é desnecessário medir com uma frequência maior a medição menos frequente poderia levar a níveis de açúcar sanguíneo desnecessariamente elevados 36 O sistema deve executar uma rotina de autoteste a cada minuto com as condições a serem testadas e as ações associadas definidas na Tabela 1 do documento de requisitos Uma rotina de autoteste pode descobrir problemas de hardware e software e alertar o usuário de que a operação normal pode ser impossível FIGURA 413 Especificação estruturada de um requisito para uma bomba de insulina Bomba de insulinaSoftware de controleSRS332 Função Computar a dose de insulina nível de açúcar seguro Descrição Computa a dose de insulina a ser fornecida quando o nível de açúcar atual estiver na zona segura entre 3 e 7 unidades Entradas Leitura atual do açúcar r2 as duas leituras anteriores r0 e r1 Fonte Leitura atual de açúcar do sensor Outras leituras da memória Saídas DoseComp a dose de insulina a ser fornecida Destino Laço de controle principal Ação DoseComp é igual a zero se o nível de açúcar estiver estável ou caindo ou se o nível estiver aumentando mas a taxa de crescimento estiver diminuindo Se o nível estiver aumentando e a taxa de crescimento também então a DoseComp é obtida pela divisão por 4 da diferença entre o nível atual e o nível anterior arredondando o resultado Se o resultado for arredondado para zero então a DoseComp é definida como dose mínima que pode ser fornecida ver Figura 414 Requer Duas leituras prévias para que a taxa de variação do nível de açúcar possa ser calculada Précondição O reservatório de insulina contém pelo menos a dose máxima permitida Póscondição r0 é substituída por r1 então r1 é substituída por r2 Efeitos colaterais Nenhum FIGURA 414 Especificação tabular do cálculo em uma bomba de insulina Condição Nível de açúcar em queda r2 r1 Ação DoseComp 0 Condição Nível de açúcar estável r2 r1 Ação DoseComp 0 Condição Nível de açúcar em alta e taxa de crescimento em queda r2 r1 r1 r0 Ação DoseComp 0 Condição Nível de açúcar em alta e taxa de crescimento estável ou em alta r2 r1 r2 r1 r1 r0 Ação DoseComp arredondar r2 r1 4 Se resultado arredondado 0 então DoseComp DoseMínima Sommerville 2019 Trabalho em Grupo 1 Com base na aula 3 que aborda os requisitos funcionais e nãofuncionais na Engenharia de Requisitos especifique um requisito funcional na abordagem tradicional do sistema trabalhado no exercício anterior 2 Pesquise sobre a modelagem ágil e especifique outra funcionalidade do sistema trabalhado no exercício anterior Histórias de usuário Desmistificando a escrita de User Story httpswwwdtidigitalcombrbloghistoriasdeusuario Bibliografia da Aula MEDEIROS E Desenvolvendo software com UML 20 definitivo Pearson 2004 SOMMERVILLE I Engenharia de software 10 ed São Paulo Pearson 2019 PFLEEGER S L Engenharia de software teoria e prática 2a ed Pearson 2004