Issuu on Google+

UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA

Requisitos de Software Engenharia de Software 2o. Semestre de 2005

Slide 1


Requisitos de software ●

Descrição e especificação de sistemas

Slide 2


Objetivos ●

● ●

Introduzir os conceitos de requisitos do usuário e requisitos de sistema. Descrever requisitos funcionais e não funcionais. Explicar duas técnicas para descrever os requisitos de sistema. Mostrar como requisitos de software podem ser organizados em um documento de requisitos de software

Slide 3


Tópicos ● ● ● ●

Requisitos funcionais e não funcionais Requisitos do Usuário Requisitos do sistema O documento de requisitos de software

Slide 4


Engenharia de Requisitos ●

É o processo de estabelecer os serviços que o cliente requer de um sistema e as restrições sob as quais deve ser desenvolvido e operar. Requisitos são as descrições das funções e restrições.

Slide 5


O que é um requisito? ●

Pode variar de uma declaração abstrata de alto nível, de uma função que o sistema deve fornecer ou de uma restrição do sistema, a uma definição detalhada, matematicamente formal, de uma função do sistema. Assim, requisitos possui diferentes níveis de descrição; • • •

Pode ser a base para uma licitação de um contrato - deve ser aberto à interpretações. Pode ser a base para o próprio contrato - deve ser definido em detalhes. Ambas declarações podem ser chamada requisitos. Slide 6


Por que os requisitos são importantes? Pesquisa Pesquisaem emmais maisde de350 350empresas empresassobre sobreos osseus seusmais maisde de8.000 8.000 Projetos Projetosde desoftware software––30 30% %dos dosprojetos projetosforam foramcancelados. cancelados.Dos Dos concluídos, concluídos,9% 9%entregues entreguesdentro dentrodo doprazo prazoeedo dovalor valorestimado(Standish estimado(Standish Group Group–1994). –1994). Fatores Fatoresprincipais principaisrelatados relatadoscomo comocausas causasdas dasfalhas: falhas: 1.1. Requisitos Requisitosincompletos incompletos(13.1%) (13.1%) 2.2. Falta Faltade deenvolvimento envolvimentopor porparte partedo dousuário usuário(12.4%) (12.4%) 3.3. Falta Faltade derecursos recursos(10.6%) (10.6%) 4.4. Expectativas Expectativasnão nãorealistas realistas(9.9%) (9.9%) 5.5. FaltA FaltAde deapoio apoiodos dosexecutivos executivos(9.3%) (9.3%) 6.6. Modificações Modificaçõesnos nosrequisitos requisitoseenas nasespecificações especificações(8.7%) (8.7%) 7.7. Falta Faltade deplanejamento planejamento(8.1%) (8.1%) 8.8. OOsistema sistemanão nãoera eramais maisnecessário necessário(7.5%) (7.5%)

Slide 7


Por que os requisitos são importantes? ●

Falta de cuidado com os requisitos pode levar a • • • •

Construção de um sistema que resolve o problema errado; Não funciona como esperado; Difícil para os usuários entenderem e utilizarem; Alto custo.

Vale a pena utilizar algum tempo para entender o problema e seu contexto, e obter os requisitos certos na primeira vez. Slide 8


Tipos de requisitos ●

Requisitos do usuário •

Requisitos do sistema •

Declarações em linguagem natural e também em diagramas sobre as funções que o sistema deve fornecer e as restrições sob as quais deve operar. Um documento estruturado que estabelece detalhadamente as funções e as restrições de sistema. Escrito como um contrato entre o cliente e o desenvolvedor do software.

Especificação do software •

Uma descrição detalhada do software que serve como base para projeto e a implementação. Escrito para os desenvolvedores. Slide 9


Definições e Especificações Definição dos requisitos do usuário 1. O software deve oferecer um meio de representar e acessar arquivos externos criados por outra ferramenta

