软件要求
系统的软件要求是对系统应执行的操作,其提供的服务或服务的描述以及其操作的约束。软件工程术语的IEEE标准词汇表将要求定义为:
- 用户需要解决问题或实现目标所需的条件或能力
- 系统或系统组件必须满足或拥有的条件或能力,以满足合同,标准,规格或其他正式强加的文件
- 如1或2中的条件或能力的记录的表示形式
与软件需求有关的活动可以大致分解为启发,分析,规范和管理。
请注意,在软件发行说明中还使用了措辞软件的要求进行解释,这取决于软件包需要构建/安装/使用的某些软件。
启发
启发是利益相关者和其他来源的收集和发现。可以使用各种技术,例如联合应用设计(JAD)会话,访谈,文档分析,焦点小组等。启发是需求开发的第一步。
分析
分析是启发引起的逻辑分解。分析涉及以多种互补的方式对每种要求达成更丰富,更精确的理解,并代表一组需求。
要求分类或要求的优先级是经常遵循分析的另一项活动。这与计划阶段的敏捷软件开发有关,例如通过规划扑克,但是根据项目,需求的上下文和性质或正在构建的产品/服务的性质,它可能与其相同。
规格
规范涉及以持续且组织良好的方式代表和存储收集的需求知识,以促进有效的沟通和变更管理。用例,用户故事,功能需求和视觉分析模型是需求规范的流行选择。
验证
验证涉及技术以确认已指定正确的要求集以构建满足项目业务目标的解决方案。
管理
项目期间的需求发生变化,并且通常有很多。这种更改的管理对于确保为利益相关者构建正确的软件至关重要。
需求工程的工具支持
需求的工具启发,分析和验证
考虑到这些活动可能涉及一些文物,例如观察报告(用户观察),问卷(访谈,调查和民意调查),用例,用户故事;诸如需求研讨会( Charrettes ),集思广益,思维映射,角色扮演等活动;甚至是原型的;提供某些或全部这些功能的软件产品可用于帮助完成这些任务。
至少有一位作者明确地提倡诸如Freemind之类的思维映射工具。另外,用于通过示例工具(例如和解)使用规范。此外,可以通过Wiki和其他协作工具(例如Trello)收集和组织这些活动所产生的思想和陈述。这些功能实际实现,标准符合性因产品而异。
要求规格的工具
软件需求规范(SRS)文档可以使用通用软件(如文字处理器或几个专用工具之一)创建。其中一些工具可以导入,编辑,导出和发布SRS文档。遵循标准化的结构和方法,例如ISO/IEC/IEEE 29148:2018,可以帮助制作SRS文档。同样,软件可能会或不使用某些标准来导入或导出要求(例如REQIF ),或者根本不允许这些交换。
需求工具文档验证
此类工具根据某些预期结构或标准验证需求文档中是否存在任何错误。
要求比较工具
这种工具根据一些预期的文档结构和标准比较两个要求集。
需求工具合并和更新
这种工具允许合并和更新要求文档。
需求的工具可追溯性
这种工具可以将需求追踪到其他工件,例如模型和源代码(正向可追溯性),或者,诸如业务规则和约束(向后的可追溯性)之类的工具。
基于模型的软件或系统要求工程工程
基于模型的系统工程(MBSE)是建模的正式应用,以支持系统需求,设计,分析,验证和验证活动,从概念设计阶段开始,并在整个开发过程中及其后来的生命周期阶段继续进行。也可以采用基于模型的方法来进行需求工程的某些阶段,而对于其他工程的方法,也可以采用更传统的方法。可能会有很多组合。
形式和复杂性的水平取决于所涉及的基本方法(例如, I*比SYSML更正式,甚至比UML更正式)
一般需求工程工程
此类别中的工具可以提供前面提到的功能的一些组合以及其他要求配置管理和协作等其他功能。这些功能实际实施,标准符合性因产品而异。
有更多的能力或一般工具可以支持其他阶段和活动。它们被归类为ALM工具。