软考系统分析师知识点十三:软件需求工程

前言

今年报考了11月份的软考高级:系统分析师。

考试时间为:11月9日。

倒计时:24天。

目标:优先应试,其次学习,再次实践。

复习计划第一阶段:扫平基础知识点,仅抽取有用信息,可有缺失,但得过眼。

第十一章:软件需求工程

内容总结

1. 需求工程
  • 用户需求:通过访谈和问卷调查获取,描述用户目标和系统必须完成的任务。
  • 系统需求:包括功能需求(行为需求)、非功能需求(属性或品质)和设计约束(如技术限制)。
2. 质量功能部署(QFD)
  • 常规需求:用户认为系统应当实现的基本功能。
  • 期望需求:用户期望但未明确表述的功能。
  • 意外需求:超出用户期望的功能,增加用户满意度。
3. 需求获取
  • 访谈:包括准备、主持和后续工作,注意措辞和记录。
  • 问卷调查:设计调查表,包括开放式和封闭式问题,提高返还率的方法。
4. 需求分析
  • 需求分析任务:包括绘制系统上下文范围关系图、创建用户界面原型、分析需求可行性、确定需求优先级、建立分析模型、创建数据字典、使用QFD。
  • 需求分析方法:结构化分析(SA)、面向对象分析(OOA)、面向问题域分析(PDOA)。
5. 结构化分析方法(SA)
  • 数据流图(DFD):描述数据流动和处理过程,包括顶层图和逐层分解。
  • 状态转换图(STD):描述系统状态和引起状态转换的事件。
6. 面向对象分析方法(OOA)
  • UML:统一建模语言,包括类图、用例图、顺序图、状态图等。
  • 用例图:描述系统功能和用户交互,包括参与者和用例。
7. 需求定义
  • 需求规格说明书(SRS):详细描述软件需求,包括范围、引用文件、需求、合格性规定、需求可追踪性、未解决的问题、注解和附录。
8. 需求验证
  • 需求评审:通过评审会议对SRS进行评估,确保需求的正确性和完整性。
  • 需求测试:基于概念测试用例进行验证,发现SRS中的错误、二义性和遗漏。
9. 需求管理
  • 需求基线:需求开发结果,作为开发基础,只能通过正式的变更控制系统进行变化。
  • 需求变更管理:控制需求变更,减少对项目成本、进度和质量的影响。
10. 需求跟踪
  • 需求跟踪矩阵:记录需求与系统元素的对应关系,包括正向跟踪和反向跟踪。
  • 正向跟踪:从用户需求到软件需求的追溯。
  • 反向跟踪:从软件需求到用户需求的追溯。
11. 风险管理
  • 风险识别:预先识别项目中可能的风险。
  • 风险应对:制定应对策略,减少风险影响。