Especificação dos requisitos de sistema 1.1. O usuário deve dispor de recursos para definir o tipo dos arquivos externos. 1.2. Cada tipo de arquivo externo pode ter uma ferramenta associada que pode ser aplicada a ele. 1.3. Cada tipo de arquivo externo pode ser representado como um ícone específico na tela do usuário. 1.4 Devem ser fornecidos recursos para o ícone que representa um arquivo externo, a ser definido pelo usuário. 1.5. Quando um usuário seleciona um ícone que representa um arquivo externo, o efeito dessa seleção é aplicar a ferramenta associada com o tipo de arquivo externo ao arquivo representado pelo ícone selecionado.

Slide 10


Leitores de diferentes tipos de especificações Requisitos Requisitos do dousuário usuário

Requisitos Requisitos de desistema sistema

Especificação Especificaçãode de projeto projetode desoftware software

Gerentes Gerentesde declientes clientes Usuários Usuáriosfinais finaisde desistemas sistemas Engenheiros Engenheirosdo docliente cliente Gerentes Gerentesdo dofornecedor fornecedor Arquitetos Arquitetosde desistemas sistemas Usuários Usuáriosfinais finaisde desistemas sistemas Engenheiros Engenheirosdo docliente cliente Arquitetos Arquitetosde desistemas sistemas Desenvolvedores Desenvolvedoresde desoftware software Engenheiros Engenheirosdo docliente cliente(talvez) (talvez) Arquitetos Arquitetosde desistemas sistemas Desenvolvedores Desenvolvedoresde desoftware software

Slide 11


Requisitos funcionais e não funcionais ●

Requisitos funcionais •

Requisitos não funcionais •

Declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como deve se comportar em determinadas situações. Restrições sobre os serviços ou as funções oferecidas pelo sistema.

Requisitos de domínio •

Requisitos que se originam do domínio da aplicação do sistema e que refletem características desse domínio (Podem ser requisitos funcionais e não funcionais).

Slide 12


Requisitos funcionais ●

Descrevem a funcionalidade ou os serviços do sistema. Dependem do tipo de software, das expectativas dos usuários e do tipo de sistema que está sendo desenvolvido. Requisitos funcionais do usuário são descritos de forma bem geral, mas os requisitos funcionais de sistema descrevem a função de sistema detalhadamente. Slide 13


Exemplos de requisitos funcionais ●

O usuário deverá ser capaz de buscar todo o conjunto inicial de banco de dados ou selecionar um subconjunto a partir dele. O sistema fornecerá telas apropriadas para o usuário ler documentos no repositório de documentos. Cada pedido será alocado a um único identificador (ORDER-ID), que o usuário poderá copiar para a área de armazenagem permanente da conta Requisitos funcionais do usuário Slide 14


Imprecisão de Requisitos ●

Problemas se originam da imprecisão na especificação de requisitos. Requisitos ambíguos podem ser interpretados de maneira diferente pelos desenvolvedores e usuário. Considere o termo ‘telas apropriadas’ • •

Intenção do usuário - telas para cada formato de documento devem ser disponibilizadas. Intenção do desenvolvedor - disponibilizar uma tela de texto que mostra o conteúdo do documento.

Slide 15


Completeza e consistência de requisitos ●

Em princípio, a especificação de requisitos funcionais deve ser completa e consistente Completeza •

Consistência •

Todas as funções requeridas pelo usuário devem estar definidas Não devem haver definições contraditórias de requisitos

Na prática, é quase impossível atingir a consistência e a completeza dos requisitos.

Slide 16


Requisitos não funcionais ●

Definem as propriedades de sistemas e restrições, por ex: confiabilidade, tempo de resposta e espaço em disco. Restrições: capacidade dos dispositivos de E/S, representações de dados, etc. Requisitos não funcionais dizem respeito ao sistema como um todo. Alguns podem restringir o processo que é utilizado para desenvolver o sistema (ditar um sistema CASE específico, linguagem de programação ou método de desenvolvimento) Podem ser mais críticos que requisitos funcionais. A falha em atender um requisito não funcional de sistema pode inutilizar o sistema. Slide 17


