Habilidades profissionais de design de arquitetura de sistema · Engenharia de requisitos de engenharia de software

Índice de artigos da série

Habilidades avançadas em design de arquitetura de sistema · Conceitos de arquitetura de software, estilos de arquitetura, ABSD, reutilização de arquitetura, DSSA (1) [Arquiteto de Sistema]
Habilidades avançadas em design de arquitetura de sistema · Atributos de qualidade de sistema e avaliação de arquitetura (2) [Arquiteto de Sistema]
Habilidades avançadas em projeto de arquitetura de sistema · Análise e projeto de confiabilidade de software (3) [Designer de arquitetura de sistema]

1. Visão geral da engenharia de requisitos

Os requisitos de software referem-se às expectativas dos usuários em relação ao sistema em termos de funções, comportamento, desempenho, restrições de design, etc.

Engenharia de Requisitos (ER) refere-se à aplicação de princípios e métodos comprovados e eficazes para descrever sistematicamente o sistema a ser desenvolvido, suas características comportamentais e restrições relacionadas por meio de ferramentas e notações apropriadas.

A engenharia de requisitos consiste em cinco etapas: aquisição de demanda, análise de demanda, formação de especificação de demanda (ou documentação de demanda), confirmação e verificação de demanda e gerenciamento de demanda, conforme mostrado na figura:

Especificação de Requisitos de Software (SRS)
SRS inclui especificamente requisitos funcionais , requisitos não funcionais e restrições . As restrições incluem restrições de projeto e restrições de processo. Um SRS aprovado éa ponte entre o desenvolvimento e o gerenciamento de requisitos .

Gerenciamento de Requisitos
O gerenciamento de requisitos é um processo de alteração, compreensão e controle de requisitos do sistema, incluindo controle de alterações, controle de versão, rastreamento de requisitos e outras atividades.

2. Desenvolvimento da demanda (linha principal, meta)

2.1 Classificação de requisitos

• Classificação de requisitos

(1) Necessidades de negócios : As necessidades de negócios refletem os requisitos-alvo de alto nível da empresa ou do cliente para o sistema. Geralmente vêm de investidores de projetos, clientes que compram produtos, gerentes de unidades de clientes, departamentos de marketing ou departamentos de planejamento de produtos, etc. Os requisitos de negócios determinam a visão e o escopo do projeto.

(2) Requisitos do usuário : Os requisitos do usuário descrevem os objetivos específicos do usuário ou as tarefas que o usuário exige que o sistema conclua. Ou seja, os requisitos do usuário descrevem o que os usuários podem fazer com o sistema. Entrevistas e questionários com usuários geralmente são usados ​​para organizar cenários de uso do usuário (cenários) para estabelecer as necessidades do usuário.

(3) Requisitos do sistema : Os requisitos do sistema descrevem os requisitos de software de uma perspectiva do sistema, incluindo requisitos funcionais, requisitos não funcionais e restrições de design.

• QFD de Implantação da Função de Qualidade

É uma tecnologia que converte requisitos do usuário em requisitos de software, com o objetivo de maximizar a satisfação do usuário durante o processo de engenharia de software. Para atingir este objetivo, o QFD divide os requisitos de software em três categorias, nomeadamente requisitos regulares, requisitos esperados e requisitos inesperados.

(1) Necessidades básicas : também chamadas de necessidades regulares, as funções ou desempenho que os usuários acham que o sistema deve alcançar. Quanto mais funções ou desempenho forem implementados, mais satisfeitos os usuários ficarão.

(2) Requisitos esperados : Os usuários tomam como certas as funções ou o desempenho que o sistema deveria ter, mas não conseguem descrever corretamente as funções ou os requisitos de desempenho que desejam. Se as expectativas não forem atendidas, os usuários ficarão insatisfeitos.

(3) Requisitos inesperados : Requisitos inesperados, também conhecidos como requisitos interessantes, são funções ou desempenho fora do escopo dos requisitos do usuário (mas geralmente recursos técnicos que os desenvolvedores de software ficam felizes em fornecer ao sistema). Os usuários ficarão mais felizes se esses requisitos forem atendidos. realizados, mas não o são, nem afecta as suas decisões de compra.

2.2 Aquisição de requisitos

