PLATAFORMA DE DESENVOLVIMENTO PINHÃO PARANÁ MDS METODOLOGIA DE DESENVOLVIMENTO DE SERVIÇOS GREQ GUIA DE ESPECIFICAÇÃO E GERENCIAMENTO DE REQUISITOS

Transcrição

1 PLATAFORMA DE DESENVOLVIMENTO PINHÃO PARANÁ MDS METODOLOGIA DE DESENVOLVIMENTO DE SERVIÇOS GREQ GUIA DE ESPECIFICAÇÃO E GERENCIAMENTO DE REQUISITOS Fevereiro/2007

2 Sumário de Informações do Documento Tipo do Documento: Definição Título do Documento: GREQ Guia de Especificação e Gerenciamento de Requisitos Estado do Documento: EB (Elaboração) Responsáveis: Equipe GIC Palavras Chaves: Modelo, Processo de Desenvolvimento, Especificação de Requisitos, MDS, Estrutura Resumo: Documento que descreve a Especificação de Requisitos de Software Número de páginas: 29 Software utilizados: Open Office Versão Data Mudanças /09/97 Elaborado por Cristina: Primeira versão da nova estrutura do Guia de Especificação de Requisitos /10/97 Elaborado por Cristina: Complementação com a norma do IEEE /10/97 Organização da norma IEEE em etapas do roteiro e inclusão de check list de requisitos /01/98 Inclusão das questões levantadas na revisão do dia 05/1/98 com Alcion, Dante, Jumara, Lucília e Luiz Carlos. Figura da Aplicação alterar para que se tenha um entendimento de todos os processos da MDS. Problemas na diferenciação de requisitos e restrições foi estipulado que requisitos seria utilizado para o software e restrições para o projeto. Existem palavras que foram escritas em itálico, negrito e sublinhado que deverão ser rediscutidas. Alteração da numeração dos títulos /01/98 Separação do roteiro e inclusão do mesmo do RDES /01/98 Inclusão de correções de português e melhorias no texto apontadas pela Jumara /03/98 Transformação do roteiro em guia de Especificação de Requisitos /03/98 Alteração dos itens levantados na revisão com os coordenadores de equipe. Principais questões: o item 2 (aplicação) deverá ser relacionado com os roteiros existentes de desenvolvimento (RAES, C/S e RNOT). Alterações das questões do check list /03/98 Revisão feita pela Lília em 24/03/98 onde foi proposta a alteração da estrutura do guia através da transformação das tarefas em fases e foi revisada a lista de atividades /04/98 Separação do check list por fases do processo de desenvolvimento. Inclusão da definição de 3 baselines para a geração da especificação de requisitos. Decisões tomadas em 06/03/98 pela Cristina, Dante e Lília m consequência do projeto piloto SIA /04/98 Inclusão do check list para o Projeto Preliminar e alteração dos check list s /05/98 Inclusão do Gerenciamento de Requisitos no anexo 6.4 e no nome do documento e dos comentários da Jumara. ' Revisão por Danielle Mayer ( Revisão destinada a retirar referências à documentos inexistentes e referências a roteiro notes) Organização da Lista para Levantamento de Requisitos Internos e Externos e referências à anexos.

3 3 SUMÁRIO 1 INTRODUÇÃO APLICAÇÃO REFERÊNCIAS ESTRUTURA DO GUIA DESCRIÇÃO DO GUIA FASE GREQ/LR - LEVANTAR REQUISITOS FASE GREQ/AR - ANALISAR REQUISITOS ANEXOS LISTA PARA LEVANTAMENTO DE REQUISITOS INTERNOS E EXTERNOS EXEMPLOS DE REQUISITOS GERENCIAMENTO DE REQUISITOS Identificar Mudanças de Requisitos Avaliar Impactos Documentar Mudanças de Requisitos Aprovar Mudanças de Requisitos e Planos do Projeto PRODUTOS EXEMPLO DE GERÊNCIA DE REQUISITOS DO PROJETO Sumário Requisitos do Projeto GERENCIAMENTO DE REQUISITOS E CMM ESCLARECIMENTOS FINAIS...26