Classificações não funcionais ●

Requisitos de produto •

Requisitos organizacionais •

Requisitos que especificam o comportamento do produto. Ex: velocidade de execução, confiabilidade, portabilidade, facilidade de uso, etc.. Requisitos que são conseqüência de políticas de procedimentos nas organizações do cliente e do desenvolvedor. Ex: padrões de processos que devem ser utilizados, requisitos de implementação, etc.

Requisitos externos •

Requisitos procedentes de fatores externos ao sistema e a seu processo de desenvolvimento. Ex: requisitos de interoperabilidade, requisitos legais e os requisitos éticos.

Slide 18


Tipos de requisitos não funcionais NoRequisitos n-fu nctio nal Requisitos requfuncionais ir ements não

não funcionais

Requisitos Pro du ct Requisitos requproduto ir ements do do produto

Requisitos Ef ficiency Requisitos requ ir ements de deeficiência eficiência

Requisitos Reliab ilityde Requisitos de requ ir ements confiabilidade confiabilidade

Requisitos Usab ilityde Requisitos de requ irements facilidade de uso facilidade de uso

Perfo rmance Requisitos de Requisitos de requ irements desempenho desempenho

Or Requisitos gRequisitos an izatio nal requ ir ements organizacionais

organizacionais

Requisitos Po rtabilityde Requisitos de requ irements portabilidade portabilidade

Requisitos Delivery de Requisitos de requ irements entrega entrega

Sp ace de Requisitos Requisitos de requespaço ir ements espaço

Requisitos Ex tern al Requisitos requ irements externos externos

Requisitos de Intero perab ility Requisitos de requ irements interoperabilidade interoperabilidade

Requisitos Implementatio n Requisitosde de requ ir ements implementação

implementação

Requisitos Ethical Requisitos requéticos irements éticos

Requisitos Stand ard sde Requisitos de requ irements padrões padrões

Requisitos Leg islative Requisitos requlegais irements legais

Priv acy de Requisitos Requisitos de requ irements privacidade privacidade

Safety de Requisitos Requisitos de requ irements segurança segurança Slide 19


Exemplos de requisitos não funcionais ●

Requisitos de produto •

Requisito Organizacional •

4.C.8 Deve ser possível que toda a comunicação necessária entre o Ambiente de apoio à programação Ada (APSE) e o usuário seja expressa no conjunto padrão de caracteres Ada. (restringe a liberdade do projetistas do APSE na sua escolha de símbolos utilizados) 9.3.2 O processo de desenvolvimento de sistema e os documentos a serem entregues deverão estar de acordo com o processo e os produtos a serem entregues, definidos em XYZ-SP- STAN95

Requisitos externos •

7.6.5 O sistema não deverá revelar aos operadores nenhuma informação pessoal sobre os clientes, além de seus nomes e o número de referência (legislação de privacidade) Slide 20


Metas e requisitos ●

Requisitos não funcionais muitas vezes podem ser difíceis de serem colocados e verificados. Meta do sistema •

Uma intenção geral do usuário, por ex:, a facilidade de uso.

Requisito não funcional verificável •

Uma declaração usando alguma métrica que pode ser objetivamente testada.

Slide 21


Exemplos ●

Uma meta do sistema •

O sistema deve ser fácil de utilizar por controladores experientes e deve ser organizado de modo que os erros dos usuários sejam minimizados.

Um requisito não funcional verificável •

Controladores experientes devem ser capazes de utilizar todas as funções do sistema depois de um total de duas horas de treinamento. Depois desse treinamento, o número médio de erros feitos pelo usuário não deve exceder a dois por dia.

Slide 22


Métricas para especificar requisitos não funcionais Propriedade Velocidade Tamanho Confiabilidade

Robustez

Portabilidade Facilidade de uso