método	Características
juntar informação	Colete informações relacionadas ao sistema que sejam úteis para o desenvolvimento do sistema.
Leia documentos históricos	Útil para coletar informações baseadas em dados.
Entrevistas com usuários	1 a 1-3, usuários representativos, compreensão de pensamentos subjetivos, boa interação. O custo é alto e requer suporte de conhecimento de domínio.
Questionário	São muitos usuários , é impossível realizar uma entrevista e o custo é baixo .
Observação no local	Para processos e operações mais complexas.
Participe da prática empresarial	Descubra efetivamente a natureza dos problemas e encontre soluções para eles.
Planejamento de Requisitos Conjuntos (JRP)	Reuniões em grupo altamente organizadas, envolvendo todas as partes, entendendo ideias, eliminando diferenças, boa interação e alto custo.
Storyboard ( método de prototipagem)	Uma série de imagens através das quais uma história é contada.
Pesquisa/amostragem por amostragem	Com base em estatísticas matemáticas, reduza custos e obtenha rapidamente. Tamanho da amostra = a*(coeficiente de credibilidade/erro aceitável)2 Nota: a é geralmente 0,25

• Entrevistas com usuários
  As entrevistas com usuários são o meio mais básico de obtenção de requisitos e seus formulários incluem estruturados e não estruturados . Estruturado significa preparar antecipadamente uma série de perguntas e conduzi-las de forma direcionada; não estruturado significa apenas elencar uma ideia aproximada e desenvolvê-la de acordo com a situação específica da entrevista . As entrevistas mais eficazes são realizadas combinando estes dois métodos, afinal é impossível planear tudo com clareza e deve ser mantida uma boa flexibilidade.
  As entrevistas com usuários têm boa flexibilidade e uma ampla gama de aplicações . No entanto, também existem muitas dificuldades. Por exemplo, os usuários estão frequentemente ocupados e têm dificuldade em organizar o tempo; a quantidade de informações durante as entrevistas é grande e a gravação é difícil ; a comunicação requer muitas habilidades eos analistas de sistemas devem ter conhecimento de domínio suficiente , etc. Além disso, durante a entrevista, você também poderá se deparar com alguns temas confidenciais e delicados para a empresa. Portanto, esta tecnologia aparentemente simples também exige que os analistas de sistemas tenham vasta experiência e fortes habilidades de comunicação.

• 
  Pesquisa por questionário Em comparação com entrevistas com usuários, a pesquisa por questionário pode coletar dados de um grande número de respostas em um curto espaço de tempo e com baixo custo; a pesquisa por questionário permite que os entrevistados preencham anonimamente, e a maioria dos usuários pode fornecer informações reais ; pesquisa por questionário Os resultados são mais fáceis organizar e contar . No entanto, a maior deficiência da pesquisa por questionário é a falta de flexibilidade. Outras deficiências incluem:
  ① As duas partes não se encontraram. O analista do sistema não pode obter mais algumas informações implícitas da expressão do usuário e de outras ações, e o usuário não tem oportunidade esclarecer imediatamente sua opinião sobre a questão. Respostas vagas ou incorretas.
  ② Os usuários podem psicologicamente não prestar atenção a um formulário pequeno e não levá-lo a sério, resultando em informações de feedback incompletas.
  ③ O questionário não permite responder às perguntas e não consegue compreender alguns detalhes.
  ④ O número de respondentes costuma ser menor do que o esperado e não há garantia de que os usuários responderão às perguntas ou explicarão melhor todas as perguntas.

• Pesquisa/amostragem por amostragem A pesquisa
  /amostragem por amostragem refere-se ao processo de seleção sistemática de um conjunto de amostra representativo de uma população . Através de um estudo cuidadoso do conjunto de amostra selecionado, informações úteis sobre a população como um todo podem ser reveladas. Para o desenvolvimento de sistemas de informação, a documentação (arquivos) do sistema existente é a população amostral. Ao começar a fazer uma análise de requisitos de um sistema, revisar a documentação do sistema existente é a melhor maneira de obter uma compreensão preliminar do sistema. No entanto, que tipos de documentos os analistas de sistemas devem examinar?Quando os dados nos documentos são muito grandes para serem estudados um por um, técnicas de amostragem precisam ser usadas para selecionar dados representativos . A tecnologia de amostragem não só pode ser usada para coletar dados, mas também para coletar entrevistas com usuários ou coletar e observar usuários. As mesmas técnicas de amostragem descritas acima se aplicam à amostragem de pessoas. Através da tecnologia de amostragem, a selecção de partes em vez de toda a população não só acelera o processo de recolha de dados, mas também aumenta a eficiência, reduzindo assim os custos de desenvolvimento. Além disso, a tecnologia de amostragem utiliza os princípios da estatística matemática para reduzir distorções na recolha de dados.
  No entanto, como a tecnologia de amostragem é baseada em princípios estatísticos, a determinação do tamanho da amostra depende da credibilidade esperada e do conhecimento prévio existente, e depende em grande parte dos fatores subjetivos do analista de sistema, da experiência pessoal e da experiência do analista de sistema. altamente dependente e exige que os analistas de sistema tenham um alto nível e uma experiência rica.

