FATTO

Subconjunto dos requisitos do usuário especificando o que o software deverá fazer em termos de tarefas e serviços.

NOTA

Os Requisitos Funcionais do Usuário incluem, mas não estão limitados a:
— transferência de dados (por exemplo: Receber dados de entrada de cliente, Enviar sinal de controle);
— transformação de dados (por exemplo: Calcular juros bancários, Derivar temperatura média);
— armazenamento de dados (por exemplo: Armazenar pedido de cliente, Registrar temperatura ambiente ao longo do tempo);
— recuperação de dados (por exemplo: Listar empregados atuais, Recuperar posição de aeronave).

Requisitos do usuário que não constituem Requisitos Funcionais do Usuário incluem, mas não estão limitados aos seguintes:
— restrições de qualidade (por exemplo: usabilidade, confiabilidade, eficiência e portabilidade);
— restrições organizacionais (por exemplo: locais para operação, hardware-alvo e conformidade com os padrões);
— restrições ambientais (por exemplo: interoperabilidade, segurança e privacidade);
— restrições de implementação (por exemplo: linguagem de desenvolvimento, prazo para entrega).

[ISO/IEC 14143-1:2007, definition 3.8]

A modificação de um produto de software, executada depois da entrega,  para manter o produto de software utilizável em um ambiente alterado ou em vias de alteração. Manutenção adaptativa fornece as melhorias necessárias para acomodar mudanças no ambiente no qual um produto de software deve operar. Estas mudanças são as que devem ser feitas para manter-se em dia com o ambiente alterado. Por exemplo, o sistema operacional deve sofrer upgrade e algumas mudanças devem ser feitas para acomodar o novo sistema operacional.

A medição do tamanho funcional para manutenção é aplicável a um subconjunto de manutenções adaptativas. Isso inclui as funcionalidades do software adicionadas, alteradas ou excluídas bem como as funcionalidades do software fornecidas para converter dados e atender outros requisitos de conversão (ex.: relatórios de conversão).

Um projeto de melhoria é um projeto para desenvolver e entregar manutenção adaptativa.

Um conjunto coeso de procedimentos automatizados e dados suportando um objetivo de negócio. Consiste de um ou mais componentes, módulos ou subsistemas. Frequentemente usado como sinônimo para Sistema, Sistema de Informação ou Sistema Aplicativo.

Exemplos: contas a pagar, contas a receber, folha de pagamento, compras, produção de loja, controle de linha de montagem, radar de busca aérea, acompanhamento de alvo, acionamento de armas, programação de aeronaves e reservas de passagens.

É a interface conceitual que delimita o software que será medido e o usuário. A fronteira:

• Define o que é externo à aplicação
• Indica a fronteira entre o software que está sendo medido e o usuário
• Atua como uma ‘membrana’ através da qual os dados processados pelas transações (EEs, SEs e CEs) passam para dentro e para fora da aplicação
• Envolve os dados lógicos mantidos pela aplicação (ALIs)
• Auxilia na identificação dos dados lógicos referenciados mas não mantidos pela aplicação (AIEs)
• Depende da visão externa do negócio do usuário da aplicação. É independente de considerações de técnicas e/ou implementação

As seguintes regras devem ser válidas:

• A fronteira é determinada com base na visão do usuário. O foco está no que ele pode entender e descrever;
• A fronteira entre aplicações afins é baseada em diferentes áreas funcionais como visto pelo usuário, não em considerações técnicas;
• A fronteira inicial já estabelecida para a aplicação ou aplicações sendo modificadas não é influenciada pelo escopo da contagem.

Nota: Pode haver mais de uma aplicação incluída no escopo da contagem. Nesse caso, múltiplas fronteiras da aplicação deverão ser identificadas. Quando a fronteira não está bem definida (como no início da análise), ela deverá ser posicionada da forma mais exata possível.

Dicas para identificação da fronteira:

• Utilize as especificações externas do sistema ou obtenha um fluxo do mesmo e desenhe a respectiva fronteira, destacando as partes internas e as externas à aplicação.
• Verifique como os grupos de dados estão sendo mantidos.
• Identifique as áreas funcionais, alocando certos tipos de objetos da análise (tais como entidades ou processos elementares) a uma área funcional.
• Observe dados de medição correlatos, tais como esforço, custo e defeitos. As fronteiras consideradas para os pontos de função e para os outros dados de medição devem ser as mesmas
• Entrevistar os especialistas no assunto para auxiliar na identificação da fronteira.

