Requisitos - VIII

Elementos Básicos

Os elementos básicos de formação do processo apresentado são os utilizados pelo RUP, para descrever seus aspectos estáticos, como:

• Papéis
• Artefatos
• Atividades
• Fluxo de atividades

Os três fluxos de atividades de engenharia de requisitos são:

• Definir o Escopo do Sistema
• Refinar Requisitos de software
• Gerenciar Mudanças

Papéis

O comportamento é descrito por meio das atividades associadas àquele papel e as responsabilidades são definidas com relação aos artefatos criados, modificados ou controlados por ele.

• Equipe: toda a equipe de desenvolvimento.
• Analista de Sistemas – o principal responsável pela engenharia de requisitos:
• Elicitação
• Análise
• Especificação
• Validação
• Gerência de requisitos.
• Gerente de Projetos – responsável pelo bom andamento do projeto, monitoração de riscos, alocação de recursos e demais atividades de planejamento.
• Cliente: representa um stakeholders do sistema, pertencente à organização cliente e que possui autorização para atuar como fornecedor de requisitos ao projeto.
• Comitê de Controle de Mudanças: é formado por representantes de todos os stakeholders.
• Uma configuração típica seria – o gerente de projeto, o gerente do projeto na organização cliente, um analista e um líder técnico.
• Em projeto pequenos, pode ser formado apenas pelo gerente de projeto.
• Qualquer Papel: qualquer membro da equipe de desenvolvimento ou stakeholders da organização cliente.

Artefatos

Os artefatos produzidos durante a execução das atividades do projeto são:

• Documentos de Entrada: quaisquer documentos relacionados ao projeto que foram produzidos antes da fase de Iniciação. Exemplo típicos de documentos de entrada são RFPs (Request for Proposals) enviados por um cliente, a Proposta Comercial feita pelo departamento de vendas e aceita pelo cliente e a Proposta Técnica, que sugere uma visão inicial das características e módulos do sistema.

• Atributos de Requisitos: são dados recolhidos ao longo do processo de análise de requisitos, desde a especificação até a aprovação da especificação final ou de posteriores mudanças.
• Há vário tipos de atributos de requisitos: identificadores e informações cadastrais, especificações e detalhamento, status e índices como importância para o negócio, relevância para arquitetura, estimativa de tamanho (ou complexidade).
• Um atributo especial é a prioridade do requisito, definida com base nos índices de outros atributos, e cuja definição depende de negociações com o cliente que envolvem atividades de gerência de projeto.

• Matrizes de Rastreabilidade: documentam as relações de dependência entre requisitos. A rastreabilidade documentada é vertical (obrigatória) e horizontal (opcional).
• É possível documentar as matrizes de rastreabilidade explicitamente, através de tabelas, planilhas ou ferramentas de gerência de requisitos, ou implicitamente, através dos demais artefatos do projeto.
• Um exemplo de documentação implícita é a matriz que relaciona requisitos aos recursos de projeto como tempo e pessoas.
• Os cronogramas do projeto possuem atividades agrupadas em blocos com os mesmos nomes dos requisitos, o que resulta em uma relação implícita com os requisitos armazenados no repositório.

• Glossário: registro do vocabulário comum do projeto, na linguagem do cliente. É criado no início do projeto e evolui ao longo do desenvolvimento do sistema, servindo como referência para todos os envolvidos.

• Documento de visão: nesse documento é definida a visão que os envolvidos têm do produto a ser entregue, em termos das principais necessidades e características.
• Também registra a motivação para o desenvolvimento do sistema, através da breve descrição do principal problema de negócio a ser resolvido pelo sistema, além de descrever os limites do produto e as restrições impostas à solução.
• Por conter um descrição em alto nível dos requisitos centrais pretendidos, incluindo restrições de design, serve como base contratual para requisitos técnicos mais detalhados.

• Especificação de Requisitos de Software (ERS): captura todos os requisitos de software do sistema e consiste em um pacote contendo especificações funcionais e não funcionais aplicáveis.
• As especificações funcionais possuem dois níveis de detalhamento: uma visão geral da funcionalidade é descrita nesse documento e o detalhamentos minucioso de cada requisitos é anotado em um documento chamado Especificação Funcional de Requisitos.

• Especificação Funcional de Requisitos: os requisitos mais genéricos, alguns requisitos não funcionais e os requisitos que não podem ser bem representados nas especificações funcionais também são registrados na ERS, na seção de Especificação Suplementares.
• Esse documento descreve minuciosamente a interação que ocorre entre os atores (usuários ou sistemas externos) e o sistema durante a execução deste(s) requisitos(s).
• O principal objetivo é especificar o funcionamento de um porção do sistema de forma clara o suficiente para que o cliente possa validar o que será desenvolvido e a equipe de desenvolvimento compreenda o que deve entregar.

• Modelo de Domínio: modelo de objetos inicial do sistema ou outra representação das entidades essenciais do sistema.

• Protótipo de Interface: descrição de uma ou mais interface com o usuário.
• Pode ser criada em vários formatos, tais como protótipos funcionais do sistema, protótipos estáticos, exemplos de tela, desenhos à mão livre capturados em meios eletrônicos e etc.

• Solicitação de Mudanças: utilizada sempre que uma mudança no projeto é requisitada.
• Esse artefato pode ser criado por qualquer membro da equipe de desenvolvimento ou da equipe do cliente, e deve ser aprovado pelo Comitê de Controle de Mudanças.

• A Solicitação do Mudança é utilizada para documentar a necessidade de mudança (defeito, melhoria ou novos requisitos), informações sobre impacto e consequências de sua adoção e status de mudança, além das justificativas para as decisões tomadas sobre a implementação da mudança.

• Repositório do Projeto: contém todos os artefatos utilizados no processo de desenvolvimento do software.
• Pode ser um conjunto de arquivos, um banco de dados ou qualquer outra base controlada, por exemplo, por uma ferramenta de gerência de requisitos.

• Aprovações: comunicação oficiais enviadas pelo cliente, atestando aceitação de algum artefato produzido.
• Geralmente são e-mails com a aprovação de Especificações Funcionais de Requisitos.

Grande Abraço,

Gilberto Ribeiro.