4 4 1 INTRODUÇÃO O GREQ Guia de Especificação de Requisitos de Software tem por finalidade orientar na elaboração de um conjunto de requisitos que representem as necessidades implícitas e explícitas que o software terá que atender, as restrições do projeto e os compromissos assumidos durante a execução do projeto. Este conjunto de requisitos é representado através da geração do documento Requisitos do Projeto. 2 APLICAÇÃO Este guia tem como característica a sua utilização tanto no RPRE Roteiro de Projeto Preliminar quanto em qualquer fase do Processo de Desenvolvimento. Este fato se deve à necessidade de se especificar requisitos durante o RPRE Roteiro de Projeto Preliminar, onde se define a solução a ser adotada e o Planejamento do Projeto. Os requisitos na fase de Projeto Preliminar são mais genéricos e são a base para a definição da solução. Também existe a necessidade de se detalhar estes requisitos à medida que os conhecimentos sobre o software a ser desenvolvido vão se consolidando. Este fato ocorre durante todo o Processo de Desenvolvimento. Outra característica dos Requisitos do Projeto é a sua geração independentemente de tecnologia, portanto este deverá ser gerado de forma paralela à execução dos roteiros que descrevem uma técnica de desenvolvimento. Durante a execução do projeto os requisitos podem sofrer modificações (inclusão, alteração e exclusão). Bem como, podem ser alteradas as prioridades, os riscos e restrições associados ao requisito ou ao projeto. Estas situações ocorrem devido a constantes mudanças de necessidades e de tecnologias utilizadas, das alterações provocadas pelo aprendizado do problema, seu contexto e sua solução. Esta contínua evolução é considerada difícil de ser eliminada e quando isto ocorrer utilizar o anexo 6.3 Gerenciamento de Requisitos que contêm orientações para serem executadas a serem seguidas.

5 5 3 REFERÊNCIAS IEEE Std , IEEE Guide for Developing System Requirements Specifications; New York: IEEE, 1996, ANSI/IEEE; IEEE Std , IEEE Guide to Software Requirements Specifications, New York: IEEE, 1984, ANSI/IEEE; ISO/IEC 12207, Information technology: Software life cycle processes, first edition, ; Paulk, M.; et all, Capability Maturity Model for Software, Version 1.1. Technical Report CMU/SEI 93 TR 24, Carnegie Mellon University Software Engineering Institute Pittsburgh, ; NBR 13596, Tecnologia da Unformação: Avaliação de Produto de Software Características de Qualidade e guia para o seu uso; primeira edição, ESTRUTURA DO GUIA A seguir, apresenta se uma representação gráfica do guia: Requisitos, restrições e compromissos Fase: Levantar Requisitos Fase: Analisar Requisitos Decisões sobre alocação de Produto: Requisitos do Projeto Gerenciamento de Requisitos

6 6 5 DESCRIÇÃO DO GUIA A especificação de requisitos inicia se com uma idéia ou concepção originada de uma necessidade de mercado, de uma imposição legal ou regulamentação, de um desejo de se criar ou melhorar um software ou processo, de uma necessidade de alterar um sistema já existente, ou de algum outro ato ou necessidade percebida. A primeira concepção dos requisitos é retratada quando da criação do Projeto Preliminar (produto do RPRE). Este guia tem como objetivo detalhar estes requisitos já levantados, bem como incluir requisitos que não haviam sido percebidos ou alterar requisitos que foram se modificando durante a execução do projeto. A Especificação de Requisitos tem por objetivo gerar o documento Requisitos do Projeto. Este é utilizado como instrumento para comunicar as necessidades do cliente para os técnicos de informática que irão projetar e construir o software. Dentro deste contexto o documento necessita ser escrito de forma clara e precisa para que tanto o cliente como os técnicos de informática entendam o seu conteúdo e possam projetar o software de modo a satisfazer o especificado. 5.1 fase GREQ/LR Levantar requisitos Nesta fase o técnico deverá identificar os requisitos do produto, restrições do projeto e compromissos do projeto. Os requisitos do produto devem ser extraídos do Projeto Preliminar e complementados por outros documentos do cliente, através de um exercício conduzido de análise. O objetivo deste processo interativo é levantar os requisitos do produto assegurando que cada requisito seja descrito formalmente. Os requisitos do produto são classificados em duas categorias: requisitos externos e internos. O requisito externo representa os resultados da definição de necessidades explícitas e implícitas do cliente, bem como a descrição do que o cliente deseja fazer com o software, quais são as funções do software, o desempenho esperado, a interface com outros elementos do sistema, além das outras expectativas de qualidade.

