Capítulo 4 Engenharia de Requisitos 1

Transcrição

1 Capítulo 4 - Engenharia de Requisitos Capítulo 4 Engenharia de Requisitos 1

2 Assuntos abordados Requisitos funcionais e não-funcionais Processos de engenharia de requisitos Levantamento de requisitos Especificação de requisites Validação de requisites Mudança dos requisitos Capítulo 4 Engenharia de Requisitos 2

3 Engenharia de requisitos O processo de definir os serviços que um cliente exige de um sistema e as restrições sob as quais opera e é desenvolvido. Os requisitos de sistema são as descrições dos serviços do sistema e as limitações que são geradas durante o processo de engenharia de requisitos. Capítulo 4 Engenharia de Requisitos 3

4 O que é um requisito? Pode variar de uma declaração abstrata de alto nível de um serviço ou de uma restrição de sistema para uma especificação matemática funcional. Os requisitos podem servir uma dupla função Pode ser a base para uma proposta de um contrato - portanto, deve ser aberto à interpretação; Pode ser a base para o próprio contrato - portanto deve ser definido em detalhe; Ambas as declarações podem ser chamadas requisitos. Capítulo 4 Engenharia de Requisitos 4

5 Requisitos abstração Se uma empresa quer um contrato para um projeto de desenvolvimento de software de grande porte, deve definir as suas necessidades de forma suficientemente abstrata. Os requisitos devem ser escritos de forma que vários contratantes podem concorrer para o contrato, oferecendo, talvez, diferentes maneiras de atender às necessidades da organização cliente. Uma vez que um contrato foi adjudicado, o contratante deve escrever uma definição do sistema para o cliente com mais detalhes para que o cliente possa entender e validar o que o software vai fazer. Ambos os documentos podem ser chamados de documento de requisitos para o sistema. Capítulo 4 Engenharia de Requisitos 5

6 Tipos de requisitos Requisitos do utilizador Descrições em linguagem natural, mais diagramas de serviços do sistema e as suas restrições operacionais. Escrito para os clientes. Requisitos de sistema Um documento estruturado, estabelecendo descrições detalhadas das funções do sistema, serviços e restrições operacionais. Define o que deve ser implementado, assim pode ser parte de um contrato entre o cliente e o contratante. Capítulo 4 Engenharia de Requisitos 6

7 Necessidades dos utilizadores e do sistema Capítulo 4 Engenharia de Requisitos 7

8 Os leitores de diferentes tipos de especificação de requisitos Capítulo 4 Engenharia de Requisitos 8

9 Stakeholders do sistema Qualquer pessoa ou organização que é afetada pelo sistema de alguma maneira e que tem um interesse legítimo Tipos de partes interessadas Utilizadores finais Gestores do sistema Os proprietários do sistema Partes interessadas externas Capítulo 4 Engenharia de Requisitos 9

10 As partes interessadas no sistema Mentcare Pacientes cujas informações são registadas no sistema. Médicos que são responsáveis pela avaliação e tratamento dos pacientes. Enfermeiros que coordenam as consultas com médicos e que podem administrar alguns tratamentos. Recepcionistas que gerem as consultas dos pacientes. A equipa de TI que são responsáveis pela instalação e manutenção do sistema. Capítulo 4 Engenharia de Requisitos 10

11 As partes interessadas no sistema Mentcare Um gerente de ética médica, que deve garantir que o sistema atende às diretrizes éticas para o atendimento do paciente. Gestores de saúde que obtêm informações da gestão do sistema. Funcionários de registros médicos que são responsáveis por garantir que as informações do sistema podem ser mantidos e preservados, e que os procedimentos de registos foram correctamente executadas. Capítulo 4 Engenharia de Requisitos 11

12 Métodos ágeis e requisitos Muitos métodos ágeis argumentam que a produção de requisitos detalhados do sistema é um desperdício de tempo, porque requisitos mudam rapidamente. Assim, o documento de requisitos está sempre desatualizado. Métodos ágeis normalmente usam a engenharia de requisitos incremental e podem expressar requisitos como relatos dos utilizadores. Isto é prático para os sistemas de negócios, mas problemático para sistemas que requerem análise de pré-entrega (por exemplo, sistemas críticos) ou sistemas desenvolvidos por várias equipas. Capítulo 4 Engenharia de Requisitos 12