Métrica Transações processadas/segundo Tempo de resposta ao usuário/evento Tempo de refresh da tela K bytes Números de chips de RAM Tempo médio para falha Probabilidade de indisponibilidade Taxa de ocorrência de falhas Disponibilidade Tempo de reinício depois de uma falha Porcentagem de eventos que causam falhas. Probabilidade de que dados sejam corrompidos por falhas Porcentagem de declarações dependentes de sistemas alvo. Número de sistemas alvo Tempo de treinamento Slide Número de frames de ajuda

23


Interação de requisitos ●

É comum a existência de conflitos entre diferentes requisitos não funcionais em sistemas complexos. Sistema para uma Espaçonave • • •

Para minimizar peso, o número de chips separado deve ser minimizado. Para minimizar consumo de energia, chips de baixo consumo deve ser usado Contudo, o uso de chips de baixo consumo significa que mais chips devem ser utilizados. Qual é o requisito mais crítico?

Slide 24


Requisitos de Domínio ●

Derivados do domínio de aplicação e refletem fundamentos do domínio da aplicação. Podem ser novos requisitos funcionais em si, podem restringir os requisitos funcionais existentes, ou estabelecer como realizar cálculos específicos. Se não forem satisfeitos, poderá ser impossível fazer o sistema operar satisfatoriamente.

Slide 25


Requisitos de domínio do sistema de biblioteca ●

Deve haver uma interface padrão com o usuário para todos os bancos de dados, que terá como base o padrão Z 39.50 Em razão das restrições referentes a direitos autorais, alguns documentos devem ser excluídos imediatamente ao serem fornecidos. Dependendo dos requisitos dos usuários, esses documentos serão impressos localmente no servidor do sistema para serem encaminhados manualmente ao usuário ou direcionados para uma impressora de rede. Slide 26


Sistema automatizado de proteção de trens ●

A desaceleração do trem será computada como: •

Dtrem = Dcontrole + Dgradiente

onde Dgradiente é 9.81ms2 * gradiente compensado/alfa e onde os valores de 9.81ms2/alfa são conhecidos para diferentes tipos de trens .

Slide 27


Problemas com os requisitos de domínio ●

Entendimento •

Requisitos são expressos com o uso de uma linguagem que é específica do domínio da aplicação

Declarações implícitas •

Especialistas em um domínio podem deixar de fornecer informações em um requisito, simplesmente por acharem que essas informações são muito óbvias.

Slide 28


Requisitos de usuário ●

Devem descrever os requisitos funcionais e não funcionais de modo compreensível pelos usuários do sistema, que não tem conhecimentos técnicos detalhados. Requisitos do usuário são definidos usando linguagem natural, tabelas e diagramas.

Slide 29


Problemas com linguagem natural ●

Falta de clareza •

Confusão de requisitos • •

Difícil usar a linguagem de maneira precisa e sem ambigüidade, sem produzir um documento de difícil leitura Os requisitos funcionais e os não funcionais, os objetivos do sistema e as informações sobre o projeto podem não estar claramente definidos.

Fusão de requisitos •

Vários requisitos diferentes podem ser expressos juntos.

Slide 30


Ex: Requisitos sobre um banco de dados 4.A.5 O banco de dados deve aceitar a geração e o controle de configuração de objetos ; ou seja, os objetos que são agrupamentos de outros objetos no banco de dados. Os recursos de controle de configuração devem permitir o acesso aos objetos em um grupo de versão, pelo uso de um nome incompleto.

Ilustra informações conceituais e detalhadas Slide 31


Requisitos de usuário para uma grade de editor (Editor de modelos de projeto de software - CASE) 2.6 Recursos de grade Para ajudar no posicionamento de entidades em um digrama, o usuário pode acionar uma grade de centímetros ou em polegadas, por meio de uma opção no painel de controle. Inicialmente, a grade está desativada. Ela pode ser ligada e desligada a qualquer momento durante uma sessão de edição e pode ser alternada entre polegadas e centímetros a qualquer momento. Uma opção de grade será fornecida na visão reduzida do diagrama, mas o número de linhas da grade mostrado diminuirá, para evitar preencher o diagrama menor com linhas de grade. Ilustra Requisitos do usuário X requisitos do sistema

