Desenvolver um plano de gerenciamento de requisitos, definir linhas de base dos requisitos, obter compreensão e comprometimento com os requisitos, gerenciar mudanças nos requisitos, manter o rastreamento bidirecional dos requisitos e identificar inconsistências entre o trabalho do projeto e os requisitos

Rastreamento bidirecional de requisitos: No rastreamento direto, em que caso de uso o requisito original é realizado, se todos os requisitos originais são atendidos. No rastreamento reverso, se um caso de uso não realiza nenhum requisito original, é uma necessidade interessante.

Informações relacionadas ao domínio do problema, informações relacionadas ao problema a ser resolvido, expectativas e restrições do usuário

Partes interessadas, sistemas legados, concorrentes, especialistas no domínio

Reunião de requisitos de discussão conjunta (discussão multipartidária), entrevistas com usuários (usuários-chave preparam perguntas), pesquisas escritas (quando há muitas pessoas), observações no local, leitura de documentos históricos e participação em práticas de negócios

Ferramentas gráficas: diagrama de blocos hierárquico, diagrama de casos de uso, diagrama IPO, diagrama Warnier

O desenvolvimento de requisitos é um processo evolutivo iterativo e não em cascata que decompõe o problema de cima para baixo, camada por camada, e fornece uma visão lógica e uma visão física do sistema.

Desenhar um diagrama de escopo do relacionamento entre o sistema e entidades externas, criar um protótipo de interface de usuário, analisar a viabilidade dos requisitos, determinar a prioridade dos requisitos, estabelecer um modelo de análise de requisitos (modelo de caso de uso, diagrama ER, diagrama de fluxo de dados) , crie um dicionário de dados e use funções de qualidade alocadas

métodos de análise estruturada

Método de análise orientada a objetos

Método de análise de domínio de problema de área

Visão lógica (atendendo aos requisitos funcionais), visão de processo (problemas de simultaneidade), visão de componente (problemas de implementação), visão de implantação (problemas de distribuição)

Converter requisitos de software em estruturas de dados e estruturas de sistema de software, completando principalmente o design geral, incluindo a divisão de funções em módulos, a determinação de funções de módulo e as relações de chamada e composição entre módulos

De cima para baixo, refinamento gradual, ocultação de informações (interface de operação), módulos independentes (alta coesão, baixo acoplamento)

Projete estrutura de dados e algoritmo para cada módulo, desempenho, tempo de resposta, tempo de resposta, rendimento, precisão, etc.

Módulo de entrada, módulo de saída, módulo de transformação, módulo de coordenação

Transformação, Transação, Mista

Projetar casos de teste de acordo com as especificações funcionais e verificar se as funções atendem aos requisitos, independente da estrutura e processamento do programa.

Divisão de classe de equivalência

análise de valor limite

erro de adivinhação

diagrama de causa e efeito

Conteúdo de teste

Métodos de teste

Combine testes de caixa preta e caixa branca

Conduzido durante a fase de codificação, testes gerais de caixa branca, como testes de função de interface de módulo, testes de estrutura de dados local, testes de caminho, testes de tratamento de erros e testes de condições de limite

Erros na fase de projeto são descobertos. Depois que os módulos são montados, a interface e a comunicação entre os módulos são testadas, geralmente testes de caixa preta.

Verifique se as funções e o desempenho do software estão consistentes com as necessidades do usuário, com base nas especificações de demanda, testes de validade, revisão de configuração de software e testes de aceitação (relatório de análise, manual do usuário, relatório de resumo de desenvolvimento) em um ambiente simulado

Testes de ambiente de produção, testes de caixa preta baseados em especificações de requisitos, cobrindo todos os componentes conjuntos e avaliando a qualidade dos produtos de software

Incluindo software, hardware, periféricos, dados, software de suporte, etc., especificamente testes de recuperação, testes de segurança, testes de resistência, testes de desempenho, testes de confiabilidade e testes de instalação

Para software do tipo produto, o desenvolvedor @ está presente e o cliente implementa o teste, e o desenvolvedor b não está presente.

Finalidade (avaliar capacidades do sistema, identificar pontos fracos, ajustar o sistema, verificar estabilidade e confiabilidade), tipo (teste de carga, teste de força, teste de capacidade)

Análise de requisitos de software, preparação do plano de teste de aceitação e critérios de aceitação do projeto, design de teste e design de caso de teste, construção de ambiente de teste, implementação de teste, análise de resultados, relatório de teste

Intermediário - Centro de Avaliação de Software de Pequim

Análise de requisitos - Possíveis melhorias e modificações são explicadas

Fase de design – solução fácil de expandir, portátil, reutilizável, orientada a objetos

Fase de codificação - anotação, qualidade, orientada a objetos

Fase de teste - se o teste for bom, então a manutenção é boa; todos os documentos relacionados ao teste estão disponíveis;

Fase de manutenção – boa gestão de configuração e documentos sincronizados

Número de loops (complexidade do código-fonte), tamanho do software, outros fatores