13 Requisitos funcionais e não-funcionais Capítulo 4 Engenharia de Requisitos 13

14 Requisitos funcionais e não-funcionais Requisitos funcionais Descrição de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como o sistema deve se comportar em situações particulares. Pode-se apresentar o que o sistema não deve fazer. Requisitos não funcionais Constrangimentos sobre os serviços ou funções oferecidas pelo sistema, tais como restrições de tempo, as limitações no processo de desenvolvimento, padrões, etc.. Muitas vezes se aplicam ao sistema como um todo, em vez de recursos ou serviços individuais. Requisitos de domínio Restrições sobre o sistema a partir do domínio de operação Capítulo 4 Engenharia de Requisitos 14

15 Requisitos funcionais Descrevem funcionalidades ou serviços do sistema. Dependem do tipo de software, dos utilizadores esperados e o tipo de sistema onde o software é usado. Requisitos funcionais do utilizador podem ser descrições de alto nível do que o sistema deve fazer. Requisitos funcionais do sistema devem descrever os serviços do sistema em detalhe. Capítulo 4 Engenharia de Requisitos 15

16 Sistema Mentcare: requisitos funcionais Um utilizador deve ser capaz de pesquisar as listas de consultas para todas as clínicas. O sistema deve gerar todos dia, para cada clínica, uma lista de pacientes que são esperados para as consultas naquele dia. Cada membro da equipa que usa o sistema deve ser unicamente identificado por seu número de funcionário de 8 dígitos. Capítulo 4 Engenharia de Requisitos 16

17 Imprecisão nos requisitos Os problemas surgem quando os requisitos funcionais não são definidos com rigor. Requisitos ambíguos podem ser interpretados de maneiras diferentes pelos programadores e utilizadores. Considere o termo 'Search' no requisito 1 intenção do utilizador - busca por um nome do paciente em todas as consultas, em todas as clínicas; Interpretação do programador - busca por um nome do paciente em uma clínica individual. O utilizador escolhe a clínica, em seguida procura. Capítulo 4 Engenharia de Requisitos 17

18 Integridade e consistência dis requisitos Em princípio, os requisitos devem ser completos e consistentes. Completo Eles devem incluir descrições de todas as instalações necessárias. Consistente Não deve haver conflitos ou contradições nas descrições dos recursos de sistema. Na prática, por causa do sistema e complexidade ambiental, é impossível produzir um documento de requisitos consistente e completo. Capítulo 4 Engenharia de Requisitos 18

19 Requisitos não funcionais Estes definem as propriedades do sistema e limitações, por exemplo, fiabilidade, tempo de resposta e os requisitos de armazenamento. As restrições são I / O da capacidade do dispositivo, representações de sistema, etc. Requisitos de processo podem também ser especificados impondo um determinado IDE, linguagem de programação ou método de desenvolvimento. Os requisitos não-funcionais podem ser mais críticos do que os requisitos funcionais. Se estes não forem atendidos, o sistema pode ser inútil. Capítulo 4 Engenharia de Requisitos 19

20 Tipos de requisitos não funcionais Capítulo 4 Engenharia de Requisitos 20

21 Implementação dos requisitos não-funcionais Requisitos não funcionais podem afetar a arquitetura geral de um sistema, em vez de componentes individuais. Por exemplo, para garantir que os requisitos são cumpridos, pode-se ter que organizar o sistema para minimizar a comunicação entre componentes. Um requisito não funcional único, como um requisito de segurança, pode gerar uma série de requisitos funcionais relacionados que definem os serviços do sistema que são necessários. Também pode gerar requisitos que restringem os requisitos existentes. Capítulo 4 Engenharia de Requisitos 21

22 Classificações não funcionais Requisitos do produto Requisitos que especificam como o produto entregue, se deve comportar por exemplo, velocidade de execução, confiabilidade, etc. Requisitos organizacionais Requisitos que são uma consequência de políticas e procedimentos organizacionais padrões, por exemplo processos utilizados, requisitos de aplicação, etc. Exigências externas Requisitos que surgem a partir de fatores que são externos para o sistema e os requisitos de interoperabilidade desenvolvimento do processo, por exemplo, exigências legislativas, etc. Capítulo 4 Engenharia de Requisitos 22

