51自学IT吧:专注于IT最前沿编程视频教程适合各个阶段的IT从业者

 找回密码
 立即注册
搜索
查看: 28|回复: 0

如何做好软件项目需求分析?

[复制链接]

21

主题

21

帖子

431

积分

学霸码农

Rank: 3Rank: 3

积分
431
发表于 2020-6-23 15:57:34 | 显示全部楼层 |阅读模式
对于软件开发团队而言,软件开发的全过程是:做什么 -> 怎么做 -> 做 -> 成果检验 -> 交付部署;其中,“做什么”对应的是需求分析过程,“怎么做”对应于软件架构设计过程,“做”对应于开发过程,“成果检验”对应于测试,部署由运维团队执行后,如果达到用户的要求,则软件上线后进入软件的运行生命周期。
在实际的软件项目开发中,“做什么”,“怎么做”和“做”是紧密结合在一起的,“做”,“成果检验”和“交付部署”通常也会是一个持续交付过程,“成果检验”的内容会受到“做什么”的影响,开展“做什么”阶段的时候,也要考虑到如何部署和交付。所以软件开发的全过程,都是紧密结合在一起的,如果刻意划分为独立的几个阶段,忽视其作为一个整理的综合影响,每个环节的实施过程必然会遇到因上一阶段考虑不周全带来的问题,从而影响整体开发效率。
基于此,我们的需求分析,从需求深度划分,可以分为三个层次:原始需求分析、业务架构分析和功能架构分析。这三个层次依次递进,没有严格的界限。
原始需求分析
原始需求是从用户或业务角度看到的,或应该有的需求,或项目团队经过初步挖掘后整理出来的、未经进一步提炼的需求。
如果拿做项目与做产品做个类比,原始需求有点类似与产品经理所说的“用户故事”,由于原始需求可能是开发者分析出来了,也可能是行业专家或目标客户 / 用户提出来的,原始需求可以不止步于“用户故事”,在该阶段做一定的业务逻辑的抽取和提炼,对接下来“业务架构”阶段的需求分析也是有帮助的,所以这两个阶段没必要确立一个严格的界限。
例如,对一个多人博客系统而言,原始需求可能是这样的:
而对于更有经验的人而言,原始需求可能更加体系化:
首先,多人博客系统由前台展示子系统和后台管理子系统构成,两个子系统的功能可以分别来描述。
前台子系统
前台子系统应该对任何人可见,该子系统至少包含以下页面或功能:
  • 文章列表 + 概要页面
  • 文章详情页面
  • 作者主页
  • 文章评论功能
  • 文章搜索功能
  • 侧边栏的目录、tag 等博客经典功能
后台子系统
后台子系统只对登录用户开放,对应多人博客而言,该子系统应该分用户组,为不同类型用户分配不同的权限,该子系统至少包含以下页面或功能:
  • 用户登录或注册功能
  • 根据不同用户的权限,登录后看到不同的页面或功能
  • 创建新文章
  • 修改或删除文章
  • 维护博客名称描述等内容的功能
