ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

1

- MÓDULO 2 - ANÁLISE DE REQUISITOS DE SOFTWARE APLICATIVO

1. INTRODUÇÃO Entender os requisitos de um problema está entre as tarefas mais difíceis na construção de um software. Na maioria das vezes o cliente não sabe o que é necessário, os usuários finais não sabem descrever as funcionalidades que lhe trarão benefícios e suas necessidades certamente mudarão ao longo do projeto. Diante deste cenário, antes de qualquer trabalho técnico é importante a aplicação de um conjunto de tarefas da Engenharia de Requisitos. Estas levam a um entendimento de qual será o impacto do software sobre o negócio, o que o cliente quer e como os usuários finais irão interagir com o sistema. Tudo isso objetivando especificações precisas do comportamento do software e sua evolução.

Segundo Pressman, na perspectiva do processo de software, a engenharia de requisitos é uma ação importante que se inicia durante a atividade de comunicação e continua na modelagem, construindo uma ponte para o projeto e para a construção. 2. REQUISITO

Um requisito é definido como “uma condição ou uma capacidade com a qual o sistema deve estar de acordo”. Pode ser desde uma indicação abstrata, de alto nível, até uma especificação matemática detalhada.

Em resumo, definem o que o sistema deve fazer e sob quais limitações ele é requisitado a operar.

São exemplos de requisitos: - “O sistema deve ser capaz de dar baixa no pagamento de uma Nota Fiscal”; - “O sistema deve ser capaz de realizar pagamentos por transferências bancárias”; - “O sistema deve suportar pelo menos 20 transações por segundo”; - “O sistema deve realizar backup uma vez por dia.”

3. IDENTIFICAÇÃO E ELICITAÇÃO DE REQUITOS Da perspectivas da Engenharia de Software, a Elicitação de Requisitos é talvez a parte mais crítica do processo de desenvolvimento de software. Estudos indicam que os requisitos que foram detectados depois do software implementado ou erros na análise de requisitos são até 20 vezes mais caros de se corrigir do que qualquer outro tipo de erro. Enfim, o sucesso das etapas posteriores depende da qualidade dos requisitos gerados. A Elicitação de Requisitos corresponde a identificar junto aos clientes/usuários quais são os objetivos do sistema, o que deve ser acompanhado, como o sistema se encaixa no contexto de necessidades do negócio e como será a utilização do sistema no dia-a-dia.

No processo de especificação dos requisitos alguns fatores constituem um problema. São aspectos a serem observados: - Virem de várias fontes; - Não refletirem as reais necessidades dos usuários do sistema; - Serem inconsistentes e/ou incompletos;

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

2

- Podem ter um alto custo para mudanças, depois de acordados; - Mal entendidos entre clientes e desenvolvedores.

Neste cenário uma ilustração bastante pertinente é a apresentada na figura 1.

Figura 1 - Requisitos

Para ajudar a superar este problemas, os desenvolvedores deve abordar os requisitos de

forma simples, prática e organizada. Os seguinte passos são recomendados: - Avaliar a viabilidade técnica e de negócio para o sistema proposto; - Identificar as pessoas que vão auxiliar a explicar os requisitos e compreender seus preconceitos organizacionais; - Definir o ambiente técnico no qual o sistema será instalado; - Identificar regras de domínio que limitam a funcionalidade ou desempenho do software a ser construído; - Definir um ou mais métodos de elicitação dos requisitos; - Solicitar a participação de várias pessoas a partir de diversos pontos de vista; - Identificar requisitos ambíguos que serão candidatos a prototipação. Os documentos criados como consequência da elicitação de requisitos dependerá do tamanho do software a ser construído: - As necessidades e viabilidades estruturadas; - Limite de escopo do software;

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

3

- Lista de clientes/usuários que participaram da elicitação de requisitos; - Cenários de usos capazes de fornecer uma ideia de uso sistema; - Protótipo que porventura tenha sido desenvolvido. Cada documento deve ser revisado por todos que participaram desta fase do projeto. Uma boa elicitação de requisitos parte das seguinte características: - Definir técnicas de coleta baseadas em fatores operacionais, táticos e financeiros; - Criar um planejamento capaz de alcançar as metas estabelecidas, como prazo, curso e qualidade; - Promover a integração e comprometimento de todos os envolvidos no processo; - Identificar os documentos e procedimentos que definem as politicas de negócio da empresa. 3.1. Técnicas para Elicitação de Requisitos