7 7 Os requisitos internos, na maioria das vezes, são identificados através do técnico de informática, pois eles não são facilmente percebidos pelo cliente. Estes requisitos são necessários para proporcionar ao produto de software o atingimento dos requisitos externos de qualidade especificados e estão normalmente ligados às questões de qualidade de software: manutenibilidade, portabilidade e eficiência. Para facilitar o levantamento dos requisitos foi elaborado um conjunto de possíveis atividades a serem desenvolvidas, retratadas em uma Lista para Levantamento de Requisitos Internos e Externos (veja Anexo 6.1 Lista para Levantamento de Requisitos Internos e Externos). Como forma de complementar os requisitos do produto é necessária a identificação das restrições do projeto ou dos próprios requisitos. Estas também deverão ser baseadas no Projeto Preliminar. Uma lista foi elaborada para auxiliar no levantamento das restrições: Lista para Levantamento de Restrições do Projeto Definição de expectativas de prazos. Definição de custos e disponibilidade de recursos financeiros pelo cliente. Disponibilidade de recursos financeiros pela CELEPAR para investimento em ferramentas e tecnologia. Identificação de riscos técnicos. Identificação de volumes envolvidos na execução. Disponibilidade de recursos humanos e tecnológicos. Imposições legais. Necessidade de compatibilização do novo software com o legado existente. Necessidade de migração dos dados de sistemas anteriores Falta de domínio do negócio e das leis a serem utilizadas para definição do software. Um outro fator importante é a identificação dos compromissos assumidos durante a execução do Projeto Preliminar ou que por ventura tenham surgido nesta fase. Estes também deverão compor o documento Requisitos do Projeto e necessitam ser analisados conjuntamente com os requisitos do produto e restrições do projeto. Para cada compromisso identificado deverá ser designado um responsável por atender a este compromisso, pois normalmente a não execução de um compromisso implica em riscos

8 8 para o projeto, que deverão ser gerenciados. Uma lista foi elaborada para auxiliar no levantamento dos compromissos do projeto: Lista para Levantamento dos Compromissos Assumidos Necessidade de recursos humanos adicionais a serem disponibilizados tanto no cliente quanto na CELEPAR. Necessidade da ajuda de um especialista para que o produto seja entendido pelos técnicos da CELEPAR. Necessidade de aquisição de algum outro software (Banco de Dados, Gerenciador de rede, Linguagem de Programação,..) para que o projeto possa ser desenvolvido e/ou implantado. Necessidade da aquisição de equipamentos para que o projeto seja desenvolvido e/ou implantado. Necessidade de reorganização física do cliente (O&M) para que o projeto possa ser implantado. Necessidade de definições negociais pelo cliente. Necessidade de aprovação de lei para que o projeto seja desenvolvido e/ou implantado no cliente. Outras informações da fase: Responsável: Envolvidos: Produtos de Entrada: Produtos de Saída: Técnicas: Líder do Projeto Cliente Equipe Técnica Projeto Preliminar Legislação do cliente Documentação do cliente Lista de Requisitos do produto, restrições do projeto e compromissos assumidos Workshops estruturados Brainstorming ou sessões de resolução de problemas Entrevistas Processo de benchmarking JAD Observações e questionários Observações de um padrão de trabalho Observações do sistema organizacional e do ambiente político

