6-需求获取 软件工程案例分析课件

1、软件工程案例分析Jin BoCollege of Computer Science and TechnologyZhejiang University构架需求分配系 统 需 求宽带接入（交换式以太网构造 ）身份认证，计费策略，网络安全，访问监测，接入服务，用户管理分配给硬件的需求交换机，PPPoE接入，访问控制设备，认证与安全服务器，网络构架，流量控制分配给软件的需求端口隔离,用户信息（ID-Addr-Mac-IP）,身份认证（ID-Passwd）,访问信息（IP-Sock-Time-Len），流量，接入软 件 需 求软件应能：通过目录服务进行用户管理，实现PPPoE接入与管理，具有安全包过滤

2、，提供DHCP分配，营帐，实时策略宽带接入控制系统适合于宽带网络环境（交换式以太网构造）用于用户接入网络的访问控制，包括：用户身份认证网络接入服务（DHCP、DNS、ARP）不合法用户和访问监测与控制网络安全体系支撑多样化计费策略支持（按时、预付费）用户基本信息管理（ID、Pswd、MAC）硬件技术需求分析交换机交换机AC用户用户用户用户管理机制用户端口隔离用户基本信息（ID-Addr-Mac-IP）用户身份认证（ID-Password）用户访问信息（IP-Sock-Time-Len）IDIPAddrMacTimeSock体系构架总部区域城市社区收费管理用户信息用户接入服务系统社区网络管理系统

3、用户信息用户信息客户服务收费管理计费管理开户交费投诉上网欠费补交销户计费管理计费管理客户服务网络管理网络管理网络管理收费管理平台支撑总部区域和城市汇聚和社区客户管理系统计费管理系统流量监测系统网络管理系统接入控制系统ERP系统的协作关系计费管理系统客户管理系统接入控制系统网络管理系统流量监测系统账单收费计时用户流量监测开关主要功能用户认证及其管理（首次认证）接入服务（DHCP、MAC-IP捆绑，ID-Sock）不合法用户和访问操作的监测与控制多样化计费操作和管理按时间计费（以后扩展按流量、带宽计费）预付费或记账式计费支持全网漫游与客服管理系统、公安安全监测系统接口部署结构城市中心AC Back

4、upAC汇聚点4000or 2000AC汇聚点4000or 2000社区接入网社区接入网社区接入网社区接入网环境与要求基于Web的构架认证Windows ClientUnix Server响应时间用户分类需求开发中的关键用户及其分类各种用户对系统具用不同要求，没有经验用户是否简单易用高级用户产品易用性和高效需要对用户分类，每一用户类有自己一系列功能和非功能要求在项目中，要尽早为产品确定并描述不同的用户类，这样就能从每一个重要的用户类代表中获取不同需求。用户“用户”（user）是泛称“客户”（customer）、“最终用户”（the end user）和“间接用户”（关系人）。掏钱买软件的用户称

5、为客户，而真正操作软件的用户叫最终用户。客户与最终用户可能是同一个人也可能不是同一个人。客户是掏钱买软件的人，所以他是“上帝” “先有鸡还是先有蛋”哲学如果顾客先点鸡，那么就先有鸡；如果顾客先点蛋，那么就先有蛋。“现代营销学之父”菲利普科特勒客户永远是本公司的座上客。客户并不依赖我们，而我们却依赖客户。客户不是我们工作的障碍，而是我们工作的目标。与客户打交道的主要目的是：一是获取需求，二是签合同。用户(续)即使最终用户不是上帝，也算是“上帝”的“亲戚”，同样怠慢不得。项目规模大，开发方与最终用户来往多。从最终用户获取详细需求，请最终用户试验软件，对最终用户进行培训等。重视“间接用户”，千万别“

6、大意失荆州” 间接用户既不掏钱买该软件产品，也不使用该软件，但是它可能对软件产品有很大影响。财务软件开发商在把“财务软件”卖给客户之前，这个“财务软件”必须得到国家财政部的批准。市面上流通的信息安全软件、杀病毒软件必须得到国家公安部的批准，否则 “非法经营”。 寻找用户代表寻找用户代表每一个用户类必须有一名和几名用户代表参与软件开发项目周期对于直接面向客户的项目，用户代表相对容易找到，对于商品化软件,用户代表（产品代表）比较难找到。产品代表必须是真正用户，而不是用户代理人，如主办者，产品客户，市场人员必须给产品代表足够尊重，否则将挫伤他们积极性产品代表者如何寻求产品代表者？与大公司建立联系通过

