软件需求总结(总)

软件需求工程复习归纳

课程目标:
  1. 系统地掌握需求开发和管理的技术和方法
  2. 掌握需求分析和建模的技术和方法
  3. 掌握需求规格的验证和评审等要点和方法
  4. 结合具体的实际项目开发,解决软件项目开发中的有关需求的各种问题
  5. 能够适应目前各种应用项目的系统的需求开发和管理工作
  6. 学习并掌握软件需求实践的工具和技巧
  7. 分析和解答软件工程实践中的困难和问题

软件工程与需求工程

生存期模型:

概念:软件开发的一种过程性框架

类型:瀑布模型、V模型、原型模型、增量式模型

瀑布模型:需求分析→设计→程序编码→软件测试→运行维护

不合格需求的主要原因

  • 用户参与度不够
  • 用户需求不要断增多
  • 需求说明模糊
  • 不必要的特性
  • 规格说明太粗
  • 不对用户分类
  • 计划不准确

需求工程

基本概念一种获取,组织并记录系统需求的系统化方法。以及一个使客户与项目团队不断变更的系统需求达成并保持一致的过程

层次特征:业务需求、用户需求、功能需求

注:需求分析:解决什么业务问题

? 需求规格说明:所开发的系统提供什么功能,性能

面对对象

概念面对对象由对象、类、继承、通信四个概念组成。

**对象:**在现实世界时是客观世界中的一个实体;在面向对象程序中表达成计算机理解、可操纵、具有一定属性的行为和对象;在计算机世界中是一个可标识的存储区域

封装:把对象的全部属性和全部服务结合到一起,形成一个不可分割的独立单位(对象),尽可能隐藏对象的全部细节(信息隐蔽)

继承:使用已存在的定义做为基础建立新定义的技术

统一建模语言UML

概念基于面向对象的可视化的通用(General)建模语言

用例图:

类图:

类图包含了一组类似及他们之间的关系

定义描述了系统中各种活动的执行顺序

组成:活动、转移、对象流、泳道(采用分组的机制)

转移:转移用带箭头的直线表示,可标注执行该转移的条件,无标注表示顺序执行。

泳道:一个道代表一组对象

顺序图:

需求获取

项目启动要考虑的问题:

愿景(描述项目核心价值【老大】)、涉众、投入、风险、可行

愿景:

没有度量指标的目标没有意义

  • 什么是愿景:在老大看来为什么要开发这个系统

  • 愿景的两个要点:1、一定来自老大的想法 2、一定要有度量指标

    例如:愿景→实现电子速汇款 度量指标→数据到账时间短

涉众:

同一件事不同利益视角,探索系统的需求就是探索涉众利益的平衡点

  • 划分原因:系统需求易变,业务需求(涉众利益)不变

  • 客户是最大的涉众

  • 划分涉众优先级

业务建模:

过程

  • 选定业务单元
  • 识别业务执行者
  • 识别业务用例
  • 详述业务用例
  • 建立对象模型

业务执行者:业务执行者在业务外面,业务工人在业务里面

业务单元:

概念:一个组织或人群

? 例:淘宝 业务单元为淘宝 公司及内部人员,业务实体则是淘宝 站

业务用例:

有效的完整目标

只针对业务执行者,为业务执行者提供价值(内部活动不是业务用例)

用例命名:执行者视角→动词+宾语

  • 慎用弱名词和弱宾语
  • 弱动词:进行、使用、复制、加载、重复….
  • 弱名词:数据、 表、表格、表单、系统…

用例的粒度:用例要有路径,路径要有步骤,而这一切都是可观测的

  • 最常犯的错误(错把步骤当作用例)

业务对象模型:

概念:业务对象模型(也叫领域模型)是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象

拓展路径:系统要处理的意外和分支

补充约束

  • 字段列表:

    • “+”→数据序列 “[ ]”→可选项 “{}*”→多个

      {|||}→可能取值 “A=B”把B的结构赋给A

    • 用表达式表示:

      用例的排序与分包:

      用例排序

      大量用例时的分包:按执行者分包、按主题分包、按开发团队分包、按发布情况分包

      包图:

      需求管理

      调研需求

      • 需求的研究对象
      • 需求的调研内容
      • 需要调研内容
      • 需求结果管理

      需求调研内容:功能、接口、用户使用环境、重要性要求、稳定性要求、易用性、性能

      需求调研方法:问卷调查、访谈、观察、开会、制作示意图、角色扮演、原型开发

      需求变更:

      随着系统上线,用户提出的问题和新的需求

      易用性问题:界面布局、操作方式、文字表达、排序条件等细节问题,这些问题不解决的话会降低用户体验,此类问题一般应尽量解决。

      拒绝变更

      • 并不是软件本身的问题
      • 根据愿景分析没必要将系统复杂化提高成本
      • 由于客观条件限制,或者技术上做不到的,要予以拒绝

      常见问题

      • 对于符合需求的易用性方面的要求,应尽量满足。

      • 有些问题可通过改善管理办法来解决。

      • 客观条件做不到的、技术上做不到的,应予以拒绝。

      • 超出范围的要求,可引导客户做第二期。

      • 有些问题需要同时在软件和管理办法上做工作来改善。

      ”老大“提出的新需求

      ”老大“的需求必须满足

      ”老大“提出的需求方案只是一种解决方案,可以通过分析用不同解决方案满足”老大“的根本需求。

      需求认知曲线

      两种需求认知曲线

      敏捷开发与敏捷需求

      敏捷过程希望尽快得到可以发布的软件版本,尽快得到反馈

      四句宣言:

      image-20211228211703481

      特点:

      • 需求模糊或快速变化的前提下,小型开发团队的软件开发活动
      • 做到“刚刚好”
      • 提高软件开发的效率
      • 以积极的态度对待需求的变化
      • 短时间不断地交付可运行的软件供用户使用

      声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2021年11月25日
下一篇 2021年11月25日

相关推荐