Para realizar a elicitação de requisitos é possível a aplicação de algumas técnicas, a saber: - Reuniões formais; - Reuniões informais; - Entrevistas; - Questionários; - Brainstorming; - Cenários (Caso de Uso);

- Prototipação; - Análise de Documentos; - Manual de Sistemas Legados. - JAD (Join Application Development); - Observações e análises sociais (etnografia); - Workshops (Brainstorming, interpretação de papéis, revisão de requisitos existentes);

3.2. Fases da Elicitação de Requisitos Um projeto de Elicitação de Requisitos tem as seguinte fases: - Planejamento (Como deve ser feito): Identificar fontes e técnicas; - Elicitação de Requisitos (O que deve ser coletado): Identificar funcionalidades, identificar requisitos e riscos; - Documentação (Como devo documentar): Documento de visão. 3.3. Identificação dos Requisitos Identificar requisitos significa identificar as funcionalidades que o software deve ter para atender as necessidades do usuário. Fazer esta identificação significa responder a duas perguntas: - O que o software deve fazer? - Quais funcionalidades ele deve ter? É necessário ainda identificar as principais características do software como: - Performance: Qual é o tempo de resposta adequado? - Segurança: Quais requisitos de segurança o software precisa? - Usabilidade: O software deve seguir uma identidade visual e as interfaces devem ser intuitivas e amigáveis.

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

4

3.4. Tipos de Requisitos Os requisitos podem ser divididos em duas categorias, conforme figura 2:

Figura 2 – Requisitos de Software

3.4.1. REQUISITOS FUNCIONAIS Estes definem funcionalidades do sistema, ou seja, aquilo que deve fazer, as funções necessárias para atender os objetivos da aplicação. Exemplo: - Cadastrar Alunos; - Emitir Boletim de notas; - Fazer uma transação no banco de dados; - Cadastrar um registro de atendimento; - Imprimir relatórios; - Etc.

Podem ser escritos em alto nível, se forem voltados ao cliente, ou podem ser especificados em detalhe, para desenvolvedores. 3.4.2. REQUISITOS NÃO FUNCIONAIS Expressam restrições sob as quais o sistema deve operar ou qualidades específicas que o software deve ter, como performance, portabilidade, segurança, usabilidade, etc. Descrevem também a qualidade do serviço (QoS). A não consideração ou esquecimento desses fatores constitui uma das principais razões de uma eventual insatisfação dos usuários com relação ao software. Os requisitos não funcionais também são chamados de RNF ou Requisitos Suplementares. Exemplo: - Confidencialidade; - Portabilidade; - Confiabilidade; - Precisão; - Performance; - Integridade; - Qualidade; - Segurança; - Usabilidade; - Etc. Os requisitos não funcionais dividem-se em outros três grupos de requisitos:

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

5

a) Requisitos do produto: Requisitos que especificam que o software entregue deve se comportar de um determinado modo, por exemplo: ser confiável, robusto, rápido, etc.

b) Requisitos organizacionais: Requisitos que são consequência das políticas e procedimentos organizacionais, como padrões, processos, etc.

c) Requisitos externos: Requisitos que são externos ao sistema e seu desenvolvimento, por exemplo: legislação, interoperabilidade, etc.

A figura 3 ilustra ainda suas subdivisões:

Figura 3 – Requisitos não Funcionais e suas ramificações

Os Requisitos não funcionais podem ser extremamente difíceis de especificar

precisamente. Porém, devem ser verificáveis usando alguma medida que possa ser objetivamente testada, como propõe a tabela 1. Tabela 1 - Mensuração de RNF PROPRIEDADE MEDIDA Desempenho Transações por segundo; Tempo de resposta para eventos; etc. Armazenamento Megabytes; Número de chips ROM; Usabilidade Tempo de treinamento; Número de cliques de mouse; Confiabilidade Tempo médio entre falhas; Taxa de ocorrência de falhas; Disponibilidade; Robustez Tempo para recomeçar depois de uma falha; Probabilidade de corrupção

de dados após falha; Portabilidade Porcentagem de declarações dependentes de plataforma; Número de

