🏆 作者简介,愚公搬代码 🏆《头衔》:华为云特约编辑,华为云云享专家,华为开发者专家,华为产品云测专家,CSDN博客专家,CSDN商业化专家,阿里云专家博主,阿里云签约作者,腾讯云优秀博主,腾讯云内容共创官,掘金优秀博主,51CTO博客专家等。 🏆《近期荣誉》:2022年度博客之星TOP2,2023年度博客之星TOP2,2022年华为云十佳博主,2023年华为云十佳博主等。
🏆《博客内容》:.NET、Java、Python、Go、Node、前端、IOS、Android、鸿蒙、Linux、物联网、网络安全、大数据、人工智能、U3D游戏、小程序等相关领域知识。
🏆🎉欢迎 👍点赞✍评论⭐收藏
软件工程需求分析是软件开发过程中的重要环节之一,它主要是通过收集、分析和规范用户的需求,为软件开发团队提供明确的需求指导,确保软件开发的目标和方向与用户需求一致。
在软件工程需求分析过程中,一般包括以下几个主要步骤:
需求分析是软件开发过程中的关键环节,它对于软件开发的成功与否起着至关重要的作用。只有通过需求分析,开发团队才能了解用户的真实需求,设计出符合用户期望的软件系统。
软件需求是指用户或相关利益相关方对软件系统所提出的期望或要求。它涵盖了系统的功能、行为、性能、设计约束
等方面。
功能需求
描述了系统应该具有的功能和特性。这些功能需求可以是用户期望的基本功能,也可以是系统必须具有的关键功能。行为需求
描述了系统在不同情况下的行为和响应。这些行为需求可以包括用户界面的交互过程、数据处理过程、错误处理过程等。性能需求
描述了系统在处理各种输入情况下的性能要求。这些性能需求可以包括系统的响应时间、吞吐量、可靠性等。设计约束
描述了系统设计和实现时需要遵循的约束条件。这些约束条件可以包括操作系统和硬件平台的要求、技术限制、安全需求等。IEEE中的定义是:软件需求指用户解决问题或达到目标所需要的条件或能力,是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力,以及反映这些条件或能力的文档说明。
软件需求的分类:软件需求就是软件必须完成的事以及必须具备的品质。需求是多层次的,包括业务需求、用户需求和系统需求,这三者是从目标到具体,从整体到局部,从概念到细节。
需求分类 | 描述 |
---|---|
业务需求 | 反映企业或客户对系统高层级的目标要求(高层级需求) |
用户需求 | 描述用户的具体目标,用户想要什么,以及要这些做什么(用户需求) |
系统需求 | 从系统的角度说明软件的需求,包括功能需求、非功能需求、设计约束等 |
-- 功能需求 | 系统必须完成的那些事,即为了向其用户提供有用的功能,产品必须执行的动作 |
-- 非功能需求 | 产品必须具备的性能或品质,例如,可靠性、容错性等 |
-- 设计约束 | 也称为限制条件、补充规约,通常是对解决方案的一些约束说明,例如,某系统必须采用国有自主知识版权的数据库,必须运行在UNIX系统之下,等等 |
质量功能部署(QFD)是一种技术,旨在将用户要求转化为软件需求,以最大限度提高用户满意度。它通过多层次的演绎分析,将用户对产品的需求转化为产品设计需求、工程部件特征、工艺要求和生产要求,以指导产品设计和保证产品质量。由于QFD使用的图形类似于房屋,因此也被称为"质量屋"。
QDF将软件需求分为三类:
软件需求分类 | 描述 |
---|---|
常规需求 | 系统应该做到的功能或性能,实现的越多,用户越满意 |
期望需求 | 用户想当然认为系统应该做到,但是不能正确表达的功能,没有实现会让用户不满意 |
意外需求 | 用户要求范围外的功能或性能,开发人员控制,实现会高兴,不实现也没关系 |
需求工程:是一个不断反复的需求定义、文档记录、需求演进的过程,并最终在验证的基础上冻结需求。需求工程可以细分为需求获取、需求分析(包括系统建模)、需求规约、需求验证以及需求管理5个阶段。
需求开发的4个阶段:
在需求开发阶段需要确定产品所期望的用户类型、获取每种用户类型的需求、了解实际的用户任务和目标,以及这些任务所支持的业务需求。
同时还包括分析源于用户的信息、对需求进行优先级分类、将所收集的需求编写成为软件规格说明书和需求分析模型,以及对需求进行评审等工作。
需求获取是一个确定和理解不同项目干系人的需求和约束的过程。在需求获取的过程中,主要解决需求调查的问题。为了做好需求调查,必须清楚地了解以下三个问题:
常见的需求获取方式有:
需求获取方式 | 描述 |
---|---|
用户访谈 | 一对一进行访谈,适合于针对有代表性的用户。形式分为结构化和非结构化两种。 |
问卷调查 | 设计问题、制作成用户调查问卷、下发填写、整理分析。适合用户面广、用户需要灵活时间进行回馈。 |
采样 | 采用统计分析技术,从目标总体中选择出样本集的过程。可以是随机抽样,也可以是非随机抽样。适合用于大量用户信息或者数据信息采集分析,最终得出需求的场景。 |
情节串联板 | 一系列图片,通过这些图片来讲述故事,从而帮助理解用户需求和场景。 |
联合讨论会 | 通过联合关键用户代表、系统分析师、开发团队代表等进行组织的会议,讨论需求,以促进有效的交流和共识形成。 |
需求记录技术 | 使用任务卡片、场景说明、用户故事等方式来记录和描述用户需求,以便后续分析和编写需求规格书。 |
需求分析是将用户的杂乱无章的要求和期望转化为清晰、准确、可测试、可跟踪的系统需求,并形成最终的需求规约。一个好的需求应具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性和必要性等特性。
在需求分析过程中,需求分析人员逐步细化软件功能,找出系统各元素之间的联系、接口特性和设计上的限制,并分析它们是否满足需求。不合理的部分被剔除,需要的部分被增加。最终,综合成系统的解决方案,并给出详细的逻辑模型,描述系统的功能和实现方式。
需求分析的任务包括:
目前,已存在的多种需求分析方法引用了不同的分析策略,常用的分析方法有以下两种:
结构化分析方法的特点是:自顶向下、逐步分解、分析的核心是数据字典。
结构化分析应该建立三种模型:数据模型、功能模型、行为模型:
模型类型 | 描述 | 常用图示 |
---|---|---|
数据模型 | 描述实体、属性和实体间的关系 | 实体关系(E-R)图 |
功能模型 | 描述数据在系统间的传递情况 | 数据流图(DFD) |
行为模型 | 描述系统状态和状态转换的事件,指出系统行为和执行的动作 | 状态转换图(STD) |
描述数据在系统中如何被传送或变换,以及如何对数据流进行变换的功能或子功能,用于对功能建模,数据流图相关概念示例如下:
数据图是一种可以分层的图表,根据层级可以分为顶层数据流图、中层数据流图和底层数据流图。顶层数据流图是最高层的图表,其他数据流图从零开始编号。
数据流图级别 | 描述 |
---|---|
顶层数据流图 | 只有一个加工,代表整个系统。包括输入数据流和输出数据流,表示系统的范围和与外部环境的数据交换关系。 |
中层数据流图 | 对顶层数据流图中的某个加工进行细化,可以再次细化形成子图。中间层次的多少取决于系统的复杂程度。 |
底层数据流图 | 不能再分解的数据流图,其加工称为"原子加工"。 |
软件需求规约(SRS)是需求分析任务的最终产物,也被称为需求定义或软件需求规格说明书。它通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明,以及合适的验收标准,来提供对目标软件的各种需求。作为用户和开发者之间的一个协议,需求规约在软件工程的各个阶段发挥重要作用。
内容 | 描述 |
---|---|
引言 | 描述软件目标,以计算机系统为背景进行阐述 |
信息描述 | 描述问题的详细说明、信息内容、信息流和信息结构 |
功能描述 | 为每个功能提供处理过程说明,描述设计约束和性能特征,使用图形表示软件的整体结构和与其他系统元素的相互影响 |
行为描述 | 描述软件操作的外部事件和内部控制特征 |
校验标准 | 描述系统成功的测试标准,即哪些测试和结果表示系统已成功实现 |
参考书目 | 引用与软件相关的文档,包括其他软件工程文档、技术参考文献、厂商文献和标准 |
附录 | 包含补充信息、表格数据、算法描述、图表和其他资料等 |
需求验证,也称为需求确认,旨在与用户一起确认需求的准确性。这个过程包括两个步骤:需求评审和需求测试。需求评审是对需求规约进行正式或非正式的评审。需求测试则是设计概念测试用例来验证需求。
需求验证作为需求开发阶段的一项工作,旨在复查需求的正确性、完整性和清晰性,以确保它能够准确反映用户的意愿。由于需求的变化可能会导致系统设计和实现的变更,因此,由需求引起的系统变更成本往往比修改设计或代码错误的成本要高得多。为了确保软件需求定义的质量,评审应由专门的人员负责,并按照规程严格进行。除了分析人员外,还应有用户、开发部门的管理者以及软件设计、实现和测试人员参加评审。
需求验证通过后,需要请用户签字确认,作为验收标准之一。此时,需求规格说明书作为需求基线,不可再随意更新。如果需要更改,必须按需求变更流程进行。需要注意的是,需求验证无法发现所有的需求问题。因此,在需求验证之后,无法避免地会对遗漏的需求进行补充,对错误理解进行更正,需求管理是必要的。
软件需求管理是指在软件项目进行过程中,通过一系列的活动来识别、控制和跟踪需求。它涉及需求工程的规划和控制,以获取、组织和记录系统需求,并使用户和项目团队在不断变更的需求上达成一致。需求管理是确保软件开发过程中需求的正确性、一致性和有效性的关键过程。它帮助项目团队确定和理解用户需求,并在开发过程中追踪和管理这些需求的变化。
在需求管理中,每个需求被赋予唯一的标识符,这种需求的唯一标识符通常被称为需求ID,它可以是一个数字、字母或组合的代码。通过为需求建立跟踪表,可以清楚地记录需求与其他相关文档或代码的关系,方便跟踪和管理需求的变更和演化过程。
特征跟踪表:
需求ID | 特征1 | 特征2 | 特征3 | ... |
---|---|---|---|---|
REQ001 | 是 | 否 | 是 | ... |
REQ002 | 否 | 是 | 否 | ... |
REQ003 | 是 | 是 | 是 | ... |
... | ... | ... | ... | ... |
来源跟踪表:
需求ID | 来源1 | 来源2 | 来源3 | ... |
---|---|---|---|---|
REQ001 | 用户反馈 | 业务需求 | ... | ... |
REQ002 | 业务需求 | ... | ... | ... |
REQ003 | 用户反馈 | 业务需求 | 用户调研 | ... |
... | ... | ... | ... | ... |
依赖跟踪表:
需求ID | 依赖需求1 | 依赖需求2 | 依赖需求3 | ... |
---|---|---|---|---|
REQ001 | REQ002 | REQ003 | ... | ... |
REQ002 | REQ004 | ... | ... | ... |
REQ003 | REQ002 | REQ005 | ... | ... |
... | ... | ... | ... | ... |
跟踪表可以包含以下信息:
这些跟踪表可以用于需求跟踪。在整个开发过程中,进行需求跟踪的目的是为了建立和维护从用户需求开始到测试之间的一致性与完整性,确保所有的实现是以用户需求为基础,所有的输出符合用户需求,并且全面覆盖了用户需求。
是的,版本控制在需求管理中起到非常重要的作用。通过版本控制,可以确保团队和用户之间对需求的共识,并定义需求的基线。一旦需求规约经过评审并形成了需求基线,下次如果有需求变更,则需要按照一定的流程进行处理。
版本控制可以通过以下步骤来进行:
1、 需求跟踪
需求跟踪是确保软件开发过程中满足用户需求的一种方法。正向跟踪和逆向跟踪是两种常用的需求跟踪方式。
正向跟踪是从用户需求出发,通过检查需求规约中的每个需求是否在后继工作产品中找到对应点来进行跟踪。简单来说,就是核对用户原始需求是否都已实现。
逆向跟踪则是从工作产品出发,检查设计文档、代码、测试用例等产品是否能在需求规约中找到对应的来源。简单来说,就是检查软件实现是否符合用户需求。
2、状态跟踪
整个项目过程中,要始终跟踪需求状态即变更情况
变更控制是项目管理中关键的一环,其主要目标是管理需求的变更,确保变更的合理性和有效性。在需求变更过程中,存在一些潜在的风险,需要进行风险管理。
以下是一些带有风险的做法:
风险因素 | 描述 |
---|---|
无足够用户参与 | 如果项目团队缺乏与最终用户的充分沟通和合作,可能导致对用户需求的误解和遗漏,最终影响项目的成功。 |
忽略用户分类 | 不同用户群体有不同的需求和优先级,忽略了用户分类可能导致无法满足某些重要用户群体的需求,降低项目价值。 |
用户需求的不断增加 | 如果在项目进行过程中,不断有新的需求被提出并接受,可能导致项目进度延迟和成本增加。 |
模棱两可的需求 | 如果需求描述模糊不清或存在歧义,可能导致开发过程中产生错误理解,最终交付的产品不符合预期。 |
不必要的特性 | 如果项目团队在需求变更过程中不加以筛选和评估,可能导致添加不必要的特性,增加开发成本和复杂性。 |
过于精简的SRS | 如果需求文档(SRS)过于简单和不完整,可能导致对需求的理解不准确或遗漏,影响项目的规划和实施。 |
不准确的估算 | 如果在需求变更过程中对成本、时间和资源的估算不准确,可能导致项目延期、超支和资源不足。 |
变更原因 | 描述 |
---|---|
外部环境的变化 | 市场需求的变化、竞争对手的新产品推出、法规政策的调整等,都可能导致业务流程和需求发生变化,从而需要进行变更。 |
需求和设计不够完整 | 在项目开始阶段,需求和设计可能未能考虑到所有情况,或者在实施过程中发现了一些问题,需要进行相应的调整和变更。 |
新技术的出现 | 随着科技的不断发展,新的技术可能提供了更好的解决方案,或者能够提高效率和质量,因此需要对原有系统进行升级或变更。 |
公司机构重组 | 公司的组织结构发生调整,业务流程可能会有所变化,需要调整相应的系统和流程来适应新的组织架构。 |
变更控制委员会(Change Control Board, CCB)是一个负责评价、审批和监督变更的组织机构。它也被称为配置控制委员会。CCB通常由项目经理、技术专家、利益相关者和其他相关人员组成。它的任务包括:
CCB职责 | 描述 |
---|---|
评价变更建议 | CCB会对提出的配置项变更建议进行评估,包括对其目的、范围、影响和风险等方面进行分析和评估。 |
审批变更请求 | CCB对变更请求进行审批,决定是否将其纳入项目的变更控制流程中。审批过程可能包括讨论、投票和达成共识。 |
监督已批准的变更 | 一旦变更请求得到批准,CCB负责监督变更的实施过程,确保按照批准的计划和要求进行变更。 |
跟踪和报告变更 | CCB跟踪所有已批准的变更,并定期向相关人员报告变更的状态和结果。 |
风险管理 | CCB也需要评估变更可能带来的风险,并提出相应的控制措施,以最大程度地减少对项目的负面影响。 |
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
扫码关注腾讯云开发者
领取腾讯云代金券
Copyright © 2013 - 2025 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号:粤B2-20090059 深公网安备号 44030502008569
腾讯云计算(北京)有限责任公司 京ICP证150476号 | 京ICP备11018762号 | 京公网安备号11010802020287
Copyright © 2013 - 2025 Tencent Cloud.
All Rights Reserved. 腾讯云 版权所有