23 Exemplos de requisitos não funcionais no sistema Mentcare Requisitos do produto O sistema Mentcare deve estar disponível para todas as clínicas durante o horário normal de trabalho (Seg-Sex, 08: ). O tempo de inatividade dentro das horas normais de trabalho não deve exceder cinco segundos em qualquer dia. Requisito organizacional Utilizadores do sistema Mentcare deve autenticar-se usando o seu cartão de identidade de saúde. Exigência externa O sistema deve implementar as disposições de privacidade do paciente tal como estabelecido no HStan priv. Capítulo 4 Engenharia de Requisitos 23

24 Objetivos e requisitos Requisitos não funcionais podem ser muito difíceis de definir com rigor e requisitos imprecisos podem ser difíceis de verificar. Objetivo A intenção geral do utilizador tal como facilidade de uso. Requisito não funcional verificável Uma descrição usando alguma medida que pode ser objetivamente testada. Metas são úteis para programadores quando exprimem as intenções dos utilizadores do sistema. Capítulo 4 Engenharia de Requisitos 24

25 Os requisitos de usabilidade O sistema deve ser fácil de usar por pessoal médico e deve ser organizado de tal forma que os erros dos utilizadores sejam minimizados. (Objetivo) A equipa médica deve ser capaz de usar todas as funções do sistema depois de quatro horas de treinamento. Após este treinamento, o número médio de erros cometidos por utilizadores experientes não excederá dois por hora de uso do sistema. (Requisito não funcional Testável) Capítulo 4 Engenharia de Requisitos 25

26 Métricas para especificar requisitos não funcionais Propriedade Rapidez Tamanho Fácil de usar Confiabilidade Robustez portabilidade A medida transações processadas / segundo User / tempo de resposta por evento tempo de atualização do monitor Mbytes Número de chips de memória ROM Tempo de treino Número de pedidos de ajuda Tempo até a falha Probabilidade de indisponibilidade Taxa de ocorrência de falha Disponibilidade Tempo para reiniciar após falha Percentagem de eventos que levam à insuficiência Probabilidade de corrupção de dados em caso de falha Percentagem de declarações dependentes Número de sistemas de destino Capítulo 4 Engenharia de Requisitos 26

27 Processos de engenharia de requisitos Capítulo 4 Engenharia de Requisitos 27

28 Processos de engenharia de requisitos Os processos utilizados para engenharia de requisitos variam muito, dependendo do domínio de aplicação, as pessoas envolvidas e da organização que desenvolve os requisitos. No entanto, há uma série de atividades genéricas comuns a todos os processos Levantamento de requisitos; Análise de requisitos; A validação de requisitos; A gestão de requisitos. Na prática, engenharia de requisitos é uma atividade iterativa em que estes processos são intercalados. Capítulo 4 Engenharia de Requisitos 28

29 Uma visão espiral do processo de engenharia de requisitos Capítulo 4 Engenharia de Requisitos 29

30 Levantamento de requisitos Capítulo 4 Engenharia de Requisitos 30

31 Levantamento de requisitos e análise Envolve pessoal técnico a trabalhar com os clientes para descobrir sobre o domínio de aplicação, os serviços que o sistema deve fornecer e as restrições operacionais do sistema. Pode envolver utilizadores finais, gestores, engenheiros envolvidos na manutenção, especialistas de domínio, sindicatos, etc. Estes são chamados partes interessadas. Capítulo 4 Engenharia de Requisitos 31

32 Levantamento de requisitos Capítulo 4 Engenharia de Requisitos 32

33 Levantamento de requisitos Os engenheiros de software trabalham com uma variedade de stakeholders do sistema para obter informações sobre o domínio da aplicação, os serviços que o sistema deve fornecer, o desempenho do sistema necessárias, as restrições de hardware, outros sistemas, etc. Inclui as etapas: Descoberta de requisitos, Classificação e organização de requisitos. Priorização e negociação de requisitos, Especificação de requisitos. Capítulo 4 Engenharia de Requisitos 33