plataformas-alvo. Além dos requisitos funcionais e não funcionais existem ainda outras definições de requisitos que não serão estudadas, mas que valem ser citadas: - Requisitos de Domínio: vêm do domínio da aplicação do sistema e refletem características do domínio. São transformados, posteriormente, em requisitos funcionais ou restrições (RNFs). Exemplo: A desaceleração do trem deve ser computada como: Dtrem = Dcontrole + Dgradiente; - Requisitos permanentes (estáveis): derivados da atividade principal da organização. Exemplo: em um hospital sempre haverá requisitos relativos aos médicos, aos pacientes, aos tratamentos, etc. Derivados do modelo de domínio;

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

6

- Requisitos Voláteis: Requisitos que se modificam durante o desenvolvimento ou quando o sistema está em uso. Exemplo: Requisitos resultantes de políticas governamentais; 3.5. Identificação de Riscos Os riscos são a principal razão de falhas em um projeto de software. Identificando-os é possível criar um plano para reduzi-los. No documento de visão é necessário identificar uma lista de riscos existentes, como: - Política: Influência de política de negócios, leis, decretos ou normas que regulam a finalidade da aplicação; - Tecnologia: Ferramentas emergentes e integração com sistemas legados; - Recursos: Orçamento restrito, contratação de terceiros; - Habilidade: Falta de domínio da tecnologia (habilidade e experiência); - Requisitos: Requisitos não plenamente conhecidos. 3.6. Identificação das Restrições São restrições impostas sobre o desenvolvimento de software, como a adequação a custos e prazos, a plataforma tecnológica, aspectos legais (licenciamento), limitações sobre a interface do usuário, componentes de hardware e softwares a serem adquiridos. Exemplo: - O projeto requer uma tecnologia como webservices; - Necessita de hardware específico como um servidor exclusivo de banco de dados. 3.7. Documentos de Visão Depois de concluída a identificação e elicitação de requisitos é necessário documentar o que foi feito através do Documento de Visão. Este documento tem as seguinte seções: - Declaração dos problemas; - Lista de Stakeholders; - Lista de requisitos; - Lista de Riscos; - Lista de Restrições. Um exemplo simples de documento de visão pode ser visto na figura 4.

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

7

Figura 4 – Documento de Visão

Fonte: Rildo F. Santos 4. ANÁLISE DE REQUISITOS

Depois que os requisitos foram coletados, os produtos de trabalho servem como base para a análise de requisitos. A análise de requisitos visa a descobrir alguns problemas e torná-los mais consistentes antes da especificação formal.

Neste ponto, o documento de visão é um documento importante na análise de requisitos. A análise de requisitos deve ser: - Correta: O requisito deve ser encontrável no software; - Não ambígua: Deve ter apenas uma interpretação; - Completa: Deve incluir RF e RNF; - Consistente: Não existir conflito entre os requisitos; - Verificável: Possibilidade de verificar e validar cada requisito; - Modificável: Requisitos serem facilmente alterados.

4.1. Atividades da Análise de Requisitos A análise de requisitos possibilita ao analista especificar as funcionalidades, classificando e detalhando os requisitos encontrados na coleta. Os requisitos funcionais serão descritos e os não funcionais serão classificados. As figuras 5, 6 e 7 exemplificam estas atividades.

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

8

Figura 5 – Descrição de Requisito Funcional

Fonte: Rildo F. Santos

Figura 6 – Descrição de Requisito não Funcional

Fonte: Rildo F. Santos

Figura 7 – Lista de Stakeholders

Fonte: Rildo F. Santos Além disso, os requisitos devem ser priorizados e negociados com o cliente. Esta atividade é importante para conciliar conflitos com os stakeholders. Eles podem pedir mais do que pode ser feito, ou ainda terem necessidades especiais. 4.2. Documento de Requisitos O resultado final desta fase é um documento de requisitos cujo objetivo é classificar e descrever os requisitos de software, usuários e entidades externas.

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

9

O formado do documento de requisitos é sugerido pela IEEE/ANSI 830-1993 e propõe a estrutura exemplificada na figura 8.

Figura 8 – Documento de Requisitos

5. ESPECIFICAÇÃO DE REQUISITOS

O termo especificação tem vários significados , podendo ser: - Um documento escrito; - Um modelo gráfico; - Um modelo matemático formal; - Uma coleção de cenários de uso, etc.

