唐磊的个人博客

软件需求

需求的基本概念

宽泛地讲,需求来源于用户的一些“需要”,这些“需要”被分析、确认后形成完整的文档,该文档详细地说明了产品“必须或应当”做什么。

“用户”(user)是一种泛称,它可细分为“客户”(customer)、“最终用户”(the end user)和“间接用户”(或称为关系人)。掏钱买软件的用户称为客户,而真正操作软件的用户叫最终用户。客户与最终用户可能是同一个人也可能不是同一个人。

需求工程——所有与需求直接相关的活动通称为需求工程。包括需求开发和需求管理。

需求开发的目的是通过调查与分析,获取用户需求并定义产品需求


需求调查的目的是通过各种途径获取用户的需求信息(原始材料),产生《用户需求说明书》。


需求分析的目的是对各种需求信息进行分析,消除错误,刻画细节等。常见的需求分析方法有“问答分析法”和“建模分析法”两类。


需求定义的目的是根据需求调查和需求分析的结果,进一步定义准确无误的产品需求,产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》开展系统设计工作。

需求管理的目的是在客户与开发方之间建立对需求的共同理解,维护需求与其它工作成果的一致性,并控制需求的变更。


需求确认是指开发方和客户共同对需求文档进行评审,双方对需求达成共识后作出书面承诺,使需求文档具有商业合同效果。


需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系,建立与维护“需求跟踪矩阵”,确保产品依据需求文档进行开发。


需求变更控制是指依据“变更申请-审批-更改-重新确认”的流程处理需求的变更,防止需求变更失去控制而导致项目发生混乱。

《用户需求说明书》与《产品需求规格说明书》的主要区别与联系


前者主要采用自然语言(和应用域术语)来表达用户需求,其内容相对于后者而言比较粗略,不够详细。


后者是前者的细化,更多地采用计算机语言和图形符号来刻画需求,产品需求是软件系统设计的直接依据。


两者之间可能并不存在一一影射关系,因为软件开发商会根据产品发展战略、企业当前状况适当地调整产品需求,例如用户需求可能被分配到软件的数个版本中。软件开发人员应当依据《产品需求规格说明书》来开发当前产品。

需求分析

分析方法大体有两类:“问答分析法”和“建模分析法”。后者技术性比较强,写出来有学术味,故大多数软件工程书籍都有论述。前者就是一些常识而已,虽然写不成文章,但是简单易用(保你一学就会),很有实用价值。


“问答分析法”比较适合于用户需求调查阶段


“建模分析法”比较适合于产品需求定义阶段


需求建模就是指用图形符号来表示、刻画需求。


建模分析方法主要有两大类:“结构化分析法”和“面向对象分析法”。

好的需求规格说明书

正确——正确地反映用户的真实意图,《产品需求规格说明书》最重要的属性


清楚——让人易读易懂


无二义性——每个需求只有唯一的含义


一致——“一致”(Consistent)是指《产品需求规格说明书》中各个需求之间不会发生矛盾


必要——《产品需求规格说明书》中的各项需求对用户而言应当都是必要的


完备——(Complete)是指《产品需求规格说明书》中没有遗漏一些必要的需求


可实现 ——《产品需求规格说明书》中的各项需求对开发方而言应当都是可实现的(Attainable)


可验证 ——《产品需求规格说明书》中的各项需求对用户方而言应当都是可验证的(Verifiable)


确定优先级


阐述“做什么”而不是“怎么做”——《产品需求规格说明书》的重点是阐述“做什么”,而不是阐述“怎么做”。“怎么做”是系统设计和实现阶段的事情

需求管理

需求确认(评审和承诺)——开发方和客户方共同对《产品需求规格说明书》进行评审,双方对需求达成共识后作出承诺。需求确认包含两个重要工作:“需求评审”和“需求承诺”

需求跟踪——目的是建立与维护“需求-设计-编程-测试”之间的一致性,确保所有的工作成果符合用户需求


正向跟踪。检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。


逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处

需求变更控制——提出需求变更目的是希望产品更加符合用户的需求。项目开发小组而言,变更需求意味着要调整资源、重新分配任务、修改前期工作成果等,开发小组要为此付出较重的代价

如果需求变更带来的好处大于坏处,那么允许变更,但必须按照已定义的变更规程执行,以免变更失去控制。 如果需求变更带来的坏处大于好处,那么拒绝变更。

tanglei wechat
欢迎扫描二维码关注我的微信公众号