34 Problemas no levantamento de requisitos As partes interessadas não sabem o que eles realmente querem. Stakeholders expressam requisitos nos seus próprios termos. Diferentes partes interessadas podem ter requisitos conflituantes. Fatores organizacionais e políticas podem influenciar os requisitos do sistema. Os requisitos mudam durante o processo de análise. Novos stakeholders podem surgir e o ambiente de negócios pode mudar. Capítulo 4 Engenharia de Requisitos 34

35 Levantamento de requisitos e processo de análise Capítulo 4 Engenharia de Requisitos 35

36 atividades de processo Descoberta de requisitos Interagir com as partes interessadas para descobrir as suas necessidades. Os requisitos de domínio também são descobertos nesta fase. Classificação e organização dos requisitos Grupos de requisitos relacionados, organizam-se em grupos coerentes. Priorização e negociação Priorizar e resolver conflitos de requisitos. Especificação de requisitos Os requisitos são documentados. Capítulo 4 Engenharia de Requisitos 36

37 Descoberta de requisitos O processo de recolha de informações sobre os sistemas necessários e existentes, filtra-se as necessidades dos utilizadores. Interação com as partes interessadas do sistema, de gestores para reguladores externos. Sistemas normalmente têm uma gama de partes interessadas. Capítulo 4 Engenharia de Requisitos 37

38 Entrevistar Entrevistas formais ou informais com as partes interessadas são parte da maioria dos processos de engenharia de requisitos. Tipos de entrevista entrevistas fechadas com base em lista pré-determinada de perguntas. entrevistas abertas, onde vários assuntos são explorados com as partes interessadas. Entrevista eficaz Ter uma mente aberta, evitar idéias pré-concebidas sobre os requisitos e sempre dispostos a ouvir as partes interessadas. Induzir os entrevistados para obter discussões, usar uma pergunta trampolim, uma proposta de requisitos, ou trabalhar em conjunto em num sistema protótipo. Capítulo 4 Engenharia de Requisitos 38

39 Entrevistas na prática Normalmente, uma mistura de entrevistas fechadas e open-ended. Entrevistas são boas para obtenção de um entendimento geral do que os stakeholders fazem e como eles podem interagir com o sistema. Entrevistadores precisam ter a mente aberta, sem ideias pré-concebidas sobre o que o sistema deve fazer Falar do uso do sistema, sugerir requisitos em vez de simplesmente pedir-lhes o que eles querem. Capítulo 4 Engenharia de Requisitos 39

40 Problemas com entrevistas Os especialistas da aplicação pode usar uma linguagem para descrever o seu trabalho que não é fácil para o engenheiro de requisitos entender. Entrevistas não são boas para a compreensão de requisitos de domínio Os engenheiros de requisitos não podem entender a terminologia específica do domínio; Alguns conhecimentos de domínio são tão familiares que as pessoas acham difícil de articular ou pensam que não vale a pena articulação. Capítulo 4 Engenharia de Requisitos 40

41 Histórias e cenários Cenários e histórias dos utilizadores são exemplos da vida real de como um sistema pode ser usado. Histórias e cenários são uma descrição de como um sistema pode ser usado para uma determinada tarefa. São baseados numa situação prática, as partes interessadas podem se relacionar com eles e podem comentar sobre a situação no que diz respeito à história. Capítulo 4 Engenharia de Requisitos 45

42 Cenários Uma forma estruturada da história do utilizador Cenários devem incluir Uma descrição da situação de partida; A descrição do fluxo normal de eventos; Uma descrição do que pode dar errado; Informações sobre outras atividades concorrentes; A descrição do estado quando o cenário terminar. Capítulo 4 Engenharia de Requisitos 47

43 Especificação de requisitos Capítulo 4 Engenharia de Requisitos 50

44 Especificação de requisitos O processo de escrita das necessidades dos utilizadores e do sistema num documento de requisitos. Necessidades dos utilizadores têm de ser compreensível por utilizadores finais e clientes que não têm uma formação técnica. Os requisitos do sistema são requisitos mais detalhados e podem incluir mais informações técnicas. Os requisitos podem ser parte de um contrato para o desenvolvimento do sistema Portanto, é importante que estes sejam tão completos quanto possível. Capítulo 4 Engenharia de Requisitos 51