• Planejamento Conjunto de Requisitos (JRP)
  O JRP é um método relativamente caro de obtenção de requisitos, mas também é muito eficaz. Ele discute os requisitospor meio de reuniões organizadas . Normalmente o número de participantes nesta reunião é de 6 a 18 pessoas, e a duração é de 1 a 5 horas .
  A principal intenção do JRP é coletar requisitos em vez de analisar e verificar os requisitos . Os seguintes princípios principais devem ser compreendidos ao implementar o JRP:
  ① Antes da implementação do JRP, uma agenda detalhada deve ser formulada e rigorosamente seguida.
  ② Realizar de acordo com o cronograma estabelecido.
  ③ Tente registrar o conteúdo da reunião da forma mais completa possível.
  ④ Tente evitar o uso de termos profissionais durante a discussão.
  ⑤ Faça pleno uso das habilidades de resolução de conflitos.
  ⑥ Deve ser definido tempo de intervalo suficiente durante a reunião.
  ⑦Incentive a equipe a chegar a um consenso.
  ⑧ Garantir que todo o pessoal participante do JRP possa cumprir as regras previamente acordadas.

2.3 Análise de requisitos

Análise de requisitos : um bom requisito deve ter características como inequívoco, integridade, consistência, testabilidade, certeza, rastreabilidade, correção e necessidade.Portanto, os analistas precisam combinar requisitos confusos do usuário com Converter em necessidades do usuário é o trabalho da análise de requisitos.

Tarefas de análise de requisitos :
(1) Desenhar o diagrama de escopo do contexto do sistema
(2) Criar um protótipo de interface do usuário
(3) Analisar a viabilidade dos requisitos
( 4) Determinar a prioridade dos requisitos
(5) Estabelecer um modelo para os requisitos
(6) Criar um conjunto de dados dicionário
(7) Use QFD (Desdobramento da Função de Qualidade)

2.3.1 Método de Análise Estruturada-SA

O núcleo do método de análise estruturada SA é o dicionário de dados . Existem três níveis de modelos em torno deste núcleo, nomeadamente modelo de dados, modelo funcional e modelo comportamental (modelo de estado) .

As etapas da análise estruturada são as seguintes:
(1) Analisar a situação do negócio e fazer um diagrama de fluxo de dados (Data Flow DiagramDFD) que reflita o modelo físico atual.
(2) Derive o DFD do modelo logístico equivalente.
(3) Projetar um novo sistema lógico e gerar dicionário de dados e descrição primitiva.
(3) Estabelecer uma interface homem-máquina e propor um DFD alternativo do modelo físico do sistema alvo.
(5) Determinar os custos e níveis de risco de várias opções e analisar várias opções em conformidade.
(6) Escolha um plano.
(7) Estabeleça uma especificação completa de requisitos.

O método de análise estruturada SA é fluxo de dados e fluxo de controle.Os métodos comumente usados ​​são diagrama de fluxo de dados (DFD) e dicionário de dados.

2.3.1.1 SA - Dicionário de Dados DD

O dicionário de dados é o núcleo do modelo de análise de requisitos. É uma descrição de cada fluxo de dados, arquivo, processo e item de dados que compõe o fluxo de dados ou arquivo no diagrama de fluxo de dados.

O dicionário de dados possui quatro categorias de entradas: fluxo de dados, itens de dados, armazenamento de dados e processamento básico. Incluindo elementos de dados, estruturas de dados, fluxos de dados, lógica de processamento e entidades externas. Como mostrado abaixo:

2.3.1.2 SA - Diagrama de Fluxo de Dados DFD

O diagrama de fluxo de dados (DFD) usa um diagrama de fluxo de dados para representar um modelo funcional. O DFD descreve as funções concluídas pelo sistema. Do ponto de vista da transmissão e processamento de dados, símbolos gráficos são usados ​​para descrever as funções de cada componente do sistema e a transferência de dados entre eles através da subdivisão camada por camada. situação para ilustrar as funções concluídas pelo sistema. Como mostrado abaixo:

Entre eles, o DFD também terá “mapa DFD de nível superior” e “mapa DFD de camada 0”.

Conforme mostrado na figura acima, existem as seguintes descrições de "elementos de imagem":

Em anexo está um diagrama DFD incorreto, como segue:

Erro conforme mostrado acima:

