Engenharia de Software Aula 2.1 Introdução à Engenharia de Requisitos. Prof. Bruno Moreno

Engenharia de Software Aula 2.1 Introdução à Engenharia de Requisitos Prof. Bruno Moreno bruno.moreno@ifrn.edu.br

Engenharia de Requisitos É, talvez, o maior problema da indústria de SW; Está relacionada com: Definição do que o sistema deve fazer; Propriedades emergentes desejáveis e essenciais Restrições quanto à operação do sisrema; Restrições quanto aos processos de desenvolvimento; 2

Engenharia de Requisitos Pode ser pensada como o processo de comunicação entre os clientes, usuários do SW e os desenvolvedores. 3

Requisitos de Software São descrições dos serviços fornecidos pelo sistema e suas restrições operacionais; Os requisitos refletem o que o sistema deve fazer para resolver algum problema do cliente. 4

Requisitos de Software A Engenharia de Requisitos envolve todo o processo de descobrir, analisar, documentar e verificar esses serviços e restrições Existem diferentes formas de expressar requisitos Depende do nível de abstração; Isso ocorre porque o termo requisito não é usado de maneira consistente na indústria de SW Pode ser uma simples declaração abstrata de alto nível; Pode ser uma declaração formal e detalhada. 5

Requisitos de Software Os requisitos podem ser classificados em diferentes níveis de abstração Requisitos de usuário Declarações, em alto nível, dos serviços esperados pelo sistema e as restrições sob as quais ele deve operar; Requisitos de sistema Definem, detalhadamente, as funções, serviços e restrições operacionais do sistema 6

Requisitos de Software Os Requisitos de Sistema são documentados por meio de um documento de requisitos de sistema, ou especificação funcional Este documento deve ser preciso Deve definir exatamente o que será implementado Pode ser parte do contrato entre comprador do sistema e os desenvolvedores Os requisitos de sistema são frequentemente classificados como funcionais e não funcionais; 7

Tipos de Requisitos Requisitos funcionais São declarações de serviços que o sistema deve fornecer; Define como o sistema deve reagir à entradas específicas e como o mesmo deve se comportar em diferentes situações; Requisitos não funcionais São restrições sobre os serviços oferecidos pelo sistema Requisitos de domínio São provenientes do domínio da aplicação do sistema Refletem características e restrições do domínio Podem ser funcionais ou não funcionais 8

Requisitos funcionais Expressam o que o sistema pode fazer; Exemplo de requisitos funcionais para um sistema de biblioteca O usuário deve ser capaz de fazer uma busca por livros em toda a biblioteca ou apenas em seções da biblioteca; O sistema deve fornecer telas apropriadas para o usuário ler os documentos na forma digital; Para cada pedido, deve ser alocado um identificador único (ORDER_ID) 9

Requisitos funcionais A especificação de requisitos funcionais deve ser completa e consistente Completa: todos os serviços devem ser definidos; Consistente: os requisitos não devem ter definições contraditórias; Em alguns casos, os requisitos funcionais também estabelecem explicitamente o que o sistema não deve fazer; 10

Requisitos não funcionais São aqueles requisitos que não estão diretamente ligados a funções específicas do sistema; Podem estar relacionados às propriedades emergentes do sistema Confiabilidade Tempo de resposta Espaço de armazenamento Podem definir restrições e as representações de dados usadas nas interfaces do sistema 11

Requisitos não funcionais Estão raramente relacionados a características individuais do sistema Podem especificar desempenho, proteção, disponibilidade e outras propriedades emergentes do sistema; São geralmente mais importantes do que os requisitos funcionais do sistema Usuários em geral encontram meios de contornar a ausência de um requisito funcional, mas uma falha no atendimento de um requisito não funcional pode comprometer o sistema como um todo. 12

Requisitos não funcionais Requisitos não funcionais não estão relacionados apenas com o sistema de SW a ser desenvolvido; Alguns deles podem estabelecer restrições referentes ao processo de desenvolvimento; Por exemplo Especificar padrões de qualidade que devem ser usados Especificar as ferramentas que devem ser utilizadas Descrever o processo de desenvolvimento que deve ser seguido 13

Requisitos não funcionais Os RNF existem devido a diferentes motivos Necessidades do usuário; Restrições de orçamento; Políticas organizacionais; Necessidade de interoperabilidade com outros sistemas de SW ou HW; ou Fatores externos a organização Regulamentos, legislações, respeito a privacidade e outros 14

Requisitos não funcionais Tipos de requisitos NF Especificam o comportamento do produto; Exemplo: rapidez de operação do sistema. Derivados de políticas e procedimentos organizacionais; Exemplo: padrões a serem seguidos pelo sistema. Derivados de fatores externos ao sistema e aos processos Da empresa De desenvolvimento Exemplos: Leis, código de ética, etc. 15

Requisitos não funcionais Tipos de requisitos NF 16

Requisitos não funcionais Um problema comum dos RNF é que eles podem ser difíceis de ser verificados; Eles são, geralmente, definidos como metas gerais Usabilidade, capacidade do sistema de se recuperar de falhas ou resposta rápida ao usuário, por exemplo Muito depende da interpretação dos desenvolvedores 17