9 9 Revisão de documentação, legislação técnica Análise de mercado Avaliação de sistemas concorrentes Engenharia reversa Simulação Prototipação... Check list da fase Cada requisito é uma declaração de necessidades, curta e definitiva? Existem condições apropriadas para que o requisito possa existir? Houve a identificação de restrições dos requisitos e do projeto? Os requisitos do produto, restrições do projeto e compromissos assumidos no Projeto Preliminar foram considerados? O requisito é testável? 5.2 FASE greq/ar Analisar Requisitos A Análise de Requisitos tem como objetivo identificar os requisitos que deverão ser contemplados no produto e a consistência entre eles. Para isto, é necessário que os requisitos sejam confrontados uns com os outros e em relação às restrições e aos compromissos assumidos. Muitas vezes, como resultado deste confronto, poderão ser identificadas contradições e impossibilidade de atendimento de algum requisito. Por exemplo, uma restrição de prazo muitas vezes pode ser oposição ao atendimento de algumas funcionalidades no software. É importante ressaltar que, quando algum requisito não puder ser atendido, o mesmo também deve estar descrito no documento Requisitos do Projeto com observações dos motivos que levaram ao não atendimento e os riscos associados a este fato (Veja um exemplo de requisitos no Anexo 6.2 Exemplos de Requisitos). Durante a análise deverá ser estabelecida uma relação entre os requisitos e as características de qualidade (NBR 13596), pois facilitará o planejamento das próximas fases do desenvolvimento do software. É importante ressaltar que toda esta análise é executada junto com o cliente.

10 10 Para cada requisito é necessário que o técnico de informática (analista) detalhe alguns aspectos: 1.Identificação Cada requisito deverá ser unicamente identificado com a primeira letra da característica de qualidade (NBR 13596) acrescido de um número sequencial. Este fator é importante para que seja possível o gerenciamento dos requisitos durante todo o processo de desenvolvimento do software. Segue abaixo a lista das características de qualidade. Funcionalidade Definição: Conjunto de atributos que evidenciam a existência de um conjunto de funções e suas propriedades especificadas. As funções são as que satisfazem as necessidades explícitas ou implícitas. Interpretação: Usabilidade Conjunto de funções definidas para o software e que atendem às necessidades do cliente (requisitos), diretrizes estabelecidas para o desenvolvimento de software na Celepar (normas e padrões) e requisitos legais. Definição: Conjunto de atributos que evidenciam o esforço necessário para se poder utilizar o software, bem como, o julgamento individual desse uso, por um conjunto explícito ou implícito de usuários. Interpretação: facilidade de uso do software; Confiabilidade Definição: Conjunto de atributos que evidenciam a capacidade do software de manter seu nível de desempenho sob condições estabelecidas durante um período de tempo estabelecido. Interpretação: Capacidade do software em manter sua integridade após a ocorrência de falhas não controladas. (Ex: Queda de luz)

11 11 Eficiência Definição: Conjunto de atributos que evidenciam o relacionamento entre o nível de desempenho do software e a quantidade de recursos usados, sob condições estabelecidas. Interpretação: uso de recursos pelo software; Quanto que o uso de recursos do software está contribuindo para a melhoria do desempenho deste Portabilidade Definição: Conjunto de atributos que evidenciam a capacidade do software de ser transferido de um ambiente para outro. Interpretação: Capacidade do software de ser transferido para ambientes e/ou plataformas conhecidas ou dentro de padrões internacionais estabelecidos Manutenibilidade Definição: Conjunto de atributos que evidenciam o esforço necessário para fazer modificações especificadas no software. Interpretação: O esforço necessário para se fazer modificações especificadas no software 2.Descrição do Requisito descrição do requisito através de uma sentença. 3.Prioridade O cliente deverá identificar as prioridades de atendimento dos requisitos. A escala de importância a se utilizar é: P Pouca importância ME Média para baixa importância MU Muita importância E Essencial importância Para se estabelecer esta escala é necessário analisar os seguintes pontos: necessidade de que o software contenha este requisito (visão do cliente e do analista);