不常见概念

  1. 需求工程的重要性

    需求工程是确保软件开发项目成功的关键步骤。它涉及到理解、收集、分析和记录用户的需求。如果需求工程做得不好,可能会导致项目目标不明确,开发出的产品不符合用户的期望,甚至导致项目失败。需求工程的成果通常包括需求规格说明书,这是后续设计和开发工作的基础。

  2. 需求的层次

    • 业务需求:反映了组织的战略目标和业务目标,通常由高层管理人员提出。
    • 用户需求:描述了用户希望系统能够完成的具体任务,通常通过用户访谈、调查问卷等方式收集。
    • 系统需求:详细描述了系统必须实现的功能和性能,包括软件必须执行的操作和系统必须满足的标准。
  3. 需求获取方法

    需求获取是需求工程的第一步,涉及到使用各种技术来收集用户的需求。这些方法包括:

    • 用户访谈:通过与用户的直接对话来获取需求,适用于获取详细和深入的信息。
    • 问卷调查:通过设计问卷来收集大量用户的需求,适用于用户数量众多且分散的情况。
    • 采样:从大量数据中选择有代表性的样本进行研究,以了解用户的需求和偏好。
    • 情节串联板:通过一系列图片或场景来讲述故事,帮助用户和开发团队共同理解需求。
    • 联合需求计划(JRP):通过组织跨部门的会议来共同讨论和定义需求。
  4. 需求分析

    需求分析是对收集到的需求进行分析和整理的过程。这一步骤的目的是确保需求是可行的、无歧义的、完整的,并且可以被测试。需求分析的方法包括:

    • 结构化分析方法:使用数据流图(DFD)和其他结构化图表来表示系统的功能。
    • 面向对象分析方法:使用UML图来表示系统的类、对象和它们之间的关系。
    • 面向问题域的分析:关注问题域的本质,而不是过早地陷入解决方案的细节。
  5. 需求文档化

    需求文档化是将需求分析的结果记录下来的过程。需求规格说明书(SRS)是需求文档化的主要成果,它详细描述了系统的需求,并作为开发和测试的基础。SRS应该清晰、准确地描述需求,以便所有项目干系人都能理解和同意。

  6. 需求验证

    需求验证是确保需求文档准确反映了用户需求的过程。这通常涉及到需求评审,其中包括:

    • 评审:正式的会议,向用户和其他项目干系人介绍需求,以获得反馈和批准。
    • 检查:由非作者的个人或小组详细检查需求文档,以发现错误和不一致之处。
    • 走查:由开发人员领导的评审过程,团队成员对工作产品进行检查和讨论。
  7. 需求管理

    需求管理是确保需求在整个项目生命周期中保持一致性和可追踪性的一系列活动。这包括:

    • 需求基线:建立一个稳定的、经过批准的需求集合,作为后续开发的基础。
    • 需求变更管理:控制和记录需求的变更,确保这些变更不会对项目造成负面影响。
    • 需求跟踪:建立需求与其他项目元素(如设计、代码和测试)之间的联系。
  8. 需求跟踪

    需求跟踪是确保需求在整个开发过程中得到满足的一种方法。它涉及到建立需求与其他工作产品之间的联系,以便可以追踪每个需求的实现和验证情况。需求跟踪的目的包括:

    • 审核:确保所有需求都被正确实现。
    • 变更影响分析:在需求变更时,评估对项目的影响。
    • 维护:在系统维护阶段,确保变更得到正确实施。
  9. 风险管理

    风险管理是识别、评估和应对项目中潜在风险的过程。与需求相关的风险可能包括:

    • 需求不明确:导致开发团队误解或实现错误。
    • 需求变更:可能导致项目延期和成本增加。
    • 需求蔓延:用户不断增加新的需求,导致项目范围不断扩大。
  10. 原型方法

    原型方法是一种迭代的开发方法,它允许在早期阶段创建一个系统的原型,以便用户可以与之交互并提供反馈。这种方法有助于:

    • 早期反馈:用户可以在开发早期提供反馈,从而避免后期的重大变更。
    • 需求验证:通过原型验证需求的可行性和用户满意度。
  11. 质量功能部署(QFD)

    QFD是一种将用户需求转化为产品特性的方法。它通过识别用户的需求和期望,并将它们映射到产品特性,从而确保产品能够满足用户的需求。QFD的目的是:

    • 提升满意度:确保产品特性能够满足用户的需求,从而提升用户满意度。
    • 优先级排序:根据用户的需求对产品特性进行优先级排序。
  12. 需求的可测试性

    需求应该是可测试的,这意味着需求应该被表述得足够具体和明确,以便可以设计测试用例来验证它们。这包括:

    • 测试用例设计:为每个需求设计测试用例,以确保需求得到满足。
    • 测试执行:执行测试用例,验证需求是否得到实现,并记录测试结果。

写在最后

以上均为粗看教程的总结,目的不是为了百分之百准确,而是为了过手过脑,有所印象。

但是如有发现谬误,感谢各位随时指出。

-- 欢迎点赞、关注、转发、收藏【我码玄黄】,各大平台同名。

相关推荐
奔跑吧邓邓子4 天前
【软考中级网络工程师】知识点之网关协议深度剖析
网络工程师·软考·网关协议·中级
奔跑吧邓邓子11 天前
【软考中级网络工程师】知识点之 STP 协议,网络的 “交通协管员”
网络工程师·软考·中级·stp协议
奔跑吧邓邓子13 天前
【软考中级网络工程师】知识点之 RIP 协议
网络工程师·软考·rip协议·中级
奔跑吧邓邓子14 天前
【软考中级网络工程师】知识点之级联
网络工程师·软考·级联·中级
奔跑吧邓邓子15 天前
【软考中级网络工程师】知识点之堆叠
网络工程师·软考·中级
蝸牛ちゃん17 天前
面向对象系统的单元测试层次
系统架构·单元测试·软考高级
蝸牛ちゃん18 天前
万字深度详解DHCP服务:动态IP地址分配的自动化引擎
网络·网络协议·tcp/ip·系统架构·自动化·软考高级·dhcp
蝸牛ちゃん18 天前
设计模式(十一)结构型:外观模式详解
设计模式·系统架构·软考高级·外观模式
蝸牛ちゃん19 天前
设计模式(二十四)行为型:访问者模式详解
设计模式·系统架构·软考高级·访问者模式
蝸牛ちゃん19 天前
设计模式(十六)行为型:解释器模式详解
设计模式·系统架构·解释器模式·软考高级