O processamento 3.1.2 tem entrada, mas não tem saída, o que é chamado de "buraco negro".
O processamento 3.1.3 tem saída, mas não tem entrada. Chame isso de "milagre".
No processamento 3.1.1, a entrada não é suficiente para produzir a saída, que chamamos de “buraco cinza”.

2.3.1.3 SA - Diagrama de Transição de Estado STD

Um diagrama de transição de estado é usado para representar um modelo comportamental.STD representa o comportamento do sistema descrevendo o estado do sistema e os eventos que causam a transição de estado do sistema, indicando quais ações serão executadas como resultado de eventos específicos. Como mostrado abaixo:

2.3.1.4 SA - diagrama ER/diagrama entidade-relacionamento

O diagrama ER descreve principalmente os atributos da entidade e os relacionamentos entre as entidades. Além disso, o modelo ER é um modelo e produto da era estruturada e não existe na orientação a objetos e na UML. Como mostrado abaixo:

O que é uma entidade fraca?
Por exemplo: No sistema de gestão de pessoal, a informação sobre os filhos dos empregados baseia-se na existência de empregados.A entidade infantil é uma entidade fraca, e a relação entre filhos e empregados é uma relação de dependência. Portanto, os colaboradores são entidades e também podem se tornar entidades fortes.
A relação entre entidades fortes e entidades fracas só pode ser 1:1 ou 1:N.

2.3.2 Método de análise orientada a objetos - OOA

Vários conceitos relacionados

objeto	Atributo [dados] + método [operação] + ID do objeto/ID de identificação
Aula [ver detalhes abaixo]	Classe de entidade/classe de controle/classe de limite Classe de entidade: geralmente tem um relacionamento correspondente com o banco de dados, seja um tipo de dados Classe de controle: uma classe que conecta classes de entidade e classes de limite Classe de limite: uma classe que se comunica com o exterior no limite de um sistema A relação entre três modelos MVC semelhantes, suas ideias são as mesmas
Herança e generalização	Mecanismo de reutilização, é uma espécie de acoplamento apertado. Porque quando a classe pai muda, a subclasse tem que mudar. A herança é baseada em instâncias existentes
encapsulamento	Oculte as propriedades e detalhes de implementação do objeto e exponha apenas a interface ao mundo externo
Polimorfismo	Objetos diferentes recebem as mesmas informações e produzem resultados diferentes.
interface	Uma classe especial que possui apenas definições de métodos, mas nenhuma implementação de métodos
Sobrecarga	Uma classe pode ter vários métodos com o mesmo nome e diferentes tipos de parâmetros. A característica de uma função com o mesmo nome, mas com parâmetros diferentes, é que
comunicação de notícias	As mensagens são comunicadas de forma assíncrona
Substituir e reescrever	O método com o mesmo nome da subclasse substitui o método com o mesmo nome da classe pai
Combinação e agregação	Relação de agregação: a relação entre as peças do automóvel e todo o veículo (o ciclo de vida do todo e da peça é diferente) Relação de combinação: a relação entre departamentos e empresas. Se a empresa falir, os departamentos serão extintos (todo o ciclo de vida é igual ao ciclo de vida da peça)

OOA segue aproximadamente as 5 etapas básicas a seguir:

(1) Determinar objetos e classes : O objeto mencionado aqui é uma abstração de dados e seu método de processamento, refletindo a capacidade do sistema de salvar e processar informações sobre certas coisas no mundo real. Uma classe é uma descrição de uma coleção de propriedades e métodos comuns para vários objetos. Inclui uma descrição de como criar um novo objeto em uma classe.
(2) Determine a estrutura : Estrutura refere-se à complexidade e às relações de conexão do domínio do problema. A estrutura dos membros da classe reflete a relação generalização-especialização, e a estrutura todo-parte reflete a relação entre o todo e a parte.
(3) Determine o tema : O tema refere-se à visão geral e ao modelo de análise geral das coisas.
(4) Determinar atributos : Atributos são elementos de dados que podem ser usados ​​para descrever instâncias de objetos ou estruturas de classificação, podendo ser fornecidos no diagrama e especificados no armazenamento do objeto.
(5) Determine o método : O método é algum método de processamento que deve ser executado após o recebimento da mensagem: o método deve ser definido no diagrama e especificado no armazenamento do objeto. Para cada objeto e estrutura, os métodos para adicionar, modificar, excluir e selecionar são implícitos (embora sejam definidos no armazenamento do objeto e não sejam mostrados no diagrama), e Alguns são exibidos.

2.3.2.1 OOA - UML

UML (Unified Modeling Language, independente de plataforma e linguagem) para análise de requisitos OOA consiste em blocos de construção básicos, regras e mecanismos comuns.