12 12 se o requisito é viável do ponto de vista de disponibilização de tecnologia, de capacitação de recursos humanos, custos associados, etc.; riscos aos quais o projeto está exposto tanto em relação a perdas financeiras, impacto no ambiente, segurança, conformidade com leis e normas, etc. quanto em relação à não contemplação de um requisito pelo projeto. 4.Fonte Indica quem identificou o requisito (cliente ou técnico ou analista). Esta informação é necessária quando da alteração ou exclusão de algum requisito durante o processo ou no caso de se ter dúvidas em relação ao atendimento dos requisitos. 5.Característica de qualidade Característica de qualidade da NBR ao qual o requisito está associado. 6.Requisito alocado ao projeto Se o requisito será implementado no projeto ou não (S/N). 7.Observação Explicação dos riscos e restrições associados ao requisito, dos motivos de não alocação do requisito, ou outra informação que se faz necessária. Consolidar a documentação da Especificação de Requisitos de acordo com o modelo presente no material de apoio da fase de análise. Responsável: Líder do Projeto Envolvidos: Cliente Produtos de Entrada: Lista de Requisitos, restrições e compromissos Produtos de Saída: Requisitos do Projeto aprovado Técnicas: Análise de Riscos

13 13 6 ANEXOS 6.1 Lista para Levantamento de Requisitos Internos e Externos A lista a seguir contém algumas atividades a serem executadas quanto o item for importante para o projeto em questão. Ela foi elaborada com o intuito de facilitar o levantamento dos requisitos junto ao cliente. Ela está ordenada pelas características e subcaracterísticas, de qualidade proposta pela norma NBR 13596, e possui algumas atividades aplicadas ao levantamento de requisitos. A lista não pretende ser exaustiva, portanto poderão aparecer questões que não estão listadas abaixo.

14 14 Característica: FUNCIONALIDADE Como o software será útil? Sub característica Atividade Check list Adequação Conjunto de funções que compõem o software (solução) e devem atender às demandas estabelecidas (cliente e CELEPAR) Identificar os principais produtos que o cliente considera necessários e que devem ser gerados pelo sistema Propõe se a fazer o que é apropriado? Verificar e prioritizar a identificação das funções que tenham informações que são divulgadas externamente, pois estas têm um grande impacto para o cliente. dentificar os patrocinadores, clientes e usuários do sistema Identificar e esclarecer os papéis dos usuários e clientes. Verificar quais funções os clientes desempenham. Acurácia Atributos do software que evidenciam a geração de resultados ou efeitos corretos ou conforme acordados. Identificar a necessidade de tratamento diferenciado de funções que necessitam ter resultados mais apurados(quais funções críticas em termos de resultados gerados) Verificar as seguintes informações : Impactos externos; Funções críticas com prejuízo político, legal, econômico, etc.. Complexidade? Interoperabilidade Facilidade do software em interagir com outros através do estabelecimento de padrões facilitadores Identificar as aplicações com as quais o software necessita se comunicar (possuir interface) Identificar quais são as informações necessárias para que a comunicação entre as aplicações ocorra Interage com os sistemas especificados? Verificar a confiabilidade das informações a serem disponibilizadas em relação ao prazo, completeza e se está correta.

15 15 Segurança de Acesso Atributos de software que evidenciam sua capacidade de evitar o acesso não autorizado, acidental ou deliberado a programas e dados. Identificar como será a sistemática de segurança de acesso requerido às funções do software. Identificar rotinas que necessitem de segurança de dados quando da impressão do mesmo. Exemplo: controle de notas fiscais, impressão de contra cheques, impressão de resultados de concursos,... Identificar que dados são passíveis de fraudes e qual o risco que isto ocorra. Identificar a necessidade de criptografia dos dados. Identificar a necessidade de auditoria de segurança Conformidade Aderência do software com as normas da CELEPAR em relação ao desenvolvimento e com as normas e leis do governo/cliente em relação ao negócio. Identificar as leis, normas, padrões, e regimentos internos que o sistema deverá seguir. Identificar questões de prazos a serem cumpridos pelo sistema para o atendimento a leis e normas impostas Está de acordo com as normas, leis, etc.? Verificar se os processos existentes atualmente dentro do cliente estão em conformidade com as leis e normas vigentes. Quando isto não ocorrer, registrar como risco do projeto. Verificar se o cliente domina o entendimento das leis e das normas a serem utilizadas no projeto. Quando isto ocorrer registrar como risco do projeto. Verificar a perspectiva de alteração das leis e normas do cliente durante o desenvolvimento do software. Quando isto ocorrer, registrar como risco do projeto.