Slide 32


Problemas com requisitos ●

Os requisitos do banco de dados inclui informações conceituais e detalhadas • •

Descreve o conceito de facilidade de controle de configuração Inclui o detalhe de que objetos podem ser acessados usando um nome incompleto.

Os requisitos para uma grade mistura 3 tipos diferentes de requisitos • • •

Requisito funcional conceitual (a necessidade de uma grade) Requisito não funcional (unidades de medida) Requisitos não funcional de interface com o usuário (Como a grade é ligada e desligada pelo usuário) Slide 33


Apresentação estruturada Recursos de grade O editor deverá fornecer um recurso de grade, em que uma matriz de linhas horizontais e verticais constitua um fundo da janela do editor. Essa grade deverá ser uma tela passiva em que o alinhamento de entidades é responsabilidade do usuário. Lógica: uma grade ajuda o usuário a criar um diagrama ‘limpo’, com entidades bem espaçadas. Embora uma grade ativa, em que as entidades saltam as linhas de grade, possa ser útil, o posicionamento é impreciso. O usuário é a melhor pessoa para decidir onde as entidades devem ser posicionadas. Especificação: 5.6

ECLIPSE/WS/Ferramenta/DE/FS

seção Slide 34


Requisitos do usuário detalhado 3.5.1. Adicionando nós a um desenho. 3.5.1.1 O editor deve fornecer um recurso aos usuários para adicionar nós de um tipo especificado a seu desenho. 3.5.1.2 A seqüência de ações para acrescentar um nó deveria ser como se segue: 1. o usuário deve selecionar o tipo de nó a ser acrescentado. 2. O usuário deve mover o cursor para a posição aproximada do nó no diagrama e indicar que o símbolo do nó deve ser adicionado naquele ponto. 3. O usuário deve então arrastar o símbolo do nó para sua posição final. Lógica: o usuário é a melhor pessoa para decidir onde posicionar um nó no diagrama. Essa abordagem dá ao usuário o controle direto sobre a seleção do tipo de nó e seu posicionamento Especificação: ECLIPSE/WS/Ferramentas/DE/FS. Seção 3.5.1 Slide 35


Diretrizes para escrever requisitos ●

Estabeleça um formato padrão e use-o para todos os requisitos. Utilize a linguagem de modo consistente. Faça distinção entre os requisitos obrigatórios e os que são desejáveis (O sistema deve ... O sistema deveria ...). Utilize destaque no texto para ressaltar partes importantes dos requisitos. Evite o uso de jargões de informática. Slide 36


Requisitos do sistema ●

● ●

Descrições mais detalhadas dos requisitos do usuário. Servem como base para um contrato destinado à implementação do sistema. Ponto de partida para o projeto do sistema. Requisitos do sistema pode ser expresso usando diferentes modelos de especificação de requisitos

Slide 37


Requisitos e projeto ●

Em princípio, os requisitos deveriam definir o que o sistema deveria fazer e não como deveria ser implementado. Na prática, é difícil conseguir essa separação • • •

Uma arquitetura inicial do sistema pode ser definida para ajudar a estruturar os requisitos. O sistema deve inter- operar com outros sistemas que geram requisitos para o novo sistema. O uso de um projeto específico pode ser um requisito externo de sistema

Slide 38


Problemas com especificação em Linguagem Natural ●

Ambigüidade •

Flexibilidade •

Leitores e escritores dos requisitos devem interpretar as mesmas palavras da mesma maneira. A linguagem natural é naturalmente ambígua e isso dificulta a interpretação A mesma coisa pode ser dita de diferentes maneiras na especificação

Falta de modularização •

estruturas da linguagem natural não são apropriadas para estruturar os requisitos do sistema.

Slide 39


Alternativas para especificação em Linguagem Natural N o tação Ling uag em natural estruturada Ling uag em de descrição de projeto N otações g ráficas E specificações m atem áticas