7、产品打折或者免费使用方式来吸引产品代表者要注意技术泄漏问题真正聘请具有丰富经验的合适产品代表者“谁说了算”“谁说了算？”问题同一用户类：个别用户需求不一致，由产品代表者作出决策。（实质是授权给产品代表者，由其解决用户类需求冲突）不同用户类：不同用户类意见不一致，决策哪一类用户需求更重要。了解产品类信息和业务目标，决定哪一用户类所占份额最大“谁说了算”不同公司客户：要求产品按照自己的喜好设计。运用项目业务目标决定最有价值客户。非核心客户的需求可以安排在下一个版本开发。客户经理与真正用户需求相冲突。用户需求必须与业务需求一致，说服客户经理服从产品代表者的用户需求和功能性规格说明。开发者构想产品与客

8、户需求冲突，由客户作出决策，但不要陷入“客户总是对的”的陷阱中去，现实中，客户并不总是对的。某出版社系统调查表编号提出问题1您在哪个部门工作？2出版业务流程是什么？3您每日都处理那些文件、数据、报表？4工作中手工处理特别麻烦的事情是什么？5工作中手工处理什么问题解决不了？影响效率的问题有哪些？6您认为提高工作效率，节省工作时间，减轻工作强度可采取哪些办法？某出版社系统调查表编号提出问题7您的部门需要成本核算和统计的内容有哪些？8您的部门采用计算机管理工作情况如何？9如何改进业务流程使之更合理？10哪些问题是目前传统手工方法根本无法解决的？11出版社计算机管理信息系统需要解决什么问题？“谁说了算

9、”市场部门提出需求与开发者构想系统发生冲突，由市场人员作为客户代理人，市场需求具有更重的分量，防止市场人员一味地迁就客户需求。没有简单的正确答案需求获取的常用方法建立分析小组 领域专家： 主角 系统分析员：导演客户访谈问题分析与确认 聆听客户的需求：访谈要点：事先需调查涉众或用户以及公司的背景。访谈前对问题进行复审。在访谈期间要参照一定的格式，以确保提出正确的问题。在访谈结束时总结两、三个最为重要的问题。重复您听到的内容，以确认您的理解是否正确。聆听客户的需求：访谈寻求客户客户是谁？ 用户是谁？ 他们的需要是否不同？ 他们具有什么背景、能力和环境？业务流程 问题是什么？想要解决该问题的原因是什

10、么？ 是否存在其他想要解决该问题的原因？ 成功解决方案的价值是什么？ 现在您如何解决问题？时间和价值之间如何折衷？在其他什么地方可以找到此问题的解决方案？ 举例（宽带运营平台）网络中心、信息中心、各级运营商网络管理员、操作员、上网用户不同，费用、安全、方便竞争环境、能力运营最少运营费用获得最大客户扩大竞争优势系统分割分期实施还是技术解决方案论证聆听客户的需求：访谈产品特点该产品解决什么问题？该产品会引起什么业务问题？对于用户来说，存在着什么危险？产品将处于什么环境？您对可用性有什么期望？您对可靠性有什么期望？需要何种性能/精度？举例高效运营计费模式，营帐模式，接入模式，管理变革，利润分配模式服

11、务质量的风险，会失去客户在线全流程服务7*24高可靠性很重要可以实时记录流量，计算费用，控制访问，灵活出帐，最小单位到3秒聆听客户的需求：访谈通用问题我是否提问了太多问题？ 我的问题是否与主题相关？您是回答这些问题的合适人选吗？ 您的答案是必需的吗？稍后我可以提出更多问题吗？您愿意参加需求复审吗？还有其他应该向您提出的问题吗？聆听客户的需求：访谈注意：不要让对方说明他们不经常说明的事情。 不要提出假设用户可以说明复杂活动的问题。一般来说，人们能做许多自己无法说明的事情。 经验主义的根据 - 缺少相关性。 提出可以自由回答的问题。 回避以“为什么”开头的问题，因为这类问题会让对方采取防范的态度。

12、 进行访谈对话时，要记住： 不要期望获得简单的答案。 不要只求得到对方的回答而匆忙草率地进行访谈。 倾听，倾听，再倾听！聆听客户的需求：研讨班研讨班研讨班开始前协调员需要邀请应该参加研讨班的涉众，从而确定参加研讨班的小组。应该向参加者提供“热身”材料，供他们在到会之前阅读。协调员负责研讨班的后勤工作，比如发出邀请、申请带有会议所需设备的适当会议室，以及分发研讨班议程等。聆听客户的需求：研讨班召开会议协调员主持会议，包括：给每个人发言机会。确保会议不脱离正题。收集关于适用的需求属性的意见记录调查结果。总结会议并得出结论。 整理结果需求研讨班结束后，协调员与系统分析员需要花些时间对调查结果进行综合

13、，并将信息精简为可介绍形式。聆听客户的需求：调查终止如何知道你已经完成了需求获取？用户不能想出更多需求用户提出新的需求，但可以从其它需求的相关功能需求重获得这些新需求用户开始重复原先讨论过的问题用户提出对将来产品的要求，而不是现在讨论的特定产品编写需求文档需求文档要求完整性一致性可修改性可跟踪性软件需求规格说明软件需求规格说明的作用客户和营销部门依赖它了解他们所能提供的产品项目经理根据包含在软件需求规格说明中描述的产品来制定规划并预测进度安排、工作量和资源软件开发小组依赖它来理解他们将要开发的产品测试小组利用它来制定测试计划，测试案例软件维护人员和支持人员依据它了解系统的功能产品发布组根据它编