Blocos de construção básicos da UML [componentes importantes]

romances	descrever
Coisas estruturais	A parte mais estática, incluindo classes, interfaces, casos de uso de colaboração, classes de atividades, componentes e nós
Coisas comportamentais	Representa ações no tempo e no espaço, incluindo mensagens, sequências de ações e conexões
coisas de grupo	Pense nisso como uma caixa, como pacotes e componentes
anotar coisas	Parte de interpretação do modelo UML. Descrever, ilustrar e anotar elementos do modelo

A relação entre os blocos básicos de construção da UML [ligando estreitamente as coisas]

relação	descrever
Dependências	Quando uma coisa muda, afeta outra.Tanto as relações de inclusão quanto as de expansão são dependências.
relação de generalização	Relacionamento geral especial, objetos de elementos especiais podem substituir objetos de elementos gerais
relação de conexão	Descreve uma cadeia, que é uma conexão entre objetos
perceber relacionamento	接口与类之间的关系，一个类指定了由另一个类保证执行的契约

UML基本构造块之图【多个相互关联的事物的集合】

图	描述
静态图	结构图
类图	描述一组类，接口协作和它们之间的关系。
对象图	描述一组对象以及它们之间的关系。对象图往往只在需要描述复杂算法时才会使用，画出来的对象图往往不会只有一个对象。
构件图	也叫组件图，是描述软件内部物理组成的一种图。系统里有哪些构件 构件之间有啥联系。描述一个封装的类和它的接口，端口，以及由内嵌的构件和连接件构成的内部结构。强调由小的部件构件大的系统。
部署图	表示为软件和硬件之间的映射。为了完成系统需要什么样配置的操作系统，内存，CPU等不在它范畴内，它只解决开发的系统如何去部署的问题。
制品图	描述计算机中一个系统的物理结构。制品包括文件，数据库，和类似的物理比特集合。
包图	将某些类放入“包”中，通过包图来组织业务概念图。
组合结构图	展示该部分内容“内部”参与者的配置情况。这个图不常用。
动态图	行为图
用例图	系统与外部参与者的交互。描述一组用例，参与者及他们之间的关系的图。
顺序图	强调按时间顺序。顺序图和通信图我们又称其为交互图。顺序图能够表达用户与系统的复杂交互过程。
通信图	也叫协作图，它强调的是相互之间关系，是顺序图的另外一种表达。
定时图	消息跨越不同对象或角色的实际时间。交互图的一种。
交互概览图	活动图与顺序图的结合。这个图不常用。
活动图	类似程序流程图，表示流程性的东西和并行的行为。它将进程或其他计算结构展示为计算内部一步步的控制流和数据流，它专注于系统的动态视图，它对系统功能建模和业务流程建模特别重要；并强调对象间的控制流程。
状态图	从某个物品的状态是如何变化的角度来展示流程。

UML规则

是构造块如何放在一起的规定，包括为构造块命名；给一个名字以特定含义的语境，即范围；怎样使用或看见名字，即可见性；事物如何正确、一致地相互联系，即完整性；运行或模拟动态模型的含义是什么，即执行。

UML公共机制

是指达到特定H标的公共UML方法，主要包括规格说明（详细说明）、修饰、公共分类（通用划分）和扩展机制4种。规格说明是事物语义的细节描述，它是模型真正的核心：UML为每个事物设置了一个简单的记号，还可以通过修饰来表达更多的信息；UML包括两组公共分类：类与对象（类表示概念，而对象表示具体的实体)、接门与实现（接口用来定义契约，而实现就是具体的内容)；扩展机制包括约束（扩展了UML构造块的语义，允许增加新的规则或修改现有的规则）、构造型（扩展UML的词汇，用于定义新的构造块）和标记值（扩展了UML构造块的特性，允许创建新的特殊信息来扩展事物的规格说明）。

UML中的概念

• 类：是描述具有相同属性、方法、关系和语义的对象的集合，一个类实现一个或多个接口。
• 接口：是指类或构件提供特定服务的一组操作的集合，接口描述了类或构件的对外的可见的动作。
• 构件：是物理上或可替换的系统部分，它实现了一个接口集合。提供一组接口的实现，是组成事物的元素。
• 包：是用于把元素组织成组的通用机制，它一个构件的抽象化的概念，是把类元按照一定的规则分成组（或称为模块）。
• 用例：是描述一系列的动作，产生有价值的结果。
• 协作：定义了交互的操作，是一些角色和其它事物一起工作，提供一些合作的动作，这些动作比事物的总和要大。
• 节点：是一个物理元素，它在运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力。

