需求怎么做软件测试人员必须清楚

需求怎么做软件测试人员必须清楚

　　对于软件开发团队而言，软件开发的是：做什么 -> 怎么做 -> 做 -> 成果检验 -> 交付部署;其中，“做什么”对应的是需求分析过程，“怎么做”对应于软件架构设计过程，“做”对应于开发过程，“成果检验”对应于测试，部署由运维团队执行后，如果达到用户的要求，则软件上线后进入软件的运行生命周期。

　　在实际的软件项目开发中，“做什么”，“怎么做”和“做”是紧密结合在一起的，“做”，“成果检验”和“交付部署”通常也会是一个持续交付过程，“成果检验”的内容会受到“做什么”的影响，开展“做什么”阶段的时候，也要考虑到如何部署和交付。所以软件开发的，都是紧密结合在一起的，如果刻意划分为独立的几个阶段，忽视其作为一个整理的综合影响，每个环节的实施过程必然会遇到因上一阶段考虑不周全带来的问题，从而影响整体开发效率。

　　基于此，我们的需求分析，从需求深度划分，可以分为三个层次：原始需求分析、业务架构分析和功能架构分析。这三个层次依次递进，没有严格的界限。

　　原始需求分析

　　原始需求是从用户或业务角度看到的，或应该有的需求，或项目团队经过初步挖掘后整理出来的、未经进一步提炼的需求。

　　如果拿做项目与做产品做个类比，原始需求有点类似与产品经理所说的“用户故事”，由于原始需求可能是开发者分析出来了，也可能是行业或目标客户 / 用户提出来的，原始需求可以不止步于“用户故事”，在该阶段做一定的业务逻辑的抽取和提炼，对接下来“业务架构”阶段的需求分析也是有帮助的，所以这两个阶段没必要确立一个严格的界限。

　　例如，对一个多人博客系统而言，原始需求可能是这样的：

　　要有个所有文章列表

　　能点击查阅文章

　　能评论文章

　　能创建新文章

　　能编辑删除文章

　　要有权限机制

　　而对于更有经验的人而言，原始需求可能更加体系化：

　　首先，多人博客系统由前台展示子系统和后台管理子系统构成，两个子系统的功能可以分别来描述。

　　前台子系统

　　前台子系统应该对任何人可见，该子系统至少包含以下页面或功能：

　　文章列表 + 概要页面

　　文章详情页面

　　作者主页

　　文章评论功能

　　文章搜索功能

　　侧边栏的目录、tag 等博客经典功能

　　后台子系统

　　后台子系统只对登录用户开放，对应多人博客而言，该子系统应该分用户组，为不同类型用户分配不同的权限，该子系统至少包含以下页面或功能：

　　用户登录或注册功能

　　根据不同用户的权限，登录后看到不同的页面或功能

　　创建新文章

　　修改或删除文章

　　维护博客名称描述等内容的功能

　　原始需求阶段做的，主要是需求是收集、整理和简单分析工作，为业务架构阶段的需求分析奠定了基础。

　　业务架构分析

　　业务架构阶段的需求分析，是对原始需求的抽象和再提炼，在形成业务架构之前，首先要梳理清楚功能需求和非功能需求，非功能需求是为接下来的功能架构及怎么做铺路的，本节暂不展开;功能需求又分为“显式的功能需求”和“潜在的功能需求”，如上一节列出的需求，均为显式功能需求，潜在的功能需求要从多个角度去考虑，如整理出用户组、权限对应的完整业务逻辑，是属于可以推测并进一步开展工作的潜在功能需求，而修改密码、个人信息、用户管理和忘记密码等功能，是上面漏掉的、但又会影响到系统完整性的潜在需求，而需要提供一个系统初始化接口的功能需求，是站在运维实施角度提出来的潜在需求。

　　当业务架构梳理过程中，尤其是整理潜在功能需求时，一定会发现上一阶段疏漏或在上一阶段的视角下考虑不到的需求点，此时应结合项目的进度要求，考虑是否进行一轮需求的迭代和补充。