Requisitos não funcionais Exemplos de RNF (1) Requisito de produto 8.1: A interface de usuário deve ser implementada como simples HTML, sem frames ou applets de Java Requisito organizacional 8.2: O processo de desenvolvimento do sistema e os documentos a serem entregues devem estar em conformidade com o processo e produtos definidos pelo padrão XYZ. Requisitos externo 8.3: O sistema não deve revelar quaisquer informações pessoais sobre os usuários do sistema ao pessoal da biblioteca que usa o sistema, com exceção do nome e número de matrícula. 18

Requisitos não funcionais Exemplos de RNF (2) Meta do sistema 8.4: O sistema deve ser fácil de ser usado pelos controladores experientes e ser organizado de modo que os erros dos usuários sejam minimizados Requisito não funcional verificável Os controladores experientes devem ser capazes de usar todas as funções do sistema depois de um treinamento no total de duas horas. Após esse treinamento, o número médio de erros cometidos pelos usuários experientes não deve exceder dois por dia. 19

Requisitos não funcionais Sempre que possível, os RNFs devem ser descritos de forma quantitativa Para que possam ser testados objetivamente. Algumas metas são impossíveis de serem traduzidas quantitativamente 20

Requisitos de Domínio São derivados do domínio de aplicação Podem ser novos requisitos funcionais Podem restringir RFs existentes Exemplos Definição de cálculos específicos devem ser realizados; Implementação de legislações vigentes, regulamentos organizacionais, dentre outras regras; 21

A distinção entre os diferentes tipos de requisitos não é tão clara. 22

Exemplo Requisito relacionado a segurança de informação parece ser não funcional; Quando detalhado, observa-se que o mesmo é um requisito funcional: Implementação da funcionalidade de autenticação de usuário; Definição de diferentes papéis de usuários; Atribuição de diferentes tarefas aos papéis; 23

Documento de Requisitos É a declaração oficial do que os desenvolvedores devem implementar; Inclui tanto uma especificação detalhada dos requisitos, como os requisitos de usuário Em alguns casos, ambos requisitos podem estar integrados em uma única descrição; Em outros, os requisitos de usuário estão definidos em uma introdução à especificação dos requisitos de sistema; 24

Documento de Requisitos O documento é usado para comunicar os requisitos aos clientes, engenheiros e gerentes; Diferentes organizações definiram padrões para documentos de requisitos; É comumente chamado de ERS (Especificação de Requisitos de Software). 25

Documento de Requisitos Informações que o documento deve conter: Uma visão geral sobre o sistema; Informações sobre o domínio da aplicação; Serviços e funções que o sistema deve prover; Limitações sobre as quais o sistema deve operar; Propriedades gerais do sistema; Definições sobre outros sistemas a serem operados; Limitações dos processos de desenvolvimento utilizados; Descrições sobre hardwares a serem utilizados; Glossário (terminologia usada). 26

Documento de Requisitos Informações que o documento deve conter: NOSSA ATIVIDADE DA AULA PASSADA! Uma visão geral sobre o sistema; Informações sobre o domínio da aplicação; Serviços e funções que o sistema deve prover; Limitações sobre as quais o sistema deve operar; Propriedades gerais do sistema; Definições sobre outros sistemas a serem operados; Limitações dos processos de desenvolvimento utilizados; Descrições sobre hardwares a serem utilizados; Glossário (terminologia usada). 27

Documento de Requisitos O padrão mais conhecido é o IEEE/ANSI 301998, que sugere a estrutura a seguir Introdução Descrição Geral Requisitos específicos Apêndices Índice 28

Documento de Requisitos Padrão IEEE/ANSI 30-1998 Introdução Propósito do documento de requisitos; Escopo do produto; Definições, acrônimos e abreviaturas; Referências; Visão geral do restante do documento; 29

Documento de Requisitos Padrão IEEE/ANSI 30-1998 Descrição Geral Perspectiva do produto; Funções do produto; Características dos usuários; Restrições gerais; Suposições e dependências. 30

Documento de Requisitos Padrão IEEE/ANSI 30-1998 Requisitos específicos Abrangem requisitos funcionais e não funcionais; Não possui uma estrutura padrão; Apêndices; Índice. 31

Adaptando um Padrão O padrão do IEEE é genérico Pode ser aplicado em diversos documentos de requisitos; Nem todas as partes do documento são necessárias para todos os documentos de requisitos; Cada organização deverá adaptar o padrão de acordo com o tipo de sistema que desenvolve. 32

Escrevendo requisitos Requisitos podem ser escritos como texto e complementados por diagramas e equações. A forma de se escrever os requisitos depende do processo de desenvolvimento utilizado; Existem formas resumidas e formas consideradas completas ; Normalmente se representa requisitos utilizando um diagrama chamado Diagrama de Casos de Uso ; 33

O essencial da escrita Requisitos são lidos mais frequentemente do que são escritos. Invista tempo lendo e entendendo os requisitos; Não assuma que todos os leitores dos requisitos tenham o mesmo background e usem a mesma terminologia sua; Permita tempo para revisão do documento. 34

Modelo de Documento Fonte: [http://www1.univap.br/~helio/2013/aquarius_mc/documento_de_requisitos.pdf] Este modelo deve ser utilizado no projeto final; 35

Modelo de Documento 36

Próximas Atividades Estudem o documento-modelo que está no site pois o utilizaremos ao longo do ano Prova: 10/08 Entrega da 1a Versão da ERS: 15/08 48