A abordagem utilizada depende da necessidade específica de cada projeto, podendo ser

documentos escritos combinados com modelos gráficos para sistemas maiores e cenários de uso para sistemas mais simples, etc. Os diagramas da UML podem ser largamente empregados para esta tarefa como se vê no esquema da figura 9.

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

10

Figura 9 – Esquema para Especificação de Requisitos

Fonte: Rildo F. Santos 5.1. Especificação de Requisitos com Caso de Uso Após a análise de requisitos o documento a ser elaborado é a Especificação de Requisitos, feitas com Caso de Uso segundo a especificação da UML. Um conjunto de Casos de Uso é importante para se compreender o que o usuário quer. Um caso de uso descreve uma funcionalidade (requisito) a ser oferecido pelo sistema. Os casos de uso expressam: - Diálogo entre usuário e sistema; - O que o sistema deve fazer. (Não como fazer); - Formam a base para teste e documentação. 5.2. Casos de Uso

É uma técnica desenvolvida por Ivar Jacobson e são parte integrante da UML. São descrições textuais das funcionalidades do sistema a partir da perspectiva do usuário.

Além da aplicação na especificação de requisitos, os casos de uso são utilizados por Arquitetos, Analistas, Projetistas e Implementadores, Testadores, Gerentes e Escritores da documentação.

Os diagramas de caso de uso fazem com que o sistema, subsistemas e classes fiquem acessíveis e compreensíveis, por apresentarem uma visão externa sobre como esses elementos interagem com o sistema.

Um exemplo de caso de uso pode ser observado na figura 10.

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

11

Figura 10 – Caso de Uso – Sistema de Vendas

5.2.1. NOTAÇÃO

O diagrama de Caso de Uso é representado por atores, casos de uso e relacionamentos entre estes elementos.

Estes relacionamentos podem ser: - associações entre atores e casos de uso; - generalizações entre os atores; - generalizações, extends e includes entre os casos de uso.

5.2.1.1. Ator Os casos de uso são executados por atores. Eles constituem as entidades externas do ambiente do sistema. São papéis que os usuários do sistema devem desempenhar nas interações. Uma “instância de ator” pode ser desempenhada tanto por um indivíduo quanto por um sistema ou mesmo por um dispositivo. É representado conforme figura 11.

Figura 11 – Ator

É importante ressaltar que os atores representam papéis/perfis e não pessoas. Tipicamente os atores são identificados nas declarações de problemas do Documento de Visão ou através de entrevista com stakeholders.

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

12

5.2.1.2. Generalização/Especialização de Atores

É possível definir tipos gerais de atores e especializá-los usando o relacionamento de especialização, conforme exemplificado na figura 12.

Figura 12 – Especialização de Ator

Deve-se usar quando um ator (filho) é um tipo de outro ator mais genérico (pai).

5.2.1.3. Caso de Uso

Um caso de uso é representado por uma elipse e um rótulo com o nome do caso de uso, conforme figura 13. Um caso de uso define uma grande função do sistema. A implicação é que uma função pode ser estruturada em outras funções e, portanto, um caso de uso pode ser estruturado.

Figura 13 – Caso de Uso

5.2.1.4. Relacionamento entre um ator e um caso de uso

Define uma funcionalidade do sistema do ponto de vista do usuário, conforme figura 14.

Figura 14 – Relacionamento entre ator e caso de uso

5.2.1.5. Relacionamento de Inclusão

Um Caso de Uso base incorpora o comportamento de outro Caso de Uso. O relacionamento é utilizado para evitar a descrição do mesmo fluxo de eventos várias vezes.

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

13

Figura 15 – Relacionamento de Inclusão

Deve-se usar quando o mesmo comportamento se repete em mais de um Caso de Uso e o

processo de realizar X sempre envolve realizar Y pelo menos uma vez. 5.2.1.6. Relacionamento de Extensão Modela partes opcionais da execução de um Caso de Uso. Modela fluxos que são executados somente em determinados casos, sob determinadas circunstâncias ou que dependem de escolha de um ator.

Figura 16 – Relacionamento de Extensão

Deve-se usar quando se deseja modelar um comportamento opcional de um Caso de Uso.

5.2.1.7. Relacionamento de Generalização/Especialização Relaciona um Caso de Uso especializado a um mais geral. O filho herda o comportamento do pai, podendo adicionar e redefinir passos em pontos arbitrários do comportamento original, conforme ilustra a figura 17.