2.3.2.2 OOA - UML 4+1视图

现有的UML，再有的UML视图

UML采用4+1视图来描述软件和软件的开发过程，其中进程视图绘制了所设计的并发与同步结构；部署视图表示软件到硬件的映射和分布结构；UML中的类图可以用来表示4+1视图中逻辑视图；最终形成用例视图，用来得到需求分析模型。

“4+1”视图模型是从不同的视角、使用多个并发的视图来组织软件架构的描述。

“4+1”视图模型具有普遍适用性，实践证明能在许多大型项目中成功运用。

2.3.2.3 OOA - 用例模型与分析模型

在OOA的需求分析中，图的应用是经常被用到的。大部分的以用例模型和分析模型的建立为主线，其中用例模型采用用例图来构建，分析模型用类型表示。其它细节情况，也可以建立其它交互图。

2.3.2.4 需求分析工具

2.3.2.4.1 使用用例建模系统需求

用例建模来源于面向对象建模技术，但该技术也在非对象开发环境中比较流行，用例建模技术对传统的系统分析和设计工具进行了补充，例如数据建模和过程建模， 也提供了架构决策和用户界面设计决策的基础。

用例建模促进并鼓励了用户参与，具有如下优点：

• 提供了捕捉功能需求的工具。
• 有助于将系统分解为更易于管理的小块。
• 提供了与用户以及其他关心系统的关联人员进行交流的工具。
• 辅助估计项目范围、投入和进度。
• 提供了需求跟踪的工具。
• 提供了确定数据对象或实体的起点。
• 提供了设计用户和系统接口的功能规格说明。

为了决定用例的重要性，项目经理或者系统分析员将填写用例分级和评估矩阵，并使用来自关联人员和开发团队的输入构造用例依赖关系图。

1、项目经理使用称为用例分级和评估矩阵，决定用例的优先级。该矩阵使用6个标准按1 ~ 5级评估用例。6个标准是：

• 对架构设计的重要影响。
• 容易实现但包含重要功能。
• 包含有风险、时间紧迫或复杂的功能。
• 需要大量的研究或者新的、有风险的技术。
• 包含主要的业务功能。
• 将增加或者减少费用。

2、有些用例依赖于其他用例，其中一个用例使系统处于一种状态，该状态是另一个用例的前置条件。我们使用用例依赖关系图建模这种依赖关系。用例依赖关系图具有以下优点：

• 系统事件及其状态的图形化表述有利于对系统功能的理解。
• 有助于确定遗漏的用例。
• 通过描述哪个用例更关键并需要最高优先权，有助于推动项目管理。

2.3.2.4.2 数据建模与分析

数据建模是一种为数据库定义业务需要的技术，因为数据模型最终要实现成数据库，所以数据建模有时称为数据库建模。下图是一个简单的数据模型，称为实体关系图。

数据建模的系统概念：

• 实体
• 属性（数据类型、域、默认值）（键）
• 关系

如何构造数据模型？

• 获取实体。
• 构造上下文数据模型：包含基本业务实体及它们之间的自然关系。
• 基于键的数据模型：确定每个实体的键。
• 泛化层次体系：父实体、子实体。
• 具有完整属性的数据模型。
• 分析数据模型：规范化（第一范式、第二范式、第三范式）。
• 将数据需求映射到地点：数据–地点–CRUD矩阵。

2.3.2.4.3 过程建模

过程建模源自传统的软件工程方法，可能的过程模型包括程序结构图、逻辑流程图或决策表。本节重点介绍系统分析的过程模型，即数据流图。 数据流图是一种描述通过系统的数据流以及系统实施的工作或处理过程的工具。同义词包括泡式图、转换图和过程模型。

过程建模的系统概念：

• 外部代理：常见的同义词包括外部实体。
• 数据存储：是一个数据的“仓库”，同义词包括文件和数据库。
• 过程：即处理，是在输入数据流或条件上执行，或者对输入数据流或条件做出响应的工作，同义词是转换。分解图、层次图。注意避免过程中三种常见的错误：1）有输入没有输出，黑洞；2)有输出但没有输入，奇迹；3)输入不足以产生输出，灰洞（如输入一个雇员地址，输出一张财务报表）。
• 数据流：所有的过程至少都有一个输入流和一个输出流。数据流是过程与系统环境之间的通信。在数据流图中，有时需要描述分支的数据流或合并的数据流。分支的数据流是一个分成多个数据流的数据流，表示一个数据流的所有或者部分路由到不同目的地。合并的数据流是多个数据流合并成一个数据流后的数据流。合并的数据流指示了不同来源的数据流可以合并成一个报文供后续处理。