Um artefato que ilustra bem o conceito de fronteira é o diagrama de contexto.

É um tipo de entidade que contém atributos que completam a descrição de um relacionamento de muitos-para-muitos entre duas outras entidades. É usada para associar duas ou mais entidades como uma forma de definir o relacionamento de muitos-para-muitos. Entidades deste tipo são geralmente criadas por quem modela os dados para resolver algumas das regras de negócio necessárias à associação entre duas entidades distintas.

É um tipo de entidade que descreve complementarmente uma ou mais características de uma outra entidade. Por definição, é uma extensão lógica de uma outra entidade. Normalmente os dados em entidades deste tipo são contados como um tipo de registro da entidade que descreve.

Representam dados centrais para o negócio da aplicação. Representam um percentual significativo das entidades identificadas. Possuem muitos atributos e são dados dinâmicos (regularmente lidos e mantidos). Devem ser contados como ALIs ou AIEs.

Também chamados de core user data ou objetos de negócio.

Características lógicas incluem:
• Obrigatório para a operação da área funcional do usuário
• Identificável pelo usuário (normalmente por um usuário do negócio)
• Mantido pelo usuário (normalmente por um usuário do negócio)
• Armazena Dados Centrais do Usuário para auxiliar as transações do negócio
• Muito dinâmico – operações normais do negócio fazem com que eles sejam regularmente referenciados, incluídos, alterados e excluídos rotineiramente.
• Reportável

Características físicas incluem:
• Têm campos chave e normalmente muitos atributos
• Podem ter de zero a infinitos registros

São dados que surgem em resposta a requisitos técnicos como: normalização de dados, garantia da integridade de dados ou melhoria na entrada de dados. Em geral são dados essencialmente estáticos que possuem poucos atributos, tipicamente código e descrição. Estes dados não contribuem para o tamanho funcional do software, nem as transações que os manipulam.

Também chamados de dados de lista ou dados de tradução. O usuário nem sempre os especifica diretamente. Em outros casos, são identificados pelo desenvolvedor em resposta a um ou mais requisitos técnicos do usuário. Provêem uma lista de valores válidos que um atributo descritivo pode assumir. Tipicamente seus atributos são código, descrição e/ou outros atributos "padrão" descrevendo o código; por exemplo, abreviação padrão, datas de início e término de vigência, dados de auditoria, ativo/inativo, etc.

A diferença chave entre Dados de Código e Dados de Referência é:
• Com Dados de Código, você pode substituir um pelo outro sem alteração do significado dos Dados do Negócio. Ex.: Código do Aeroporto X Nome do Aeroporto, Código da Cor X Descrição da Cor.
• Com Dados de Referência você não pode substituir (Ex.: Código do Imposto com a Alíquota do Imposto)

Características lógicas incluem:
• Dados são obrigatórios para a área funcional, mas armazenado opcionalmente como um arquivo de dados
• Geralmente não identificado como parte dos requisitos funcionais; ele é normalmente identificado como parte do projeto para satisfazer requisitos técnicos
• Às vezes mantidos pelo usuário (normalmente por um usuário do suporte)
• Armazena dados para padronizar e facilitar atividades do negócio e transações do negócio
• Essencialmente estático – apenas alterado em resposta a mudanças na maneira que o negócio é operado
• Transações do negócio acessam Dados de Código para melhorar casos de entradas de dados, melhorar a consistência de dados, garantir integridade de dados, etc.

Quando reconhecido pelo usuário:
• As vezes é considerado como um grupo do mesmo conjunto de dados
• Pode ser mantido utilizando a mesma lógica de processamento

Características físicas incluem:
• Possui campos chave e normalmente um ou dois atributos apenas
• Tipicamente tem um número estável de registros
• As vezes desnormalizado e armazenado em uma tabela física com outros Dados de Código
• Pode ser implementado de diferentes formas (ex.: em uma aplicação separada, dicionário de dados ou diretamente no código fonte do software)

Exemplos:
• Dados estáticos
• Dados de substituição (código + descrição)
• Dados de domínio de valores

IEEE: (1) Ler dados de uma fonte, mantendo os dados da fonte intactos e gravar os mesmos dados em outro local em forma física que pode diferir daquela da fonte. Por exemplo,  copiar dados de um disco magnético para uma fita magnética. (2) O resultado de um processo de cópia como acima exposto. Por exemplo, uma cópia de um arquivo de dados.