Figura 17 – Relacionamento de Generalização

Deve-se usar quando se necessita identificar Casos de Uso semelhantes e um deles for uma forma especial (uma especialização) do outro.

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

14

Na figura 18 é possível observar outro exemplo de caso de uso.

Figura 18 – Caso de uso

5.2.2. TIPOS DE CASO DE USO Os casos de uso podem ser concretos ou abstratos. Um caso de uso concreto é iniciado por um ator e constitui um fluxo completo de eventos. Um caso de uso abstrato nunca é instanciado diretamente. Casos de uso abstratos geralmente são:

- Incluídos em outros Casos de Uso; - Estendidos de outros Casos de Uso; - Generalizações de outros Casos de Uso. Atores “enxergam” apenas casos de uso concretos.

5.2.3. CASOS DE USO E CENÁRIOS Os casos de uso exibem as funcionalidades na perspectiva do usuário. Contudo, é possível completar esta função através da construção de cenários. Um cenário é como uma instância de um caso de uso, isto é, um caminho lógico com início e fim. Suas principais características são: - Não contém declarações condicionais; - Pode ter o mesmo começo, mas com fim diferente; - É uma narrativa de uma situação; - Devem descrever os caminhos corretos e errados.

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

15

Exemplo: “Em uma loja é descrito o cenário de compra de um produto: O cliente navega no catálogo de itens e adiciona-os a sua cesta de compras. Quando o cliente deseja pagar, fornece os dados do cartão de crédito e finaliza a compra. O sistema solicita o endereço para entrega do pedido. O sistema verifica a autorização do cartão e confirma a transação enviando um e-mail para o usuário.” Este é um dos possíveis cenários. Caso haja algum problema neste processo teremos um novo cenário. 5.2.4. FORMULÁRIO/ESPECIFICAÇÃO DE CASO DE USO

Todo diagrama de caso de uso é acompanhado de um documentos denominado especificação de caso de uso. A seguir podemos observar um exemplo de especificação do caso de uso Fazer Pedido.

Tabela 2 - Especificação de Caso de Uso

NÚMERO UC001 CASO DE USO Fazer Pedido DESCRIÇÃO Caso de uso que especifica o fluxo de ações para o cliente fazer um

pedido no Sistema ATOR Cliente FLUXO PRINCIPAL Realizar o pedido de um produto P1. O caso de uso começa quando o cliente seleciona a opção “Fazer Pedido”; P2. O cliente fornece seu nome e endereço e fornece o código do produto [EXT1]; P3. O sistema fornece a descrição e o preço do produto [INC1]; P4. O cliente fornece as informações de pagamento e escolhe a opção “confirmar” [A1]; P5. O sistema verifica as informações fornecidas e envia os dados para o sistema de pagamento [E1]; P6. O caso de uso é encerrado. FLUXO ALTERNATIVO A1. No passo P4 cliente seleciona a opção “cancelar”; A1.1 O sistema não grava o pedido e o fluxo retorna para o passo P6. PONTOS DE EXTENSÃO EXT1. O sistema estende o caso de uso “Pedido em Oferta”. PONTOS DE INCLUSÃO INC1. O sistema inclui o caso de uso “Dar informação do produto”. REQUISITOS ESPECIAIS O usuário deve estar cadastrado no sistema. FLUXO EXCEPCIONAL E1. No passo P5 o sistema verifica que as informações fornecidas estão incorretas; E1.1 O sistema pede ao cliente para corrigir as informações e o fluxo retorna ao passo P4. PRÉ CONDIÇÃO Usuário deve estar logado no sistema. PÓS CONDIÇÃO O pedido deve ter sido gravado no sistema e marcado como

confirmado. Além das informações contidas na tabela 2, o Caso de Uso pode conter outros dados, como:

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

16

- Requisitos não Funcionais relacionados - Diagrama de atividades relacionado - Protótipo de interface - Outros diagramas O importante é que as necessidades sejam entendidas e acordadas por todas as partes

interessadas. 5.2.5. PASSOS PARA ESPECIFICAÇÃO DE REQUISTOS COM CASO DE USO a) Identifique quais requisitos se relaciona com os casos de uso; b) Identifique os atores e seus papeis; c) Determine um nome para o caso de uso, que deve ser único; d) Escreva cenários para o caso de uso; e) Compile os cenários em um único formulário denominado especificação de caso de uso;