D escrição D epende da definição de form ulários padrão ou tem plates para expessar a especificação de req uisitos. U tiliza um a ling uag em parecida com um a ling uag em de prog ram ação, porém com recursos m ais abstratos. Ling uag em g ráfica, com plem entada com textos, é utilizada para definir os req uisitos funcionais do sistem a. E x: usecase. S ão notações com base em conceitos m atem áticos, com o por exem plo, m áq uinas de esta dos finitos, redes de P etri, statecharts, etc. S ão especificações não am bíg üas, porém usuários relutam em aceitá-las com o base para um contra to.

Slide 40


Especificações em linguagem natural estruturada ●

É uma forma restrita da linguagem natural, que se destina a escrever requisitos do sistema. Essa abordagem elimina problemas de ambigüidade e flexibilidade e garante um certo grau de uniformidade na especificação. Em geral, as notações de linguagem estruturada utilizam templates e abordagens baseadas em formulários pré-definidos.

Slide 41


Especificações baseadas em formulário padrão ● ● ● ● ● ●

Inclui: Descrição da função ou entidade especificada. Descrição de suas entradas e origens. Descrição de saídas e destinos. Indicação de outras entidades utilizadas. Pré e pós condição (se apropriado) Efeitos colaterais (caso existam)

Slide 42


Especificação utilizando formulário padrão Função Adicionar nós. Descrição Adiciona um nó em um desenho existente. O usuário seleciona o tipo de nó e seu posicionamento. Quando Adicionado ao desenho, o nó se torna a seleção atual. O usuário escolhe a posição do nó movimentando o cursor para a área que em que o nó será adicionado. Entradas Tipo de nó, Posição do nó, identificador do desenho Saídas Identificador do desenho. Destino O banco de dados do desenho. O desenho é designado para a base de dados, no término da operação. Requer Gráfico de desenho associado ao identificador de desenho de entrada. Pré condição O desenho é aberto e exibido na tabela do usuário. Pós condição O desenho é imutável, a não ser pela adição de um nó do tipo especificado em dada posição. Efeitos colaterais Nenhum. Slide 43


Especificação de requisitos com o uso de uma PDL ●

Requisitos podem ser definidos operacionalmente com o uso de uma linguagem de descrição de programa (PDL) PDL é uma linguagem derivada de uma LP, com maior poder de expressão. Apropriada em duas situações • •

Quando uma operação é especificada como uma seqüência de ações e a ordem é importante. Quando interfaces de hardware e software tiverem de ser especificadas.

Slide 44