如何构造过程模型：

• 构造上下文数据流图：0号数据流图。
• 构造系统功能分解图。
• 事件响应或用例清单：构建分解图后，下一步是确定系统必须响应什么业务事件，（外部事件、时序事件、状态事件）。发现并确定事件和响应的更成功的方法之一是用例的技术。用例分析是确定并建模业务事件、谁触发事件以及系统如何响应事件的过程。
• 事件分解图：把事件处理过程增加到分解图中。
• 事件图：以分解图为提纲，可以为每个事件过程绘制一个事件图。
• 构造系统图：从原始的上下文图中的单个过程“爆炸”出来，在单张图中显示了系统的所有事件，显示了子系统的所有事件。 构造基本图：具有较复杂的事件图的事件过程应该扩展成一个更详细的基本数据流图，每个基本过程都是内聚的，也就是说仅完成一件事。
• 完成规格说明：对以上完成的数据流图中的每个数据流、数据存储和基本过程进行描述，并写进资料库中。对于过程内部的逻辑描述，我们可以使用结构化英语（自然英语+编程逻辑），用于说明过程模型中的基本过程的内部逻辑。但许多过程是由复杂的条件组合的（即业务策略），使用结构化英语不容易表达，此时可以使用决策表。

2.3.2.4.4 面向对象分析与建模

面向对象分析涉及到定义信息系统的静态和动态行为模型，而非定义数据和过程模型（这是传统开发方法的特点）。对象的标识，对象的数据部分（属性），对象的行为。

2.4 需求定义（形成需求规格）

需求定义的过程也就是形成需求规格说明书SRS的过程，通常有两种需求定义的方法，分别是严格定义方法和原型方法。

严格定义法的特点：所有需求都能够被严格定义；开发人员和用户之间能够准确而清晰的交流；采用图形文字能够充分体现最终系统。

原型法：并非所有的需求都能在开发前被准确的说明；项目参加者之间通常存在交流上的困难；需要实际的可供用户参与的系统模型；有合适的系统开发环境；反复是完全需要和值得提倡的，需求一旦确定就应该遵从严格的方法。

2.5 需求确认与验证

需求规格说明书SRS的需求验证也称为需求确认，其活动是为了确定以下几个方面的内容：

（1）SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征。
（2）SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的。
（3）需求是完整的和高质量的。
（4）需求的表示在所有地方都是一致的。
（5）需求为继续进行系统设计、实现和测试提供了足够的基础。

需求验证包括了需求评审和需求测试。

需求评审包括了：正式评审和非正式评审。需求验证是需要做用户签字确认，但往往实施起来比较困难，因为需求验证时签字就要负责任，它是验收的标准之一（此时的规格说明书SRS就是需求基线）。需求的评审需要用户的参与。

需求测试，不是运行类的测试而是设计测试用例进行测试，比如告诉你输入是什么输出是什么，所以更加接近于想像性测试，它是验证方向对不对该不该做的过程。需求测试仅仅是基于文本需求进行“概念”上的测试。然而，以功能需求为基础（SA方法）或者从用例派生出来（OO方法）的测试用例，可以使项目干系人更清楚地了解系统的行为。虽然没有在系统上执行测试用例，但是涉及测试用例的简单动作可以解释需求的许多问题。这种测试用例通常称为概念测试用例，即不是真正执行的测试用例，它们可以发现SRS中的错误、二义性和遗漏，还可以进行模型分析，以及作为用户验收测试的基础。在正式的系统测试中，还可以将它们细化成测试用例。

三、 需求管理（支持，保障）

在软件需求工程中，需求管理贯穿于整个过程中，它的最基本的任务就是明确需求，并使项目团队和用户达成共识，即建立需求基线。另外，还要建立需求跟踪能力联系链，确保所有用户需求都被正确地应用，并且在需求发生变更时，能够完全地控制其影响范围，始终保持产品与需求的一致性。

需求管理是可重复级的一个关键过程域，其目标是为软件需求建立一个基线，供软件开发及其管理使用，使软件计划、产品和活动与软件需求保持一致。从软件需求工程的角度来看，需求管理包括在软件开发过程中维持需求一致性和精确性的所有活动，包括控制需求基线，保持项目计划与需求一致，控制单个需求和需求文档的版本情况，管理需求和联系链之间的联系，或管理单个需求和项目其他可交付物之间的依赖关系，跟踪基线中需求的状态。

3.1 定义需求基线