45 Maneiras de escrever uma especificação de requisitos do sistema Notação Linguagem natural Linguagem estruturada Linguagem descrição natural Notações gráficas Especificações matemáticas de Descrição Os requisitos são escritos usando frases numeradas em linguagem natural. Cada frase deve expressar uma exigência. Os requisitos são escritos em linguagem natural num formulário padrão ou modelo. Cada campo fornece informações sobre um aspeto da exigência. Esta abordagem utiliza uma linguagem como uma linguagem de programação, mas com recursos mais abstratos para especificar os requisitos através da definição de um modelo operacional do sistema. Esta abordagem agora é raramente usado, embora possa ser útil para especificações de interface. Modelos gráficos, complementados por anotações de texto, são utilizadas para definir os requisitos funcionais para o sistema; casos de uso UML e diagramas de sequência são comumente usados. Estas notações são baseadas em conceitos matemáticos tais como máquinas de estados finitos ou conjuntos. Embora estas especificações não ambíguas podem reduzir a ambiguidade em um documento de requisitos, a maioria dos clientes não entendem uma especificação formal. Eles não podem verificar se esta representa o que eles querem, assim estão relutantes em aceitá-lo como um contrato de sistema Capítulo 4 Engenharia de Requisitos 52

46 Requisitos e projeto Em princípio, requisitos devem definir o que o sistema deve fazer e o projeto deve descrever como ele faz isso. Na prática, requisitos e projeto são inseparáveis A arquitetura do sistema pode ser concebido para estruturar os requisitos; O sistema pode interoperar com outros sistemas que geram requisitos de projeto; O uso de uma específica arquitetura para satisfazer os requisitos não-funcionais, pode ser um requisito de domínio. Capítulo 4 Engenharia de Requisitos 53

47 Especificação em linguagem natural Requisitos são escritos como frases em linguagem natural complementadas por diagramas e tabelas. Usado para escrever requisitos porque é expressivo, intuitivo e universal. Isto significa que os requisitos podem ser entendidos por utilizadores e clientes. Capítulo 4 Engenharia de Requisitos 54

48 Diretrizes para escrever requisitos Inventar um formato padrão e usá-lo para todas as exigências. Usar uma linguagem de forma consistente. Use o realce de texto para identificar as partes principais do requisito. Incluir uma explicação (lógica) de por que um requisito é necessário. Capítulo 4 Engenharia de Requisitos 55

49 Problemas com linguagem natural A falta de clareza A precisão é difícil sem tornar o documento difícil de ler. Requisitos confusos requisitos funcionais e não-funcionais tendem a ser confuso. Fusão de requisitos Vários requisitos diferentes podem ser expressos em conjunto. Capítulo 4 Engenharia de Requisitos 56

50 Exemplo requisitos para o sistema de software da bomba de insulina 3.2 O sistema deve medir o açúcar no sangue e injetar insulina, se necessário, a cada 10 minutos. 3.6 O sistema devem executar uma rotina de autoteste a cada minuto com as condições a serem testadas e as ações associadas definidas na Tabela 1. (A rotina de autoteste pode descobrir problemas de hardware e software e alertar o utilizador para o fato da operação normal poder ser impossível.) Capítulo 4 Engenharia de Requisitos 57

51 Especificações estruturadas Uma abordagem para escrever requisitos, onde a liberdade da escrita é limitada e os requisitos são escritos de uma forma padrão. Isso funciona bem para alguns tipos de requisitos, por exemplo para sistemas de controle integrado, mas às vezes é demasiado rígida para escrever requisitos do sistema empresarial. Capítulo 4 Engenharia de Requisitos 58

52 Especificações baseadas em formulário Definição da função ou entidade. Descrição das entradas e de onde eles vêm. Descrição das saídas e onde eles vão. Informações sobre as informações necessárias para o cálculo e outras entidades. Descrição da ação a tomar. Condições pré e pós (se for o caso). Os efeitos colaterais (se for o caso) da função. Capítulo 4 Engenharia de Requisitos 59

53 Uma especificação estruturada de um requisito de uma bomba de insulina Capítulo 4 Engenharia de Requisitos 60