16 16 Característica: CONFIABILIDADE Funciona bem em caso de falhas? Sub característica Atividade Check list Maturidade Atributos do software que evidenciam a freqüência de falhas por defeitos no sofware. Tolerância a Falhas Evidência a capacidade de recuperar o estado de operação normal anterior à falha. Ex. No caso de queda de energia proporcionar um restart automático e/ou recuperar os dados através de log. Identificar qual o período crítico que o sistema deverá estar disponível. Identificar a necessidade do sistema possuir distribuição de dados Identificar a necessidade de tratamento especial de rotinas de segurança Ocorrendo falhas, como ele reage? Recuperabilidade Capacidade de recuperação dos dados que sofreram danos na hora da falha e o tempo e esforço para tal. Identificar a necessidade de instrumentos especiais de recuperação de dados. Este fato está relacionado ao nível de criticidade das informações. Qual é o esforço necessário para se recuperar de falhas? Característica: USUABILIDADE Como facilitar o uso? Sub característica Atividade Check list Inteligibilidade Facilidade no entendimento do software. Apreensibilidade Facilidade no aprendizado do software. Operacionalidade Atributos do software que evidenciam o esforço do usuário para sua operação e controle da sua operação. Identificar a necessidade da aplicação possuir interface gráfica (ambiente gráfico, internet, mapas, geoprocessamento, etc.) Identificar a necessidade de disponibilizar assistente, manuais, tutorial,... Identificar se existe necessidade de treinar o usuário É fácil entender o conceito e a aplicação? Como facilitar o aprendizado?

17 17 Característica: EFICIÊNCIA É eficiente? Sub característica Atividade Check list Comportamento em relação ao tempo Tempo de resposta das funções do software. Identificar as necessidade do sistema requerer tempo de resposta crítica O desempenho é adequado às necessidades? Comportamento em relação aos recursos Recursos usados na execução das funções do software. Identificar os recursos disponíveis em relação aos recursos humanos, por exemplo: necessidade de operadores para o sistema, necessidade de recursos humanos treinados em novas tecnologias para o desenvolvimento do software, etc. Não desperdiça recursos computacionais?

18 18 Característica: MANUTENIBILIDADE É fácil de modificar? Sub característica Atividade Check list Analisabilidade Facilidade de entender no software o que deve ser modificado. Modificabilidade Atributos do software que evidenciam o esforço necessário para modificá lo, remover seus defeitos ou adaptá lo a mudanças ambientais. Estabilidade Atributos do sofware que evidenciam o risco de efeitos inesperados ocasionados por modificações. Testabilidade Atributos do sofware que evidenciam o esforço necessário para validar o software modificado. A extensão em que um teste objetivo e factível pode ser projetado para determinar se um requisito é atendido. Identificar se a legislação que é utilizada para desenvolver o sistema é instável e possui muitas mudanças. Identificar se existem muitos clientes e se eles possuem divergências de opiniões quanto ao que o software necessita atender (Levantamento para análise de risco). Identificar se os procedimentos do cliente que o sistema deverá atender são estáveis ou instáveis (Levantamento para análise de risco). Identificar se sistemas similares tiveram grandes manutenções. Identificar se o ciclo de vida do software será curto ou longo. Identificar se a demanda é complexa (Levantamento para análise de risco). Identificar a necessidade de evolução tecnológica constante e rápida no sistema É fácil de entender?