原始需求阶段做的,主要是需求是收集、整理和简单分析工作,为业务架构阶段的需求分析奠定了基础。
业务架构分析
业务架构阶段的需求分析,是对原始需求的抽象和再提炼,在形成业务架构之前,首先要梳理清楚功能需求和非功能需求,非功能需求是为接下来的功能架构及怎么做铺路的,本节暂不展开;功能需求又分为“显式的功能需求”和“潜在的功能需求”,如上一节列出的需求,均为显式功能需求,潜在的功能需求要从多个角度去考虑,如整理出用户组、权限对应的完整业务逻辑,是属于可以推测并进一步开展工作的潜在功能需求,而修改密码、个人信息、用户管理和忘记密码等功能,是上面漏掉的、但又会影响到系统完整性的潜在需求,而需要提供一个系统初始化接口的功能需求,是站在运维实施角度提出来的潜在需求。
当业务架构梳理过程中,尤其是整理潜在功能需求时,一定会发现上一阶段疏漏或在上一阶段的视角下考虑不到的需求点,此时应结合项目的进度要求,考虑是否进行一轮需求的迭代和补充。
对上文提到的多人博客系统而言,业务架构可以设计如下:
多人博客系统业务架构
做好业务架构,是为整个软件项目迈出坚实的第一步。业务架构是需求分析中最重要的阶段,经历了整理业务架构分析的过程,基本上才真正把系统需求梳理出来了,如果简单粗暴的在需求和开发之间切出一个交接面,把交接面放在业务架构上是比较合适的,系统开发的底线是要与业务架构保持一致,后续的需求迭代或变更,也要基于业务架构扩展或重构。
业务架构对软件系统开发也有重要影响。开发软件系统,通常要求具备充分的可扩展性,而可扩展性,在需求分析阶段就奠定了基础,需求分析做的充分,就能在很大程度上给系统可扩展性定性了,当增加新功能时,系统能否扩展功能,还是系统的某些功能要打破重来,业务架构阶段就能看出端倪。比如,如果想在多人博客系统中增加用户的社交功能,可以把该功能插入到用户模块和个人模块中去,也可以单独开一个社交模块来封闭相关功能,前者会更多的打破原有业务逻辑,从而改变已有功能的代码实现,而后者更多的是在新的模块中梳理业务逻辑,开发新功能,前者重构多于扩展,而后者扩展多于重构。所以如果业务架构设计的具有足够的扩展性,相当于软件系统先天具备较强的可扩展性。
功能架构分析
业务架构为软件系统的开发奠定了基础,在实际的软件项目中,通常可以在此基础上让需求分析再往前迈一步,将"做什么"和“怎么做”是紧密联系起来,承上启下,我将这部分需求分析称之为“功能架构分析”。
为什么需求分析中要做功能架构分析?
定性的说,这一步工作也可以纳入“怎么做”的环节再开展,但我认为把它作为需求分析的最后阶段,对整个项目过程而言更有效率。这部分工作依然是围绕需求分析展开的,前文所述的需求分析工作通常开发者也会参与进去,所以业务架构分析和功能架构分析本来就是衔接在一起的连续过程,如果把这一步工作从需求分析中抛离,项目进行到怎么做或做的阶段时,发现现实(代码逻辑和系统实施)和理想(业务逻辑)不一致的概率会更大,开发过程中可能会有更多关于“需求分析没做到位”的扯皮,甚至不得不重新返回需求分析阶段再次梳理需求,这都会带来本可避免的项目进度延误。
所以,需求分析如果只考虑“原始需求”和“业务架构”两个维度,是有盲点的,功能架构分析虽然可以作为“怎么做”的第一步,但把它作为“做什么”的最后一步,能有效减少因为没有“向后看”带来的需求分析不充分的问题,能够把需求和实现更紧密的结合在一起,它在一定程度上对业务架构做了进一步的细化,也在一定程度上影响了业务架构的最终成果。
功能架构分析怎么做?
功能架构不必刻意设计的与业务架构不同,但功能架构分析的关注点已经是为怎么做和做这两个阶段铺路了,是怎么做的基础,“怎么做”是架构师负责的,功能架构分析最好也由需要架构师来牵头和落实。
合理并且有效地运用项目管理软件,不仅可以让我们工作井然有序地进行,还能最大程度保证项目目标的达成。我推荐使用CORNERSTONE提供了包括任务/需求/测试管理、迭代规划、缺陷追踪、报表统计、团队协作、WIKI、共享文件和日历等功能模块,现在申请20人以下团队即可免费使用。

回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

在线支持
在线咨询
咨询热线
522174229@qq.com

QQ|Archiver|手机版|小黑屋|51自学IT吧  

GMT+8, 2020-7-9 10:15 , Processed in 0.084875 second(s), 24 queries .

© 2014-2017 51自学it吧论坛

快速回复 返回顶部 返回列表