54 Uma especificação estruturada de um requisito de uma bomba de insulina Capítulo 4 Engenharia de Requisitos 61

55 Especificação tabular Usado para complementar a linguagem natural. Particularmente útil quando se tem que definir uma série de possíveis fluxos de ação alternativos. Por exemplo, os sistemas de bomba de insulina baseiam os seus cálculos sobre a taxa de variação do nível de açúcar no sangue e a especificação tabular explica como calcular a necessidade de insulina para diferentes cenários. Capítulo 4 Engenharia de Requisitos 62

56 Especificação tabular de cálculo, para uma bomba de insulina Condição Açao Nível de açúcar baixo (r2 <R1) CompDose = 0 Nível de açúcar estável (R2 = R1) CompDose = 0 Nível de açúcar aumentando e diminuindo a taxa de aumento ((R2 - r1) <(R1 - r0)) Nível de açúcar aumentando e ritmo de aumento estável ou aumentando ((R2 - r1) (R1 - r0)) CompDose = 0 CompDose = volta ((R2 - R1) / 4) Se arredondado resultado = 0 então CompDose = MinimumDose Capítulo 4 Engenharia de Requisitos 63

57 Os casos de uso Os casos de uso são um tipo de cenário que estão incluídos no UML. Os casos de uso identificam os atores numa interação e descrevem a interação em si. Um conjunto de casos de uso deve descrever todas as possíveis interações do sistema. Diagramas de sequência UML podem ser usados para adicionar detalhes aos casos de uso, mostrando a sequência de processamento de eventos no sistema. Capítulo 4 Engenharia de Requisitos 64

58 Os casos de uso para o sistema Mentcare Capítulo 4 Engenharia de Requisitos 65

59 Documento dos requisitos de software O documento dos requisitos de software é a declaração oficial do que é exigido dos programadores do sistema. Deve incluir tanto uma definição de requisitos de utilizador, como uma especificação dos requisitos do sistema. Não é um documento de design. Na medida do possível, deve definir o que o sistema deve fazer ao invés de como ele deve fazer isto. Capítulo 4 Engenharia de Requisitos 66

60 Os utilizadores de um documento de requisitos Capítulo 4 Engenharia de Requisitos 67

61 Variabilidade do documento de requisitos Informações no documento de requisitos dependem do tipo de sistema e a abordagem de desenvolvimento usado. Sistemas desenvolvidos de forma incremental vai, normalmente, com menos detalhes no documento de requisitos. Normas foram concebidas por exemplo, padrão IEEE. Estes são principalmente aplicável aos requisitos para grandes projetos de engenharia de sistemas. Capítulo 4 Engenharia de Requisitos 68

62 A estrutura de um document de requisitos Capítulo Prefácio Introdução Glossário Definição de requisitos de utilizador Descrição Isto deve definir o número de leitores esperado do documento e descrever o seu histórico de versões, incluindo uma justificativa para a criação de uma nova versão e um resumo das alterações feitas em cada versão. Esta secção deve descrever a necessidade do sistema. Deve descrever brevemente as funções do sistema e explicar como vai funcionar com outros sistemas. Também deve descrever como o sistema se encaixa nos objetivos de negócios ou estratégicas globais da organização que pediu o software. Isto deve definir os termos técnicos utilizados no documento. Não deve fazer suposições sobre a experiência ou conhecimento do leitor. Aqui, descreve-se os serviços prestados para o utilizador. Os requisitos não funcionais do sistema também devem ser descritas nesta seção. Essa descrição pode usar a linguagem natural, diagramas, ou outras notações que são compreensíveis para os clientes. normas de produtos e processos que devem ser seguidos devem ser também especificados. Arquitetura do sistema Este capítulo deve apresentar uma visão geral de alto nível da arquitetura do sistema previsto, mostrando a distribuição das funções dos módulos do sistema. Componentes da arquitetura que são reutilizados devem ser destacadas. Capítulo 4 Engenharia de Requisitos 69