Parte de uma descrição em PDL de uma ATM class ATM { // declarations here public static void main (String args[]) throws InvalidCard { try { thisCard.read () ; // may throw InvalidCard exception pin = KeyPad.readPin () ; attempts = 1 ; while ( !thisCard.pin.equals (pin) & attempts < 4 ) { pin = KeyPad.readPin () ; attempts = attempts + 1 ; } if (!thisCard.pin.equals (pin)) throw new InvalidCard ("Bad PIN"); thisBalance = thisCard.getBalance () ; do { Screen.prompt (" Please select a service ") ; service = Screen.touchKey () ; switch (service) { case Services.withdrawalWithReceipt: receiptRequired = true ;

Slide 45


Desvantagens da PDL ●

● ●

A PDL pode não ser suficientemente expressiva para definir a funcionalidade do sistema. A notação é difícil de entender. A especificação é mais um esboço de projeto ao invés de um modelo para auxiliar o usuário a compreender o sistema.

Slide 46


Especificação de Interface ●

A maioria dos sistemas deve operar com outros sistemas e as interfaces de sistemas existentes devem ser especificadas como parte dos requisitos. Existem três tipos de interfaces que podem precisar ser definidas: • • •

Interfaces de procedimentos Estruturas de dados transmitidas de um subsistema para outro Representações de dados.

Notações formais são técnicas adequadas para a especificação de interfaces. Slide 47


Descrição em PDL de um servidor de impressão interface PrintServer { // define um servidor de impressora abstrato // requer: interface Printer, interface PrintDoc // fornece: initialize, print, displayPrintQueue, cancelPrintJob, switchPrinter void initialize ( Printer p ) ; void print ( Printer p, PrintDoc d ) ; void displayPrintQueue ( Printer p ) ; void cancelPrintJob (Printer p, PrintDoc d) ; void switchPrinter (Printer p1, Printer p2, PrintDoc d) ; } //PrintServer

Slide 48


O documento de requisitos ●

O documento de requisitos é a declaração oficial do que é exigido dos desenvolvedores de sistema. Deve incluir os requisitos de usuário e uma especificação detalhada dos requisitos de sistema. NÃO é um documento de projeto. Deve esclarecer o que o sistema deve fazer e não como deve ser feito.

Slide 49


Clientes Clientesde de sistema sistema

Gerentes Gerentes

Especificam Especificamos osrequisitos requisitoseeos os lêem lêempara paraverificar verificarse seeles eles atendem atendemaasuas suasnecessidades. necessidades. Especificam Especificamas asmudanças mudanças nos requisitos. nos requisitos. Utilizam Utilizamdoc. doc.de derequisitos requisitospara para planejar planejarum umpedido pedidode deproposta proposta para paraoosistema sistemaeepara paraplanejar planejar ooprocesso processode dedesenvolvimento. desenvolvimento.

Engenheiros Engenheirosde de sistema sistema

Utilizam Utilizamos osrequisitos requisitospara para compreender compreenderque quesistema sistema deve deveser serdesenvolvido desenvolvido

Engenheiros Engenheirosde de teste testede desistema sistema

Utilizam Utilizamos osrequisitos requisitospara para desenvolver desenvolvertestes testesde de validação validaçãopara paraoosistema sistema

Engenheiros Engenheirosde de manutenção manutenção de desistema sistema

Utilizam Utilizamos osrequisitos requisitospara para ajudar ajudaraacompreender compreenderoo sistema sistemaeeas asrelações relaçõesentre entre suas suaspartes partes

Usuários de um documento de requisitos


Requisitos de um documento de requisitos ● ● ● ●

Deve: Especificar o comportamento externo do sistema. Especificar as restrições à implementação. Ser fácil de ser modificado. Servir como ferramenta de referência para a manutenção. Registrar a estratégia sobre o ciclo de vida do sistema. Caracterizar respostas aceitáveis para eventos indesejáveis. Slide 51


Padrão IEEE/ANSI 830 - 1993 para o documento de requisitos ● ● ● ● ●

Introdução Descrição Geral Requisitos específicos (funcionais e não funcionais) Apêndices Índice Essa é uma estrutura genérica, que deve ser instanciada para sistemas específicos Slide 52


A estrutura de um documento de requisitos ● ● ● ● ● ● ● ● ● ●

Prefácio Introdução Glossário Definição de requisitos de usuário Arquitetura de sistemas Especificação de requisitos do sistema Modelos do sistema Evolução do sistema Apêndices Índice Slide 53


Pontos Chave ●

Os requisitos estabelecem o que o sistema deve fazer e definem restrições sobre sua operação e implementação. Requisitos funcionais são declarações de funções que o sistema deve fornecer. Requisitos não funcionais se relacionam às propriedades emergentes do sistema e, portanto, se aplicam ao sistema como um todo. Requisitos de usuário são declarações de alto nível do que o sistema deve fazer. Slide 54


Pontos chave ●

Requisitos de usuário devem ser escritos em linguagem natural, tabelas e diagramas. Requisitos de sistema se destinam a comunicar, de modo preciso, as funções que o sistema tem de fornecer. Requisitos de sistema podem ser escritos em linguagem natural estruturada, uma PDL ou em linguagem formal. O documento de requisitos de software é a declaração estabelecida dos requisitos do sistema. Slide 55


Slide 56


Requisitos de Software