19 19 Adaptabilidade Capacidade de adaptação do software a ambientes diferentes especificados, sem a necessidade de aplicação de outras ações ou meios além daqueles fornecidos para essa finalidade pelo software. Identificar para qual ambiente o software deverá ser projetado Identificar se o software necessita ser projetado para múltiplas plataformas. Adapta se facilmente a outros ambientes? Capacidade para ser instalado Atributos do software que evidenciam o esforço necessário para sua instalação num ambiente especificado. Capacidade para substituir Facilidade do software substituir um outro software Identificar se o sistema deverá substituir um outro vigente É fácil este software substituir outro? Conformidade Atendimento aos padrões da CELEPAR e a plataforma de hardware que foi convencionada para o software Está de acordo com padrões de sistemas abertos? Característica: PORTABILIDADE Adapta se facilmente a ambientes diferentes? Sub característica Atividade Check list Adaptabilidade Capacidade de adaptação do software a ambientes diferentes especificados, sem a necessidade de aplicação de outras ações ou meios além daqueles fornecidos para essa finalidade pelo software. Capacidade para ser instalado Atributos do software que evidenciam o esforço necessário para sua instalação num ambiente especificado. Capacidade para substituir Facilidade do software substituir um outro software. Conformidade Atendimento aos padrões da CELEPAR e a plataforma de hardware que foi convencionada para o software Identificar para qual ambiente o software deverá ser projetado Identificar se o software necessita ser projetado para múltiplas plataformas. Identificar se o sistema deverá substituir um outro vigente Adapta se facilmente a outros ambientes? É fácil este software substituir outro? Está de acordo com padrões de sistemas abertos?

20 Exemplos de Requisitos Este é um exemplo de como identificar uma restrição a partir de um requisito inicial do cliente. O requisito é necessidade do software ser customizável pelo usuário. Informações adicionais do cliente incluem: a customização deverá ser feita pelo próprio usuário e deverão ser obedecidos os direitos de acesso às funções para ele autorizadas. Estas condições e restrições devem ser identificadas durante a fase de análise de requisitos e comporão a especificação de requisitos: Característica de Qualidade: Usabilidade Id. Descrição do Requisito Prioridade Fonte Alocado(S/N) U01 O software deverá possibilitar a customização das funções Essencial pelo próprio cliente Cliente Sim Y Observação: foi identificado como restrição do requisito que somente poderão ser customizadas as funções às quais o usuário tem acesso autorizado. A prioridade de atendimento assinalada como Essencial é devido à constatação pelo cliente de um número elevado de usuários que executam somente algumas funções do sistema. Estes usuários utilizam sistemas que já trabalham com esta filosofia, portanto já é padrão a existência desta facilidade. A identificação e análise deste requisito, por outro lado, terá como conseqüência a identificação de um outro requisito que é: Característica de Qualidade: Funcionalidade Id. Descrição do Requisito Prioridade Fonte Alocado(S/N) F02 Necessidade de disponibilização de uma função genérica para customização do software pelo próprio usuário. Essencial Analist a X Observação: requisito identificado a partir de um outro requisito ligado à usabilidade: O software deverá possibilitar a customização das funções pelo próprio cliente. Sim

21 GERENCIAMENTO DE REQUISITOS A gerência de requisitos tem como objetivo identificar e registrar alterações das necessidades que o produto de software terá que atender (requisitos do produto), além de orientar a avaliação de impactos destas mudanças nos planos do projeto. O processo de gerenciamento de requisitos nasceu da constatação que as mudanças normalmente ocorrem durante o processo de desenvolvimento de produtos. Estas mudanças são geradas por alterações de legislação, de objetivos de negócio, ou mesmo de um melhor entendimento das potencialidades oferecidas pelos sistemas de informações. Na maioria das vezes, tais mudanças implicam em renegociação de prazo, custo e de esforço para o projeto. Quando isto ocorrer é essencial que fique explicitado e que existam mecanismos de renegociação com o cliente e com a equipe técnica do projeto em relação aos compromissos de cada envolvido e aos objetivos e requisitos a serem atendidos pelo produto. O processo de gerenciamento de requisitos é composto pelas seguintes tarefas: Identificar Mudanças de Requisitos A identificação da mudança de requisitos inicia se com uma percepção de uma alteração de mercado, de legislação (imposição), de alterações de fundos para o projeto (recursos financeiros ou de pessoal tanto interno da Celepar como do cliente), de disponibilização ou mudança de tecnologia, de algum outro ato ou necessidade percebida ou como consequência de mudanças na equipe técnica do cliente e da CELEPAR Avaliar Impactos Para cada mudança identificada é necessário que se estabeleça e identifique quais são os requisitos que foram afetados dentro do projeto e que deverão ser renegociados, pois muitas vezes a simples mudança em um requisito tem como consequência alterações em outros requisitos.