Engenharia Software
Upcoming SlideShare
Loading in...5
×
 

Engenharia Software

on

  • 5,087 views

 

Statistics

Views

Total Views
5,087
Slideshare-icon Views on SlideShare
5,070
Embed Views
17

Actions

Likes
2
Downloads
159
Comments
0

1 Embed 17

http://www.slideshare.net 17

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial LicenseCC Attribution-NonCommercial License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Engenharia Software Engenharia Software Presentation Transcript

    • ENGENHARIA DE SOFTWARE Aula 04 Engenharia de Requisitos Prof. Cleuber Fernandes Mestre em Ciência da Computação - UnB Cleubermf@yahoo.com.br http://br.groups.yahoo.com/group/ES-2008 ________________________________________________________________________ Prof. M.Sc. Cleuber Fernandes 1
    • 1. Motivação “Uma COMPREENSÃO COMPLETA DOS REQUISITOS de software É FUNDAMENTAL para um bem-sucedido desenvolvimento de software. Não importa quão bem projetado ou quão bem codificado seja, um programa mal analisado e especificado desapontará o usuário e trará aborrecimentos no desenvolvimento” [Pressman] Declaração de um cliente: “Sei que você acredita que entendeu o que acha que eu disse, mas não estou certo de que percebe que aquilo que ouviu não é o que eu pretendia dizer...” Em uma pesquisa realizada nos EUA em 1995 com 350 empresas americanas em 8000 projetos de software, foi constatado que AS FALHAS OCORRIDAS foram decorrentes de: • Pouco envolvimento do usuário (13%) • Requisitos incompletos (12%) • Mudanças de requisitos (11%) • Expectativas irreais (6%) • Objetivos obscuros (5%) ________________________________________________________________________ Prof. M.Sc. Cleuber Fernandes 2
    • Analisando os dados da pesquisa, podemos concluir que aproximadamente 50% DAS CAUSAS DE PROBLEMAS EM UM DESENVOLVIMENTO DE SOFTWARE, ESTÃO EM UM LEVANTAMENTO DE REQUISITOS RUIM. 2. Definição Requisitos são FUNÇÕES ou RESTRIÇÕES estabelecidas por clientes e usuários que definem as diversas propriedades do sistema. Engenharia de Requisitos é o processo de DESCOBRIR, ANALISAR, DOCUMENTAR E VERIFICAR as funções e restrições do software. Existem dois níveis de descrição dos requisitos: • REQUISITOS DE USUÁRIO: declarações, em linguagem natural e diagrama sobre funções e restrições que o sistema deve atender. • REQUISITOS DO SISTEMA: estabelecem detalhadamente as funções e as restrições de sistema. Algumas vezes chamado de especificação funcional, deve ser preciso. ⇒ Diferentes níveis de especificações de sistemas são úteis, porque comunicam informações sobre o sistema a diferentes tipos de interessados. Exemplo: Requisito de usuário • O software deve permitir checkin de hóspedes. Especificação dos requisitos de sistema • O sistema deve exibir aptos disponíveis; • O usuário deve selecionar apto; • O usuário deve informar dados do hóspede; • O sistema deve imprimir comprovante de checkin. 3. Dificuldades • DESCONHECIMENTO DO DOMÍNIO DE NEGÓCIO; • FALTA DE CLAREZA E OBJETIVIDADE POR PARTE DO CLIENTE EM DEFINIR OS OBJETIVOS E REQUISITOS DO SISTEMA; • POUCO ENVOLVIMENTO E COMPROMETIMENTO DO USUÁRIO; • MUDANÇAS CONSTANTES NOS REQUISITOS. ________________________________________________________________________ Prof. M.Sc. Cleuber Fernandes 3
    • 4. Atividades 1. LEVANTAMENTO DE REQUISITOS (RECONHECIMENTO DO PROBLEMA) 2. ANÁLISE DE REQUISITOS (SÍNTESE) 3. MODELAGEM (CASOS DE USO) 4. ESPECIFICAÇÃO (DE CASOS DE USO) 5. AVALIAÇÃO E REVISÃO (PELO CLIENTE E USUÁRIOS) 6. GERÊNCIA DE REQUISITOS (GERENCIAR INCLUSÃO DE NOVOS REQUISITOS E MUDANÇA NOS JÁ EXISTENTES) 5. Requisitos Funcionais, Não Funcionais e de Domínio • Requisitos Funcionais São declarações de FUNÇÕES QUE O SISTEMA DEVE FORNECER, como o sistema deve reagir a entradas específicas e como deve se comportar em determinadas situações. Podem também declarar o que o sistema não deve fazer. • Requisitos Não Funcionais São restrições sobre os serviços ou as funções oferecidas pelo sistema, tais como: RESTRIÇÕES DE TEMPO, SEGURANÇA, DISPONIBILIDADE, dentre outras. • Requisitos de Domínio Originam do domínio de aplicação do sistema e refletem características desse domínio. Podem ser FUNCIONAIS OU NÃO FUNCIONAIS. Essas definições são sutis. Um requisito do usuário de que é necessário AUTORIZAÇÃO DE ACESSO, pode parecer um requisito não funcional de segurança, enquanto na verdade é um requisito funcional. 5.1 Requisitos Funcionais Os requisitos funcionais descrevem a funcionalidade ou os serviços que se espera que o sistema forneça. Os requisitos funcionais de usuário são descritos de forma geral, mas os requisitos funcionais de sistema descrevem as funções de sistema detalhadamente, suas entradas e saída, exceções. REQUISITOS FUNCIONAIS PODEM SER ESCRITOS EM DIFERENTES NÍVEIS DE DETALHAMENTO, como segue: 1. O usuário deve ser capaz de incluir novos hóspedes; 2. Cada hóspede terá um identificador único que o identificará nos demais módulos do sistema. Muitos problemas de engenharia de software se originam de IMPRECISÃO NA ESPECIFICAÇÃO de requisitos, que muitas vezes PERMITEM INTERPRETAÇÕES AMBÍGUAS. Dessa forma, a especificação de requisitos funcionais de um sistema deve ser completa e consistente. ________________________________________________________________________ Prof. M.Sc. Cleuber Fernandes 4
    • • A completeza significa que todas as funções requeridas pelo usuário devem estar definidas. • A consistência significa que os requisitos não devem ter definições contraditórias. Durante o ciclo de vida do sistema certamente serão identificados novos requisitos, bem como alguns requisitos inconsistentes. Por isso, o modelo iterativo e incremental (RUP) é mais indicado que o modelo cascata. 5.2 Requisitos Não Funcionais Como o próprio nome sugere, são aqueles que não dizem respeito diretamente às funções específicas fornecidas pelo sistema. Podem estar relacionados a propriedades de sistemas, como CONFIABILIDADE, TEMPO DE RESPOSTA, USO DE MEMÓRIA. Podem definir RESTRIÇÕES PARA O SISTEMA. Muitos requisitos não funcionais dizem respeito ao sistema como um todo, e não a características individuais. Freqüentemente os requisitos não funcionais são mais importantes que os funcionais. Deixar de atender um requisito funcional pode degradar uma funcionalidade, mas uma falha num requisito não funcional pode prejudicar todo o sistema. Como exemplo, temos: SE UM SISTEMA DE AVIAÇÃO NÃO ATENDER AOS REQUISITOS DE CONFIABILIDADE, NÃO TERÁ AUTORIZAÇÃO PARA OPERAR. Requisitos não funcionais surgem em razão de restrições de orçamento, políticas organizacionais, necessidade de interoperabilidade com outros sistemas de software ou hardware, ou devido a regulamentos de segurança, privacidade, dentre outros fatores externos. O diagrama abaixo exibe a classificação dos diferentes tipos de requisitos não funcionais. Requisitos Não Funcionais Requisitos do Requisitos Requisitos Produto Organizacionais Externos Prazo de Interoperabili- Eficiência Portabilidade Padrões Legais Entrega dade Espaço Desempenho Privacidade Segurança Memória/Disco Os requisitos não funcionais devem ser expressos quantitativamente, utilizando-se métricas que possam ser objetivamente testadas. As medições podem ser feitas durante o teste de sistema, para determinar se o sistema cumpre com os requisitos ou não. Segue exemplo: ________________________________________________________________________ Prof. M.Sc. Cleuber Fernandes 5
    • Meta do sistema: O sistema deve ser fácil de usar por controladores experientes e deve ser organizado de modo que erros de 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. Após este treinamento, o número médio de erros feitos por usuários experientes não deve exceder a dois por dia. Propriedade Métrica Velocidade Transações processadas por segundo Tempo de resposta ao usuário por evento Tempo de atualização da tela Facilidade de uso Tempo de treinamento Número de ajudas on-line Confiabilidade Tempo médio para falhar Probabilidade de indisponibilidade Robustez Tempo de reinício após falha Porcentagem de eventos que causam falhas Portabilidade Porcentagem de recursos dependentes de SO/Hardware Número de SO/Hardware Alguns requisitos não funcionais podem entrar em conflito com requisitos funcionais, como: - Requisito funcional: O sistema deve apresentar, em vídeo, gráficos de faturamento mensal; - Requisito não funcional: O sistema não deve ocupar mais que 512 KB de memória. 5.3 Requisitos de Domínio São derivados do domínio da aplicação do sistema, em vez de serem obtidos a partir das necessidades específicas dos usuários. Podem: - Ser novos requisitos funcionais; - Restringir os requisitos funcionais existentes; - Estabelecer regras de negócio, como cálculos específicos. Requisitos de domínio são importantes por refletirem fundamentos do domínio da aplicação, como: - Uma rede bayesiana não pode conter ciclos orientados; X Y Z - A probabilidade de uma variável condicionada ao conjunto de variáveis pais é calculada da seguinte forma: ________________________________________________________________________ Prof. M.Sc. Cleuber Fernandes 6
    • Y Z X P( X , Y , Z ) P( X | Y , Z ) = P(Y , Z ) 6. Requisitos de Usuário Devem descrever requisitos funcionais e não funcionais de modo compreensível pelos usuários do sistema que não têm conhecimento técnico. Não devem ser definidos utilizando-se um modelo de implementação. Podem ser escritos usando linguagem natural, formulários ou DIAGRAMAS INTUITIVOS. Vários problemas podem surgir quando requisitos são escritos em LINGUAGEM NATURAL: 1. Falta de clareza: às vezes, é difícil utilizar a linguagem de maneira precisa e sem ambigüidades. 2. Confusão de requisitos: Os requisitos funcionais e não funcionais, os objetivos do sistema e as informações sobre o projeto podem não estar bem definidos e até mesmo contraditórios. 3. Fusão de requisitos: Vários requisitos diferentes podem ser expressos juntos como um único requisito. Exemplo: Recursos de grade Para ajudar no posicionamento de entidades em um diagrama, o usuário pode acionar uma grade em centímetros ou em polegadas, por meio de uma opção no painel de controle. Inicialmente, a grade está desativada. Ela pode ser ligada ou 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. A descrição em linguagem natural acima mistura três tipos de requisitos: 1. Um requisito funcional conceitual especifica que o sistema de edição deve fornecer uma grade e apresenta uma base lógica para isso. 2. Um requisito não funcional, que fornece informações detalhadas sobre as unidades da grade (centímetros ou polegadas). 3. Um requisito não funcional de interface com o usuário, que define como essa grade é ligada e desligada pelo usuário. Os requisitos de usuário devem mostrar apenas os recursos principais a serem fornecidos pelo sistema. A lógica associada com os requisitos é importante, pois ajuda os desenvolvedores e os responsáveis pela manutenção a compreender por que os requisitos foram incluídos e avaliar o impacto da mudança nos requisitos. ________________________________________________________________________ Prof. M.Sc. Cleuber Fernandes 7
    • A descrição abaixo, para o requisito de grade, é mais indicada do que a citada acima. 1. Recursos de grade 1.1 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 é de 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. 7. Requisitos de Sistema Os requisitos de sistema são DESCRIÇÕES MAIS DETALHADAS dos requisitos do usuário. Pode servir como um contrato destinado à implementação do sistema e, dessa forma, devem ser uma especificação completa e consistente de todo o sistema. São UTILIZADOS PELOS ENGENHEIROS DE SOFTWARE como ponto de partida para o projeto de sistema. A especificação de requisitos de sistema pode incluir diferentes modelos, como modelo de caso de uso detalhado, encenação de caso de uso e modelo de objetos. Apesar da linguagem natural ser freqüentemente utilizada para escrever especificações de requisitos de sistema, alguns problemas podem surgir, tais como: 1. Uso das mesmas palavras expressando conceitos distintos; 2. Uso flexível, dizer a mesma coisa de modos completamente diferentes; Por estes motivos, o uso da linguagem natural em especificação de requisitos de sistema pode gerar divergências, pois dá margens a interpretações individuais. Dessa forma, é indicado o uso de outras formas de especificação que reduzam ambigüidades, como a Linguagem natural estruturada. ________________________________________________________________________ Prof. M.Sc. Cleuber Fernandes 8
    • 8. Modelo de Casos de Uso O modelo de casos de uso é um modelo que descreve os requisitos de um sistema em termos de casos de uso. É um modelo das FUNÇÕES PRETENDIDAS DO SISTEMA E SUAS VIZINHANÇAS, que serve como CONTRATO ENTRE O CLIENTE E OS DESENVOLVEDORES. O mesmo modelo de casos de uso é o resultado da disciplina Requisitos e é usado como entrada para as disciplinas Análise & Design e Teste. Os usuários e qualquer outro sistema que podem interagir com o sistema são os atores. Como eles representam os usuários do sistema, os ATORES AJUDAM A DELIMITAR O SISTEMA e fornecem uma imagem mais clara do que se espera que seja feito. Os casos de uso são desenvolvidos com base nas necessidades dos atores. Isso garante que o sistema será o que os usuários esperam. Conforme eles são revelados, os casos de uso e os atores devem ser descritos brevemente, antes de descrever os casos de uso detalhadamente, o modelo de casos de uso deve ser revisto pelo cliente para verificar se todos os casos de uso e os atores foram encontrados e se juntos eles podem fornecer o que o cliente deseja. Em um ambiente de desenvolvimento iterativo, você seleciona um subconjunto de casos de uso para ser detalhado em cada iteração. Essas descrições mostram como o sistema interage com os atores e o que o sistema executa em cada caso individual. Como Evitar a Decomposição Funcional Não é raro que o modelo de casos de uso se torne uma decomposição funcional do sistema. Para evitar isso, observe os seguintes sintomas: • Casos de uso quot;pequenosquot; - significa que a descrição do fluxo de eventos é apenas uma ou poucas frases. • quot;Muitosquot; casos de uso - significa que o número de casos de uso é algum múltiplo de cem em vez de um múltiplo de dez. • Os nomes dos casos de uso que são construções como quot;executar esta operação com esses dados específicosquot; ou quot;executar esta função com esses dados específicosquot;. Por exemplo, quot;Inserir o Número de Identificação Pessoal em um caixa eletrônicoquot; não deve ser modelado como um caso de uso ________________________________________________________________________ Prof. M.Sc. Cleuber Fernandes 9
    • separado para um caixa eletrônico, já que ninguém usaria o sistema para executar apenas isso. Um caso de uso é um fluxo completo de eventos que resulta em algo de valor para um ator. Para evitar a decomposição funcional, você deve ter certeza de que o modelo de casos de uso ajuda a responder perguntas como: • Qual é o contexto do sistema? • Por que o sistema foi criado? • O que o usuário deseja realizar quando usa o sistema? • Que valor o sistema agrega aos usuários? Requisitos Não Funcionais É muito fácil perceber que os casos de uso são uma forma muito boa de capturar os requisitos funcionais em um sistema. E os requisitos não funcionais? O que são eles e onde são capturados? Muitos requisitos não funcionais aplicam-se a um caso de uso individual e são capturados dentro das propriedades desse caso de uso. Nesse caso, eles são capturados dentro do fluxo de eventos do caso de uso ou como um requisito especial do caso de uso (consulte Diretrizes: Caso de Uso). Exemplo: No Sistema da Máquina de Reciclagem, um requisito não funcional específico para o caso de uso Devolver Itens do Depósito pode ser: A máquina deve ser capaz de reconhecer os itens de depósito com uma confiabilidade de mais de 95%. Freqüentemente, os requisitos não funcionais aplicam-se ao sistema inteiro. Esses requisitos são capturados nas Especificações Suplementares (consulte Artefato: Especificações Suplementares). Exemplo: No Sistema da Máquina de Reciclagem, um requisito não funcional que se aplica ao sistema inteiro pode ser: A máquina só permitirá um usuário por vez. ________________________________________________________________________ Prof. M.Sc. Cleuber Fernandes 10
    • Dilema “O que” versus “Como” Os casos de uso ou os requisitos do software devem estabelecer quot;o quequot; o sistema executa, mas não quot;comoquot; ele executa. Casos de Uso Concretos e Abstratos Há uma distinção entre casos de uso concretos e abstratos. Um caso de uso concreto é iniciado por um ator e constitui um fluxo completo de eventos. quot;Completoquot; significa que uma instância do caso de uso executa a operação inteira chamada pelo ator. Um caso de uso abstrato propriamente nunca é instanciado. Os casos de uso abstratos são incluídos em (consulte Diretrizes: Relacionamento de Inclusão), se estendem para (consulte Diretrizes: Relacionamento de Extensão) ou generalizam (consulte Diretrizes: Generalização de Casos de Uso) outros casos de uso. Quando um caso de uso concreto é iniciado, uma instância do caso de uso é criada. Essa instância também exibe o comportamento especificado por seus casos de uso abstratos associados. Portanto, nenhuma instância separada é criada de casos de uso abstratos. A distinção entre os dois é importante porque são os casos de uso concretos que os atores quot;verãoquot; e iniciarão no sistema. Você indica que um caso de uso é abstrato escrevendo seu nome em itálico. Exemplo: ________________________________________________________________________ Prof. M.Sc. Cleuber Fernandes 11
    • Estruturação do Modelo de Casos de Uso Há três motivos principais para estruturar o modelo de casos de uso: • Facilitar o entendimento dos casos de uso. • Particionar o comportamento comum descrito em muitos casos de uso. • Facilitar a manutenção do modelo de casos de uso. No entanto, a estruturação não deve ser feita primeiro. Só faz sentido estruturar os casos de uso quando você souber um pouco mais sobre o comportamento deles, além de uma breve descrição em uma frase. Você deve pelo menos ter estabelecido um esquema passo a passo para o fluxo de eventos do caso de uso, a fim verificar se as suas decisões se basearam em um entendimento bem preciso do comportamento. Se houver uma parte de um caso de uso base que represente uma função da qual o caso de uso só depende do resultado, e não do método usado para produzir o resultado, você poderá fatorar essa parte em um caso de uso adicional. A adição é explicitamente inserida no caso de uso base, usando o relacionamento de inclusão. Se houver uma parte de um caso de uso base que seja opcional ou desnecessária para entender a principal finalidade do caso de uso, você poderá fatorar essa parte em um caso de uso adicional para simplificar a estrutura do caso de uso base. A adição é implicitamente inserida no caso de uso base, usando o relacionamento de extensão. Se houver casos de uso com semelhanças no comportamento, na estrutura e na finalidade, as partes comuns podem ser fatoradas em um caso de uso base (pai) que é herdado por casos de uso adicionais (filho). Os casos de uso filho podem inserir um novo comportamento e modificar o existente na estrutura herdada do caso de uso pai. Consulte também Diretrizes Você pode usar a generalização do ator para mostrar como os atores são especializações uns dos outros. Exemplo: Considere parte do modelo de casos de uso de um Sistema de Gerenciamento de Ordens. É útil separar o Cliente comum do Cliente de Internet, já que eles têm propriedades ligeiramente diferentes. Entretanto, como o Cliente de Internet exibe todas as propriedades de um Cliente, você pode dizer que esse Cliente de Internet é uma especialização do Cliente, indicado com uma generalização de ator. Os casos de uso concretos neste diagrama são a Ordem por Telefone (iniciada pelo ator Cliente) e Ordem pela Internet (iniciada pelo Cliente de Internet). Esses casos de uso são variações do caso de uso mais geral Inserir Ordem, que neste exemplo é abstrato. O caso de uso Solicitar Catálogo representa um segmento opcional de comportamento que não é parte da principal finalidade de Inserir Ordem. Ele foi fatorado em um caso de uso abstrato para simplificar o caso de uso Inserir Ordem. O caso de uso Fornecer Dados do Cliente representa um segmento do comportamento que foi fatorado, desde que seja uma função separada da qual apenas o resultado esteja afetando o caso de uso Inserir Ordem. O caso de uso Fornecer ________________________________________________________________________ Prof. M.Sc. Cleuber Fernandes 12
    • Dados do Cliente também pode ser reutilizado em outros casos de uso. Tanto o caso de uso Solicitar Catálogo quanto o Fornecer Dados do Cliente são abstratos neste exemplo. Este diagrama de casos de uso mostra parte do modelo de casos de uso de um Sistema de Gerenciamento ________________________________________________________________________ Prof. M.Sc. Cleuber Fernandes 13
    • 9. Especificações em Linguagem Natural Estruturada É UMA FORMA RESTRITA DA LINGUAGEM NATURAL, QUE SE DESTINA A ESCREVER REQUISITOS DE SISTEMA. A vantagem dessa linguagem é que ela mantém a facilidade de expressão e compreensão da linguagem natural, mas GARANTE QUE ALGUM GRAU DE UNIFORMIDADE seja imposto à especificação, obtido pelo uso de templates. O RUP propõe um padrão para especificação de requisitos de sistema, usando linguagem natural estruturada, chamado “ESPECIFICAÇÃO OU DESCRIÇÃO DE CASO DE USO”, como segue: Caso de Uso: Fazer checkin de hóspede. Descrição: Realiza a hospedagem eletrônica do hóspede no sistema. Fluxo principal: 1. O recepcionista seleciona apto disponível; 2. O recepcionista digita os dados pessoais do hóspede; 3. O recepcionista informa o desconto combinado; 4. O recepcionista confirma checkin. 5. O sistema solicita confirmação de impressão. 6. O sistema registra dados no banco de dados; 7. O sistema imprime comprovante de checkin. 8. O caso de uso termina. Fluxos alternativos: 1. O recepcionista não informou todos os dados exigidos, o sistema emite uma mensagem com uma lista de itens não fornecidos e sugere que os forneça. 2. Por algum motivo não é possível realizar as alterações requisitadas. Neste caso o sistema informa o problema e sugere que o processo seja refeito. Entradas: Número do apto, dados pessoais do hóspede, valor da diária e desconto. Origem: Número do apto, dados pessoais do hóspede e desconto são informados pelo usuário; Valor da diária é obtido da base de dados. Saída: Confirmação de hospedagem. Destino: Impressora padrão (usuário) e base de dados. Pré-condição: A seleção de um apto disponível. Pós-condição: Dados gravados na base de dados e botão do apto exibido em vermelho, indicando que está ocupado. ________________________________________________________________________ Prof. M.Sc. Cleuber Fernandes 14
    • 9. O Documento de Requisitos de Software Às vezes chamado de Especificação de Requisitos de Software é a declaração oficial do que é exigido dos desenvolvedores de sistema. Ele deve conter os requisitos de usuário e de sistema. O documento de requisitos tem um conjunto diversificado de usuários, abrangendo desde a alta gerência da organização até os engenheiros responsáveis pelo desenvolvimento do software. A figura abaixo mostra os possíveis usuários do documento e como o utilizam. Especificam os requisitos e os lêem para verificar Clientes se eles atendem a suas necessidades. Especificam as mudanças nos requisitos. Usam o documento de requisitos para elaborar Gerentes proposta e planejar o processo de desenvolvimento do sistema. Usam os requisitos para compreender que sistema Engenheiros de deve ser desenvolvido. Sistema Utilizam os requisitos para desenvolver testes e Engenheiros de validação para o sistema. teste Usam os requisitos para ajudar a compreender o Engenheiros de sistema e as relações entre suas partes. manutenção Pontos-Chave • Os requisitos para um sistema de software estabelecem o que o sistema deve fazer e definem restrições sobre sua operação e implementação. • Os requisitos funcionais são declarações de funções que o sistema deve fornecer ou são descrições de como alguns cálculos devem ser realizados. Os requisitos de domínio são requisitos funcionais, provenientes de características do domínio de aplicação. • Os requisitos não funcionais são os requisitos do produto, que restringem o sistema a ser desenvolvido, os requisitos de processo que se aplicam ao processo de desenvolvimento e os requisitos externos. Eles freqüentemente se relacionam às propriedades emergentes do sistema e, portanto, se aplicam ao sistema como um todo. • Os requisitos de usuário se destinam às pessoas envolvidas no uso e na aquisição do sistema. Eles devem ser escritos utilizando-se linguagem natural, tabelas e diagramas, de modo que sejam compreensíveis. ________________________________________________________________________ Prof. M.Sc. Cleuber Fernandes 15
    • • Os requisitos de sistema se destinam a comunicar, de modo preciso, as funções que o sistema tem de fornecer. Para reduzir a ambigüidade, eles podem ser escritos em uma linguagem estruturada de algum tipo, que pode ser um formulário estruturado de linguagem natural. • O documento de requisitos de software é a declaração explícita estabelecida dos requisitos do sistema. Ele deve ser organizado de modo que possa ser utilizado pelos clientes de sistema e pelos desenvolvedores de software. ________________________________________________________________________ Prof. M.Sc. Cleuber Fernandes 16