63 A estrutura de um documento de requisitos Capítulo Especificação de requisitos do sistema Modelos de sistemas Evolução do sistema Apêndices Índice Descrição Este deve descrever os requisitos funcionais e não-funcionais em mais detalhes. As interfaces com outros sistemas podem ser também definidos. Isto pode incluir modelos gráficos dos sistemas que mostram as relações entre os componentes do sistema e o seu ambiente. Exemplos de possíveis modelos são modelos de objeto, modelos de fluxo de dados, ou modelos de dados semânticos. Este deve descrever os pressupostos fundamentais em que o sistema se baseia, e quaisquer mudanças previstas, devido à evolução do hardware, mudança das necessidades dos utilizadores, entre outras. Esta seção é útil para projetistas de sistemas que possa ajudá-los a evitar decisões de design que restringem futuras prováveis mudanças no sistema. Estes devem fornecer informações detalhadas, específica que está relacionada com a aplicação que está a ser desenvolvida; para descrições exemplo, hardware e base de dados. Definir os requisitos de hardware, as configurações mínimas e ótimas para o sistema. Requisitos de base de dados definem a organização lógica dos dados utilizados pelo sistema e as relações entre os dados. Vários índices no documento podem ser incluídos. Bem como um índice alfabético normal, pode haver um índice de diagramas, um índice de funções, e assim por diante. Capítulo 4 Engenharia de Requisitos 70

64 A validação de requisitos Capítulo 4 Engenharia de Requisitos 71

65 A validação de requisitos Preocupação com o que demonstra que os requisitos definem o sistema que o cliente realmente quer. Custos de erros nos requisitos são altos então a validação é muito importante Corrigir um erro de requisitos depois da entrega pode custar até 100 vezes o custo de fixação de um erro de implementação. Capítulo 4 Engenharia de Requisitos 72

66 Controlo dos requisitos Validade. O sistema fornece as funções que melhor suporte às necessidades do cliente? Consistência. Há algum conflito de requisitos? Completude. Estão todas as funções exigidas pelo cliente? Realismo. Os requisitos podem ser implementados com o orçamento e tecnologia disponível. Verificabilidade. Os requisitos podem ser verificados? Capítulo 4 Engenharia de Requisitos 73

67 Técnicas de validação de requisitos Revisões de requisitos Análise manual sistemática dos requisitos. Prototipagem Usar um modelo executável do sistema para verificar requisitos. Geração de casos de teste Desenvolvimento de testes para requisitos, para verificar a sua capacidade de teste. Capítulo 4 Engenharia de Requisitos 74

68 Revisões de requisitos Comentários regulares devem ser feitos enquanto a definição de requisitos está a ser formulada. Cliente e utilizadores devem ser envolvidos nas revisões. Comentários podem ser formais (com documentos completos) ou informais. Boa comunicação entre programadores, clientes e utilizadores podem resolver problemas num estágio inicial. Capítulo 4 Engenharia de Requisitos 75

69 Verificações de revisão Verificabilidade É o requisito realista e testável? Compreensibilidade É o requisito entendido corretamente? Rastreabilidade É claro a origem do requisito? Adaptabilidade O requisito de ser alterado sem um grande impacto sobre outros requisitos? Capítulo 4 Engenharia de Requisitos 76

70 Mudança de requisitos Capítulo 4 Engenharia de Requisitos 77

71 Mudança dos requisitos O ambiente de negócios e a técnica do sistema sempre mudam após a instalação. Novo hardware pode ser introduzido, pode ser necessário fazer a interface do sistema com outros sistemas, as prioridades de negócios pode mudar (com as consequentes alterações no suporte ao sistema), e nova legislação e regulamentos podem ser introduzidos que o sistema deve necessariamente respeitar. As pessoas que pagam para um sistema e os utilizadores do sistema raramente são as mesmas pessoas. Clientes do sistema impoêm exigências devido a restrições organizacionais e orçamentais. Estes podem entrar em conflito com os requisitos do utilizador final e, após a entrega, novos recursos podem ter que ser adicionado para suporte ao utilizador. Capítulo 4 Engenharia de Requisitos 78

72 Mudança de requisitos Sistemas grandes geralmente têm uma comunidade de utilizadores diversificada, com muitos utilizadores com diferentes necessidades e prioridades que podem ser conflituantes ou contraditórios. Os requisitos finais de sistema são inevitavelmente um compromisso entre eles e, com a experiência, muitas vezes é descoberto que o equilíbrio de apoio dado a diferentes utilizadores tem que ser mudado. Capítulo 4 Engenharia de Requisitos 79

