需求分概要

需求包括3个层次:业务需求,用户需求,开发需求

需求分析的一般流程:

1。业务人员以业务语言定义出初步文档,包括业务需求和用户需求

2。开发人员阅读需求文档并与业务人员充分沟通,消除二义性,明确边界,完善需求逻辑

3。开发人员从开发角度定义出开发需求,必要时定义配套的测试用例

敏捷开发提倡面对面的沟通来高效了解需求,使用用例卡片记录需求。我觉得需求分析首先要学好语文,一句简单的话可能并不简单,可能需要扩展分析,挖出背后隐藏的前提条件和分支路径,经反复确认最终获得正确和精确的需求。当需求不能当场确定时,需要特别标记TBD(To Be Determined),以引起重点关注,有秩序的进行下一步的分析和确定。

敏捷开发拥抱变化,即不怕需求变化多,因为它有应对的方法。方法就是用户的强参与和每日迭代,整个开发过程对用户是开放的,用户需要在场,每时每刻都有可以运行的软件供用户使用,用户的任何思想变动和开发的任何进展变动都能双向快速知晓,使花儿结成果实,果实尽快成熟。

需求也有非功能性的,可从开发质量和运行质量来分类,开发质量最重要的是可维护性和可测试性,运行质量最重要的是性能,以及可配置性,状态的可监视性,和安全性。

可维护性首先要求可读性,其次要求修改方便,扩展方便。实现方法是把可复用的和可能需要灵活变化的部分抽取出来,精益求精。

可测试性指功能被验证的方便程度,和Bug被测出的容易程度,获得性能数据的容易程度。常用的测试类型有单元测试(白盒),集成测试(黑盒),性能测试(在不同负载下的外部表现)。高标准的软件都需要测试代码对产品代码有100%的覆盖率。

可维护性和可测试性往往一致要求面向接口编程,敏捷开发也是测试驱动开发,先写测试逼着程序员面向接口编程,我希望我的新团队能采用这种方法。

性能的2个常用指标是吞吐量和响应时间,通常需要规定吞吐量的最低要求和响应时间的上限,对于开发需求,还有一个基准配置,即在什么样的硬件配置下达到这样的目标。

可配置性包括系统参数的修改和生效,模块的替换,策略的切换等。

状态的可监视性指获得系统输入和输出的能力,当前系统的负载数据,异常信息的记录和通知等。

安全性指不允许被公开的数据的完整性和私密性,常用的手段包括使用安全的传输协议,加密,以及签名等。

时间: 2024-08-06 12:44:46

需求分概要的相关文章

电子零售软件需求与概要分析小组分工

软件需求分工: 1.由陈仔祥.孟拓提出报告模板,设定8个任务 2.其余8位同学分别完成对应的8的任务 陈庚.崔祥岑完成前两个任务 汪力.刘校完成第3.4任务 郭澳林.肖宇完成第5.6任务 武清.胡圣阳完成第7.8任务 3.小组集体成员在最终审核制作出完整可行的软件需求报告 概要分析分工: 1.由孟拓.陈仔祥搜集相应资料.并制定模板.设定出8个任务 2.其余8位同学完成对应的八个任务 陈庚.崔祥岑完成前两个任务 汪力.刘校完成第3.4任务 郭澳林.肖宇完成第5.6任务 武清.胡圣阳完成第7.8任务

软件需求分、架构设计与建模最佳实践

软件需求分.架构设计与建模最佳实践 cxx 2019-04-13 一.为什么要详细设计,价值? 在多人团队环境中,详细设计驱动开发可实现明确交付的目标和标准 可复用的设计成果 提高代码的可维护性 可对交付进行工作量和质量的评估 实现知识传承,提高软件生命周期 二.控制软件复杂性的基本方法 分解法 抽象法 三.UML有哪些元素 结构 行为 四.基于用户目标的需求组织形式 交互式需求 清晰的责任 场景化 文档的五大功效 有助于编写使用手册 测试用例转化:帮助开发人员设计测试用例 需求用例 利于详细设

第四章,需求获取

这一章主要介绍了需求分功能的和解功能的需求两类,需求获取在软件开发的过程中也占据了非常重要的位置. 需求诱解是此过程中一个相当重要的部分,我们必须使用各程技术来确定是用户和顾客正想要什么.需求描绘系统行为,当系统作用于数据或指令上时,对象或实践从一种状态迁移到另一种状态.为了更好的描述需求,我们可以有两种方式考虑他们:功能的和解功能的.功能的需求遇到的问题都有独立于顾客问题解决方案实现的答案. 表达需求又分为动态描述和静态描述,静态描述的方式分为间接引用,递归关系,公共定理,数据对象:动态描述的