f) Faça o diagrama de caso de uso.

6. VALIDAÇÃO DE REQUISITOS

Esta etapa visa demonstrar que os requisitos definem o sistema que o usuário realmente deseja. É uma etapa importante uma vez que o custo para remover um erro de requisito é grande.

A validação de requisitos visa a assegurar que: - A versão do documento de requisitos descreve as funcionalidades e características do

sistema satisfatoriamente; - Os requisitos são consistentes e de alta qualidade; - O documento de requisitos provê uma base adequada para Projeto e Implementação.

6.1. Técnicas de Validação de Requisitos Para validação de requisitos podem ser utilizadas as seguintes técnicas: a) Revisões (inspeções): Um grupo de pessoas se reúne, lê e analisa os requisitos, para identificar problemas e suas possíveis soluções.

b) Prototipagem: Um protótipo executável demonstra os requisitos e ajudam os stakeholders a descobrir problemas.

c) Geração de Casos de Teste: Casos de teste ajudam a mostrar se os requisitos estão ambíguos ou incompletos.

Revisões regulares devem ocorrer durante a formulação e definição dos requisitos. Tanto o cliente como a equipe de projeto devem estar envolvidas na revisão que podem ser formais (com documentos completos) ou informais. Uma boa comunicação pode evitar problemas nos estágios finais.

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

17

7. GERENCIAMENTO DE REQUISITOS

É o processo de gerenciar as mudanças nos requisitos durante o processo de Engenharia de Requisitos.

Os requisitos são, inevitavelmente, incompletos e inconsistentes. Novos requisitos surgem à medida que as necessidades de negócios mudam e há um melhor entendimento do sistema.

Diferentes pontos de vista normalmente têm requisitos diferentes (e conflitantes). Diante disso é possível afirmar que os requisitos sempre mudam, bem como a prioridade de cada um ao longo do projeto, como ilustra a figura 19.

Figura 19 – Evolução dos requisitos

Considerando que o ambiente de negócio e tecnológico do projeto mudam durante seu

desenrolar é necessário gerenciar tudo isso. Durante o processo de engenharia de requisitos, será necessário planejar: - A identificação dos requisitos: Como os requisitos são individualmente identificados; - Um processo de mudança de gerenciamento; - Políticas de rastreabilidade: Manter o histórico dos requisitos, rastrear suas mudanças e seus possíveis impactos; - Suporte de ferramenta: Necessário para auxiliar no processo de gerenciamento. 7.1. Rastreabilidade A rastreabilidade preocupa-se com as relações entre requisitos, suas fontes e o projeto do software.

- Rastreabilidade de Fonte: Ligação entre o requisito e o stakeholder que o propôs (e sua necessidade original);

- Rastreabilidade de Requisitos: Ligações entre requisitos que dependem entre si; - Rastreabilidade de Projeto: Ligação entre o requisito e o projeto (arquitetura, módulos,

código) do software. 7.2. Ferramentas

É impossível rastrear requisitos sem uma ferramenta CASE adequada. Ela deve: - Armazenar os requisitos em um ambiente seguro e gerenciado; - Dar suporte ao gerenciamento de mudança dos requisitos;

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

18

- Permitir recuperar automaticamente a ligação (rastreabilidade) dos requisitos. 7.3. Gerenciamento de Mudanças de Requisitos Deve ser feito em qualquer proposta de mudança de requisito. Segue os seguintes estágios, conforme figura 20.

Figura 20 – Gerenciamento de mudança de requisitos

- Análise do problema e especificação da mudança. Discute-se os problemas com os requisitos e propõe-se mudanças. - Análise e custo da mudança. Avalia-se os efeitos da mudança em outros requisitos do sistema. - Implementação das mudanças. O documento de requisitos e outros documentos são alterados de forma a refletir as mudanças. 8. BIBIOGRAFIA BÁSICA PRESSMAN, R. S. Engenharia de Software. São Paulo. Makron Books, 2006. SOMMERVILLE, Ian. Engenharia de Software - Ed. Prentice Hall, 2007. SANTOS, F. Rildo. Análise de Requisitos de Software. Material instrucional. Norma IEEE/ANSI 830/1993