汉语国际网站建设,网站的营销推广方案及预算,微信开发平台官网,网站开发步骤说明书这是一篇关于怎么进行软件需求分析的文章#xff0c;读完的第一个感觉就是累。真的是特别累#xff0c;我大概估计了一下#xff0c;得有40000个字。不过读完之后还是有一点收获的。下面是一个大概的内容。 一.需求调研阶段 初识1.在客户组织的第一场见面会上#xff0c;保… 这是一篇关于怎么进行软件需求分析的文章读完的第一个感觉就是累。真的是特别累我大概估计了一下得有40000个字。不过读完之后还是有一点收获的。下面是一个大概的内容。 一.需求调研阶段 初识 1.在客户组织的第一场见面会上保持良好的态度不卑不亢。对需求进行深入的理解从而提出更加合理的方案建立良好的初期形象 2.对客户的用户角色进行详细的划分为解决多元化的问题做好准备“从高层领导着手提出规范化管理的口号。同时在进行需求调研时尽可能地召集各个单位的代表在一起开会讨论。同时应当有高层领导或者指定一个负责人在出现分歧的时候最终拍板决策。” 3.了解客户方领导的期望值建立双方达成共识的宏观目标。 拜访 1.也就是交友的部分与各个角色和各个类型的客户建立联系培养感情保持友好的关系 2.判定客户群体对于软件的看法团结能够因这个项目收益的人尊重与交好项目与他无关但是他可以给予你巨大帮助的人争取那些怀有敌意的人。 研讨会 1.有效的抑制个性化的差异 2.分模块进行专项的研讨会 3.通过对比发现不同公司的问题所在并且与客户交流从而得到一个相对统一的答案分散式研讨 4.创建经典案例,例如在一个部门先推行下去并且获取成功从而激励其他部门。 需求研讨怎样与客户讨论业务需求 1.客户会提出不正确的需求的情况 1.1对软件不了解提不出需求 1.2能提出需求但是当软件做出来的时候需求就发生了改变 1.3详细的提出需求甚至知道怎么实现但是会提出一些不切实际的要求或者我们会有更好的方案 2.同时还有的情况就是为了开发软件无限扩大学习领域的知识 3.用合理的方式去拒绝技术难以实现的或者根本无法实现的需求 3.1提出一个更好的的方案 3.2让对方意识到这是不可实现的 迭代 1.需求捕获 1.1记录下业务流程 1.2询问名词的含义 1.3记录软件希望的功能 1.4列出需求列表 2.需求整理 2.1通过用例模型划分整个系统的功能模块以及各个模块的业务流程之后细分流程直到需求已经非常清楚为止 2.2制作领域模型一般以对象图和类图的形式表达的对产品的领域进行更加深刻的理解。 3.需求验证 3.1应当对及时地与客户进行反馈确认我们的理解是否正确也就是需求验证工作 3.2需求验证工作应当贯穿整个研发周期并且在不同时期表现出不同的形式 3.3通过每开发完一个迭代周期将开发的成果与客户反馈。及时对产品进行修改和优化从而将修复问题的成本降到最低。 需求捕获 1.包括两种态度主动询问信息和被动的接受信息。其中被动的接受信息也就是单纯的记录用户所说的功能非常危险。 2.潜伏中的需求 2.1用户嘴中没有说出来的需求 2.1.1原因在他们看来已经是天经地义根本就不用说出来的业务规则 2.1.2解决办法在需求分析的整个过程不断进行业务领域知识的学习。 2.2客户压根儿就没有想到的需求。 2.2.1原因软件在最开始没有实体的时候客户很难想象开发出来的软件是什么样子。而在软件研发的后期客户能拿到那些研发成果的实物去操作可以看到。这时候很多他们起初没有想到的需求就会源源不断地被提出来。 2.2.2解决办法站在客户的角度去思考我们的软件应当设计成什么样子每个需求的真实意图是什么。站在这个基础上再运用专业知识去整理、分析与设计。 二.需求分析阶段 功能角色分析 1.采取用例图的方式来进行分析工作的细化 1.1参与者Actor 1.2用例Use Case 1.3系统边界Boundary。 2.绘制用例图的错误示范 2.1没有正确理解用例图的视角。没有站在用户的角度方面来考虑仅仅站在自己的角度来看问题 2.2图形绘制杂乱无章绘图不够清晰 2.3用例不是一个场景没有将一个案例真正放在事实上的案例上就会导致有考虑不周或者将问题想的太简单的问题。 3.补充 3.1必须要对用例进行进一步的文字描述。 3.2在每一个用例说明的后面与该用例相关的需求列表便于需求跟踪。 业务流程分析 1.通过流程分析抛开软件实现对一个流程进行梳理并且分析我们的软件能做什么事 2.明白软件系统的功能是为了提高客户的工作效率而避免加重他们的负担。 3.流程改进的意见 3.1清除低效环节 3.2简化业务瓶颈 3.3整合可用资源 3.4自动化繁重操作 查询报表分析 1.报表的目的通过一组一组的数据揭示的都是一些客观规律、复杂活动与发展趋势。 2.用户使用报表的频率常常决定了报表设计的方式。 3.一个报表的核心就是展现给客户的报表格式以及报表与报表间的各种链接。 业务领域分析 1.原文分析法 1.1对原文进行分析提取其中的名词判定其中的实体 1.2名词的多义性需要注意细致的措辞以防引起开发人员的误解 1.3对原文进行分析提取其中的动词 2.领域驱动设计 2.1建立双方都能理解的共同语言 非功能需求 1.可用性Usability:它泛指那些能让用户顺利使用系统的指标包括易用性易操作、易理解、准确性、安全性权限体系、访问限制、兼容性服务器、客户端的兼容度 2.可靠性Reliability:系统可以可靠运行包括系统成熟度数据吞吐量、并发用户量、连续不停机性能等、数据容错度、系统易恢复性等等。 3.性能Performance:在设计的时候就解决的问题 4.可支持性Supportability是维护系统的关键所在 5.其它 三.需求确认阶段 需求列表 1.需求列表不掺杂我们对业务需求的任何分析与设计这是需求列表的核心 2.需求列表应当是站在业务人员的视角对业务需求的简明扼要的描述。 快速原型法 1.利用快速开发出来的原型来与用户进行交流。从而获取用户对软件的看法。 ————————————————————————————————————————————————————— 四.之间的关系 原文链接请参考链接http://blog.csdn.net/yqmfly/article/details/7679781 转载于:https://www.cnblogs.com/tianxiayoujiu/p/8516920.html