如何写好产品需求文档?

常常有人问我怎么写prd,在深受市面上流行的功能需求模板“残害”之后,我现在一般不会向别人推荐任何所谓的“模板”. 需求文档是产品需求的表达方式,而其中需要描述什么内容取决于产品经理想要描述什么,即产品经理的需求.如果产品经理的需求是明确的,而且产品经理脑中有物,那么需求文档自然而然就出来了.最可怕的是产品经理自己都不知道自己要描述的是什么内容,这个时候即使有模板,写出来的东西也是一团糟. 互联网产品以用户为中心,所以prd也应该站在用户的角度来描述,如果不知道自己要写什么,在写文档之前产品经理

20170926日关于需求调研的一些理解,

下面是关于调研需求与查询资料后的一些整理. (1)收集需求 需求来源:需求从哪里来? 内部:老板,同事(客服,运营,市场),产品经理自身策划,挖掘 外部:用户,客户,合作伙伴 挖掘方法:怎么去挖掘? 用户反馈 ,竞品分析,数据统计分析,头脑分析,定性定量采集,小组座谈会,深度访谈法,专家意见法,电话调查,面访调查,邮寄,用户访谈,测试结果 记录需求:怎么样可以更明显的记录下需求? (2)分析需求 分类别:功能类型,运营类型,数据类型,设计类型 后续计划:排期,留存,暂存,合并 (3)筛选需求 评

关于需求——软件需求工程

1.需求分哪几个层次,每个层次的含义 需求层次:业务需求,用户需求,功能需求   业务需求:     代表了需求链中的最高的抽象,它为软件系统定义了项目视图和范围,反映了企业/组织     对软件系统的最高层次目标要求     就是这个系统是做啥的,比如图书馆管理系统就是管理图书馆的,从大的方面指出   用户需求:     用户使用软件需要完成什么任务,怎么完成的需求,用户需求是需求捕获的产物     是零散的,存在矛盾的     就是这个系统能干啥,比如图书馆管理系统能借书,还书balabal

结构化方法和面向对象方法的比较

结构化方法和面向对象方法的比较 结构化方法 1概述        结构化方法(SD方法)是一种传统的软件开发方法,它是由结构化分析.结构化设计和结构化程序设计三部分有机组合而成的.它的基本思想:把一个复杂问题的求解过程分阶段进行,而且这种分解是自顶向下,逐层分解,使得每个阶段处理的问题都控制在人们容易理解和处理的范围内. 2基本思想 结构化方法的基本要点是:自顶向下.逐步求精.模块化设计.结构化编码. 结构化分析方法是以自顶向下,逐步求精为基点,以一系列经过实践的考验被认为是正确的原理和技术为支

如何做好单元测试

前言 单元测试是对软件基本组成单元进行的测试,是属于白盒测试的范畴,它主要通过对代码的逻辑结构进行分析来设计测试用例.在动态测试手段中,单元测试是一种非常高效的测试方法,并且是软件测试周期中第一个进行的测试.从成本角度考虑,缺陷发现越早越好,加强单元测试力度有利于降低缺陷定位和修复难度,从而降低缺陷解决成本,同时加强单元测试也减轻了后续集成测试和系统测试的负担.根据业界的统计,一个 BUG 在单元测试阶段发现花费是 1 的话,到集成测试就变为 10 ,到系统测试就高达 100 ,到实际推向市场量

20160408 从软件工程的3大文档开始说起

软件工程的三大文档可以说分3个阶段:需求,概要和详细. 一,需求分析文档 简单说来就是与客人沟通,把客人的业务需求整理成为文档. 需求分析文档中可以有用例描述,开发人员与用户充分沟通后,用用例图将客人的要求表达出来,而用例图能够使他们两者达成共识. 需求里面也需要放一些其他的东西,比如关于性能描述,非功能性要求等等 二,概要设计文档 我觉得这个是我现阶段作为一个常年工作在生产第一线的人反过来总结自己所做的项目的一个很好的表达方式.理由往下看吧... 首先概要设计的观看对象是 项目经理和客人,或者