需求开发的结果应该有项目视图和范围文档、用例文档和SRS，以及相关的分析模型。经评审批准，这些文档就定义了开发工作的需求基线。这个基线在用户和开发人员之间就构成了软件需求的一个约定，它是需求开发和需求管理之间的桥梁。

基线是一个软件配置管理的概念，它帮助开发人员在不严重阻碍合理变化的情况下来控制变化。根据IEEE的定义，基线是指已经通过正式评审和批准的规约或产品，它可以作为进一步开发的基础，并且只能通过正式的变更控制系统进行变化。在软件工程范围内，基线是软件开发中的里程碑，其标志是有一个或多个软件配置项的交付，且已经经过正式技术评审而获得认可。例如，SRS文档通过评审，其中的错误已经被发现并纠正，则就变成了一个基线。根据国家标准《计算机软件配置管理计划规范》（GB/T 12505-1990）的规定，基线可以分为功能基线、指派基线和产品基线三种，通过评审后的SRS（软件需求规格说明书）属于指派基线。

3.2 需求的状态

在需求状态的变化中，项目管理人员首先需要关注的是那些被拒绝和被丢弃的需求。因为这些需求有可能是应该被接受和并被实现的需求，如果不是通过有管理的处理过程，就有可能因为疏忽而被遗漏。同时，也应关注被交付的需求，因为可交付物是项目的成果体现，而可交付物的主要内容就是对需求的实现。

3.3 需求变更管理

CCB，变更控制委员会，也成配置控制委员会。
要让变更有序进行，首先需要有一个统一的单位来负责，这个单位一般叫变更控制委员会（Change
Control Board），也叫配置控制委员会（Configuration Control
Board）。CCB由项目干系人中有代表性的人员组成，人数没有限制，一个人也可以。CCB有能力在管理上做出承诺，对建议的配置项变更做出评价、审批及监督已批准变更的实施。CCB是决策机构，一般不参与具体的变更执行工作。

3.4 需求变更管理过程

（1）问题分析和变更描述。当提出一份变更提议后，需要对该提议做进一步的问题分析，检查它的有效性，从而产生一个更明确的需求变更提议。
（2）变更分析和成本计算。当接受该变更提议后，需要对需求变更提议进行影响分析和评估。变更成本计算应该包括对该变更所引起的所有改动的成本，例如修改需求文档、相应的设计、实现等工作成本。一旦分析完成并且被确认，应该进行是否执行这一变更的决策。
（3）变更实现。当确定执行该变更后，需要根据该变更的影响范围，按照开发的过程模型执行相应的变更。在计划驱动过程模型中，往往需要回溯到需求分析阶段开始，重新作对应的需求分析、设计和实现等步骤;在敏捷开发模型中，往往会将需求变更纳入到下一次迭代的执行过程中。

常见的需求变更策略：

(1) Todas as alterações de requisitos devem seguir o processo de controle de alterações.
(2) O trabalho de concepção e implementação não deve ser realizado para alterações que não tenham sido aprovadas.
(3) As mudanças devem ser decididas pelo Conselho de Controle de Mudanças do Projeto e quais mudanças devem ser implementadas.
(4) Os detentores dos riscos do projeto devem ser capazes de compreender o conteúdo das alterações.
(5) O documento original da solicitação de mudança não deve ser excluído ou modificado da biblioteca de configuração do projeto.
(6) Cada mudança de requisito integrada deve ser rastreável até uma solicitação de mudança aprovada para manter a rastreabilidade horizontal.

3.5 Risco de demanda

As práticas arriscadas incluem: ① Não há usuários suficientes para participar. ②A classificação do usuário é ignorada. ③As demandas dos usuários continuam a aumentar. ④ Necessidades ambíguas. ⑤Recursos desnecessários. ⑥SRS excessivamente simplificado. ⑦Estimativa imprecisa.

Razões para mudanças: ① Mudanças no ambiente externo. ②Os requisitos e o design não estão suficientemente completos. ③O surgimento de novas tecnologias. ④ A reorganização da organização da empresa resulta em mudanças nos processos de negócios.

3.6 Acompanhamento de requisitos

Os requisitos de cada item de configuração de software no SRS devem ser rastreáveis ​​bidirecionalmente aos requisitos dos sistemas (ou subsistemas) envolvidos. O chamado rastreamento bidirecional inclui rastreamento direto e rastreamento reverso. O rastreamento direto refere-se à verificação se cada requisito no SRS pode encontrar um ponto correspondente nos resultados de trabalho subsequentes; o rastreamento reverso, também chamado de rastreamento reverso, refere-se à verificação do projeto • Se documentos, códigos, casos de teste e outros resultados de trabalho podem ser encontrados no SRS.