软件需求建模方法并没有绝对固定的数量（因分类维度和细化程度不同而有差异），但行业中主流的方法可归纳为6大类别，包含十几种具体技术。这些方法从不同角度（如数据、行为、结构、用户视角等）描述系统需求，帮助团队清晰、一致地理解需求。
1. 结构化建模方法（传统方法）
聚焦系统的功能、数据流程和结构，适合结构化开发（如瀑布模型）。
- 数据流图（DFD）：通过“数据流”“加工”“数据存储”“外部实体”描述系统数据的流动和处理过程。
- 实体关系图（ERD）：描述系统中实体（如用户、订单）及实体间的关系（如“用户下单”），用于数据建模。
- 状态转换图（STD）：描述系统或对象在不同状态下的转换规则（如“订单”从“待支付”→“已支付”→“已发货”的状态变化）。
- 功能分解图（FDD）：将系统功能逐层分解为子功能（如“电商系统”→“订单管理”→“创建订单”），体现功能层次结构。
2. 面向对象建模方法
以“对象”为核心，关注系统的对象、交互和行为，适合面向对象开发（如UML驱动开发）。
- 用例图（Use Case Diagram）：从用户视角描述系统的功能（用例）及用户（参与者）与功能的交互（如“用户登录”“管理员审核订单”）。
- 类图（Class Diagram）：描述系统中的类（属性、方法）及类之间的关系（继承、关联、聚合等），体现系统的静态结构。
- 序列图（Sequence Diagram）：按时间顺序描述对象间的交互（如“用户下单”时，“用户”“订单系统”“支付系统”的消息传递流程）。
- 活动图（Activity Diagram）：描述复杂流程（如“订单处理流程”），包含分支、并行等逻辑，类似流程图但更贴近对象行为。
- 状态机图（State Machine Diagram）：细化对象的状态转换（比STD更面向对象），如“商品”从“库存中”→“已售罄”→“补货中”的状态变化。
3. 行为建模方法
聚焦系统的动态行为（如响应、规则、事件）。
- 事件-响应模型：描述系统对外部事件（如“用户点击提交”）的响应逻辑（如“验证数据→保存信息”）。
- 业务规则引擎（BRE）：用规则表达式（如“满100减20”）描述业务约束，适合规则复杂的场景（如电商促销、金融风控）。
4. 原型建模方法
通过“可视化原型”直观呈现需求，适合需求模糊或用户难以描述的场景（如UI/UX需求）。
- 低保真原型：如手绘界面、流程图，快速验证功能流程。
- 高保真原型：如Axure制作的可交互界面，模拟用户操作体验。
5. 敏捷建模方法
适合敏捷开发，强调轻量化、快速迭代。
- 用户故事（User Story）：用简洁语言描述用户需求（格式：“作为<角色>，我想<功能>，以便<价值>”），如“作为买家，我想查看订单物流，以便跟踪商品位置”。
- 用户故事地图（User Story Map）：将用户故事按“用户目标”和“流程步骤”排列，梳理需求优先级和整体脉络。
6. 形式化建模方法
用数学符号或逻辑语言（如Z语言、Petri网）精确描述需求，适合高可靠性系统（如航天、医疗设备），可通过工具验证需求的一致性和无歧义性。
总结
实际项目中通常会组合多种方法（如用例图+ERD+用户故事），根据项目类型（如电商、工业软件）、团队习惯和需求复杂度选择。核心目标是：让需求从“模糊描述”转化为“可理解、可验证、可追溯”的模型。