73 Evolução dos requisitos Capítulo 4 Engenharia de Requisitos 80

74 A gestão dos requisitos A gestão dos requisitos é o processo de gestão de mudanças de requisitos durante o processo de engenharia de requisitos e desenvolvimento do sistema. Novos requisitos emergem quando o Sistema está a ser desenvolvido e depois de ter entrado em uso. Precisa-se manter o controle das necessidades individuais e manter ligações entre os requisitos dependentes para que se possa avaliar o impacto das mudanças nos requisitos. Precisa-se estabelecer um processo formal para fazer propostas de mudança e ligando-os aos requisitos do sistema. Capítulo 4 Engenharia de Requisitos 81

75 Planeamento de gestão de requisitos Estabelece o nível de detalhe necessário para a gestão de requisitos. Decisões de gestão de requisitos: Identifdicação dos requisitos Cada requisito deve ser identificado exclusivamente para que possa ser cruzada com outros requisitos. Um processo de gestão de mudança Este é o conjunto de atividades que avaliam o impacto e o custo de mudanças. Políticas de rastreabilidade Estas políticas definem as relações entre cada requisite e entre os requisitos e o projeto do sistema. Ferramenta de suporte Ferramentas que podem ser utilizadas variam de sistemas de gestão de requisitos especializados para sistemas de base de dados simples. Capítulo 4 Engenharia de Requisitos 82

76 Gerir a mudança dos requisitos Decidir se uma mudança de requisitos devem ser aceite Análise do problema e especificação da mudança Durante esta fase, o problema ou a proposta de mudança é analisada para verificar se é válido. Análise e custo da mudança O efeito da mudança proposta é avaliada através de informações de rastreabilidade e conhecimentos gerais sobre os requisitos do sistema. Uma vez que esta análise é concluída, uma decisão é tomada se deve ou não prosseguir com a mudança dos requisitos. Implementação da mudança O documento de requisitos e, se necessário, a concepção e implementação do sistema, são modificados. Idealmente, o documento deve ser organizado de modo que as mudanças possam ser facilmente implementadas. Capítulo 4 Engenharia de Requisitos 83

77 Gerir a mudança dos requisitos Capítulo 4 Engenharia de Requisitos 84

78 Pontos chave Requisitos para um sistema de software definem o que o sistema deve fazer e definiem os constrangimentos ao seu funcionamento e implementação. Os requisitos funcionais são declarações dos serviços que o sistema deve fornecer ou são descrições de como alguns cálculos devem ser realizados. Requisitos não funcionais muitas vezes restringem o processo de desenvolvimento do sistema que está a ser desenvolvido e/ou está a ser usado. Eles muitas vezes se relacionam com as propriedades emergentes do sistema e, portanto, se aplicam ao sistema como um todo. Capítulo 4 Engenharia de Requisitos 85

79 Pontos chave O processo de engenharia requisitos é um processo iterativo que inclui levantamento de requisitos, especificação e validação. Levantamento de requisitos é um processo iterativo que pode ser representado como uma espiral de atividades - descoberta requisitos, classificação requisitos e organização, negociação de requisitos e documentação de requisitos. Pode-se usar uma variedade de técnicas para levantamento de requisitos, incluindo entrevistas, histórias de utilizadores e cenários podem ser usados para facilitar as discussões. Capítulo 4 Engenharia de Requisitos 86

80 Pontos chave Especificação de requisitos é o processo de formalmente documentar as necessidades dos utilizadores e do sistema e criar um documento de requisitos de software. O documento de requisitos de software é uma declaração acordada dos requisitos do sistema. Deve ser organizado para que os clientes do sistema e programadores possam usá-lo. Capítulo 4 Engenharia de Requisitos 87

81 Pontos chave A validação de requisitos é o processo de verificação dos requisites, de validade, consistência, integridade, realismo e verificabilidade. Mudanças no negócios, nas organizações inevitavelmente levam a mudanças nos requisitos para um sistema de software. A gestão de requisitos é o processo de gestão e controlo dessas mudanças. Capítulo 4 Engenharia de Requisitos 88