14、写客户文档，包括用户手册和帮助培训人员根据它编写培训教材什么是好的需求规格说明书正确 正确地反映用户真实意图。开发者和用户自己都不明白用户究竟“想要什么”和“不要什么”。双方确认需求规格说明书。清楚 采用反问方式来判断需求文档是否清楚文档结构、段落是否乱七八糟？上下文是否不连贯？ 文档语句是否含糊其词、罗里罗嗦？ 看了半天是否还不明白需求究竟是什么？ 无二义性 每个需求只有唯一含义。措词准确，切勿模棱两可。 什么是好的需求规格说明书一致 各个需求之间不会发生矛盾。矛盾常常潜伏在需求文档的上下文中。 必要 各项需求对用户而言应当都是必要的。“雪中送炭”，不能 “画蛇添足”“锦上添花”是好事，但不

15、会多付钱。集中精力先完成必要需求，条件允许再“锦上添花”“锦上添花”需求设置为较低优先级。 完备 没有遗漏必要需求。不能关注特色，忽视必需功能。 什么是好的需求规格说明书可实现 各项需求对开发方而言应当都是可实现的（Attainable）。“可实现”：技术上可行，满足时间、费用、质量约束。营销人员对用户提出的需求“来者不拒”。但是产品需求规格说明书相当于商业合同。对于合同项目，如开发方不能确信某些需求是否可实现，则应事先与用户协商，达成一致处理意见。可验证 各项需求对用户方而言应当都是可验证的（Verifiable）。摩天大楼的一项需求是“抗十二级台风”.如何验证？ 什么是好的需求规格说明书确

16、定优先级 原因是：项目存在“进度、费用、人力资源”限制。“取舍”法：先做优先级高的需求，后做（甚至放弃）优先级低的需求，这样可以将风险降到最低。 阐述“做什么”而不是“怎么做” 重点是阐述“做什么”，而不是“怎么做”。“怎么做”是系统设计和实现阶段的事情。 开发人员身兼数职，可能把需求开发、系统设计、编程等工作从头做到尾。关键是不要将“怎么做”写到需求规格说明书里面，记录在其它文档里就行了。 软件需求规格说明文档可读性对节、小节和单个需求的号码编排必须一致在右边部分留下文本注释区允许不加限制地使用空格正确使用各种可视化强调标志创建目录表和索引表有助于读者寻找所需信息对所有图和表制定号码和标识号

17、软件需求规格说明需求的标识序列号，如UR-2,SRS13层次化编码，如层次化文本标签，“当用户请求打印超过10个副本时，系统必须让用户进行确认判断。” 不完整的需求进行特殊的标识TBD(to be determined)，在继续进行构造需求集合之前，必须处理完所有TBD用户界面与软件需求说明用户界面是解决方案，而不是需求，但是可以更清楚的定义需求。可以画一些草图软件需求规格说明a 引言目的文档约定预期的读者和阅读建议产品的范围参考文献b.综合描述产品的前景产品的功能软件需求规格说明用户类和特征运行环境设计和实现上的限制假设和依赖C.外部接口需求用户界面硬件接口软件接口通信接口软件需求规格说明D

18、.系统特性说明和优先级激励、响应序列功能需求其它非功能需求性能需求安全设施需求软件安全性需求软件质量属性业务规则用户文档其它需求附录A:词汇表附录B:分析模型附录C:待确定问题的类标软件需求规格说明的注意事项需求说明语句保持语句和段落的简短采用主动语态的表达方式编写具有正确的语法和标点的完整句子使用的术语应该和词汇表中定义的一致需求陈述应该具有一致的式样“系统必须”，或者“用户必须”紧跟一个行为动作和可观察的结果“仓库管理子系统必须现实一张在所请求的仓库中有存货的药品名单。”软件需求规格说明的注意事项减少不确定性，避免采用模糊、主观术语“用户友好、容易、简单、迅速、有效、支持、许多、最新技术、优越的、可接受和健壮。”避免使用比较性词汇“提高，最大化，最小化和最佳化。”定量说明所需提高的程度或说清一些参数可接受的最大值和最小值。“系统处理能力，其处理发票扫描与识别的速度为的150”需求表达“产品必须在固定的时间间隔内提供状态消息，并且每次时间间隔不得小于60秒”后台任务管理器应该在用户界面的指定区域显示状态消息在后台任务进程启动之后，消息必须每隔60（+_10）秒更新一次，并且保持连续的可见性。如果正在正常处理后台任务进程，那么后台任务管理器必须显示后台任务进程已完成的百分比