第4讲工程立项、可行性分析与需求获取.ppt

2019年12月28日12时25分 王少华武汉大学国际软件学院空间信息与数字工程研究中心huazimail 工程立项 可行性分析与需求获取 2006年9月28日6时52分 结构化分析设计过程 2006年9月28日6时52分 结构分析设计过程 2006年9月28日6时52分 本质上是功能分解 以实现功能的过程为中心 而用户的需求变化主要是针对功能的 这就使基于过程的设计不易被理解 且功能变化往往引起结构变化较大 稳定性不好 系统有明确的边界定义 且系统结构依赖于系统边界的定义 这样的系统不易扩充和修改 数据与操作分开处理 可能造成软构件对具体应用环境的依赖 可重用性 reusability 较差 结构化技术的缺点 2006年9月28日6时52分 管理的范围 有效的项目管理集中于三个P上 人员 people 问题 problem 和过程 process 其顺序不是任意的 任何管理者如果忘记了软件工程是人的智力密集的劳动 他就永远不可能在项目管理上得到成功 任何管理者如果在项目开发早期没有支持有效的用户通信 他有可能为错误的问题建造一个不错的解决方案 最后 对过程不在意的管理者可能冒把有效的技术方法和工具插入到真空中的风险 2006年9月28日6时52分 一 工程立项建议 1 立项原因2 立项基础3 国内外研究现状4 工程意义与目标5 用户调查6 投资条件7 投资周期8 技术力量与基础9 软件硬件价格与性能10 数据源状况11 应用前景12 效益评估13 可运行性评价 2006年9月28日6时52分 问题定义 问题定义阶段必须回答的关键问题是 要解决的问题是什么 问题定义阶段的工作 系统分析员应该提出关于问题性质 工程目标和规模的书面报告 问题定义阶段是生命周期中最简短的阶段 一般只需要一天甚至更少的时间 2006年9月28日6时52分 二 可行性研究 这个阶段要回答的关键问题是 对于上一个阶段所确定的问题有可行的解决办法或值得做吗 可行性研究比较简短 这个阶段的任务不是具体解决问题 而是研究问题的范围 探索这个问题是否值得去解 是否有可行的解决办法 做还是不做 联想集团领导人柳传志曾说 没钱赚的事我们不干 有钱赚但投不起钱的事不干 有钱赚也投得起钱但没有可靠的人选 这样的事也不干 柳传志为决策立了上述准则 同时也为可以行性分析指明了重点 2006年9月28日6时52分 2 1可行性研究的任务 可行性研究的目的就是用最小的代价在尽可能短的时间内确定问题是否能够解决 可行性研究的目的不是解决问题 而是确定问题是否值得去解 以及关键技术 难点 能否解决 必须分析几种主要的可能解法的利弊 从而判断原定的系统目标和规模是否现实 系统完成后所能带来的效益是否大到值得投资开发这个系统的程度 一般说来 可行性研究的成本只是预期的工程总成本的5 10 软件领域的可行性分析主要考虑四个要素 经济 技术 社会环境和人 项目的意义 社会的意义 技术可行性经济可行性操作可行性 2006年9月28日6时52分 3 1 1可行性研究的任务 可行性分析的四个任务 2006年9月28日6时52分 2 2可行性研究的步骤 1系统定义 复查系统规模和目标 性质 范围 约束和限制2研究目前正在使用的系统 研究现行系统 人工 旧软件 描绘系统流程图 审核 现有的系统必然有某些缺点 新系统必须能解决旧系统中存在的问题 3 导出新系统的逻辑模型 分析员应该画出描绘现有系统的高层系统流程图 并请有关人员检验他对现有系统认识是否正确 千万不要花费太多时间去了解和描绘现有系统的实现细节 例如 除非是为了阐明一个特别关键的算法 否则不需要根据程序代码画出程序流程图 2006年9月28日6时52分 2 3导出新系统的高层逻辑模型 4 设计方案 优秀的设计过程通常总是从现有的物理系统出发 导出现有系统的逻辑模型 再参考现有系统的逻辑模型 设想目标系统的逻辑模型 最后根据目标系统的逻辑模型建造新的物理系统 并进行可行性评价 4方面 分析员能够使用数据流图描绘数据在系统中流动和处理的情况 从中概括地表达出他对新系统的设想 通常为了把新系统描绘得更清晰准确 还应该有一个初步的数据字典 定义系统中使用的数据 数据流图和数据字典共同定义了新系统的逻辑模型 以后可以从这个逻辑模型出发设计新系统 2006年9月28日6时52分 2 4重新定义问题 分析员应该和用户一起再次复查问题定义 工程规模和目标 这次复查应该把数据流图和数据字典作为讨论的基础 可行性研究的前四个步骤实质上构成一个循环 分析定义问题 分析这个问题 导出一个试探性的解 在此基础上再次定义问题 再一次分析这个问题 修改这个解 继续这个循环过程 直到提出的逻辑模型完全符合系统目标 2006年9月28日6时52分 2 5导出和评价供选择的解法 5 推荐可行的方案 分析员应该从他建议的系统逻辑模型出发 导出若干个较高层次的 较抽象的 物理解法供比较和选择 其次可以考虑操作方面的可行性 考虑经济方面的可行性 对每个可能的系统进行成本 效益分析 最后为每个在技术 操作和经济等方面都可行的系统制定实现进度表 不需要 也不可能 制定得很详细 通常中需要估计生命周期每个阶段的工作量 2006年9月28日6时52分 2 5 1经济可行性 经济经济可行性分析主要包括 成本 收益 分析和 短期 长远利益 分析 成本 收益分析最容易理解 如果成本高于收益则表明亏损了 如果成本大大高于收益那就亏大了 2006年9月28日6时52分 2 6成本 效益分析 直接效益服务节省开支提高工作效率间接效益科学决策快速决策社会效益 2006年9月28日6时52分 2 6 1成本考虑的方面 1 办公室房租 2 办公用品 如桌 椅 书柜 照明电器 空调等 3 计算机 打印机 网络等硬件设备 4 电话 传真等通讯设备以及通讯费用 5 资料费 6 办公消耗 如水电费 打印复印费等 7 软件开发人员与行政人员的工资 8 购买系统软件的费用 如买操作系统 数据库 软件开发工具等 有些老板买盗版的系统软件 却按市场价算成本 可从美国佬那里赚一笔 9 做市场调查 可行性分析 需求分析的交际费用 10 公司人员培训费用 11 产品宣传费用 如果用Internet作宣传 则要考虑建设Web站点的费用 12 如果客户是政府部门 还要充分考虑用于吃喝玩乐 行贿的费用 13 如果公司的风水不好 会有很多莫名其妙的管理费 每戳一个红艳艳的公章都要化一把钞票 2006年9月28日6时52分 2 6 2短期 长远利益分析 人们喜欢吃着碗里的 看着锅里的 还想着别人家里的 短期利益和长远利益兼得是人们梦寐以求的事 开发策略 2006年9月28日6时52分 2 6 3成本估计 系统规模 1 代码行技术 面向规模的估计 代码行KLOC 每千行代码 KLOC 的错误数 每千行代码 KLOC 的缺陷数 每行代码 LOC 的成本 每千行代码 KLOC 的文档页数 每人月错误数 每人月代码行 LOC 每页文档的成本 2 任务分解技术 面向功能的估计 功能点 用户输入数 计算每个用户输入 它们向软件提供面向应用的数据 输入应该与查询区分开来 分别计算 用户输出数 计算每个用户输出 它们向用户提供面向应用的信息 这里 输出是指报表 屏幕 出错信息 等等 一个报表中的单个数据项不单独计算 用户查询数 一个查询被定义为一次联机输入 它导致软件以联机输出的方式产生实时的响应 每一个不同的查询都要计算 文件数 计算每个逻辑的主文件 如数据的一个逻辑组合 它可能是某个大型数据库的一部分或是一个独立的文件 外部接口数 计算所有机器可读的接口 如磁带或磁盘上的数据文件 利用这些接口可以将信息从一个系统传送到另一个系统 2006年9月28日6时52分 2 6 3问题分解及过程分解 首先把软件开发工程分解为若干个相对独立的任务 估计每个任务的成本时 通常先估计完成该任务需要用的人力 以人月为单位 再乘以每人每月的平均工资而得出每个任务的成本 最常用的办法是按开发阶段划分任务 如果软件系统很复杂 由若干个子系统组成 则可以把每个子系统再按开发阶段进一步划分成更小的任务 典型环境下各个开发阶段需要使用的人力的百分比大致如表所示 2006年9月28日6时52分 2006年9月28日6时52分 软件规模的例子 2006年9月28日6时52分 3 自动估计成本技术采用这种技术必须有长期搜集的大量历史数据为基础 并且需要有良好的数据库支持 2006年9月28日6时52分 参考书籍 软件成本估算 COCOMOII模型方法出版社 机械工业出版社作者 美 勃姆 Boehm B W 等 译者 李师贤 杜云梅 李卫华等 功能点分析 成功软件项目的测量实践作者 美 DavidGarmus DavidHerron 出版社 清华大学出版社 2006年9月28日6时52分 功能点分析法 功能点分析法 FPA functionpointanalysis 是在需求分析阶段基于系统功能的一种规模估算方法 是基于应用软件的外部 内部特性以及软件性能的一种间接的规模测量 功能点可以用于 需求文档 设计文档 源代码 测试用例 度量 根据具体方法和编程语言的不同 功能点可以转换为代码行 2006年9月28日6时52分 功能点分析法的步骤 2006年9月28日6时52分 功能点分析法 FP 总计数值 0 65 0 01 Fi 其中 总计数值 是所有功能点条目的总和 Fi i 1到14 是基于对图4 6中问题的回答而得到的 复杂度调整值 0到5 等式中的常数和信息域值的加权因子是根据经验确定的 Fi 1 系统需要可靠的备份和复原吗 2 需要数据通信吗 3 有分布处理功能吗 4 性能很关键吗 5 系统是否在一个已有的 很实用的操作环境中运行 6 系统需要联机数据项吗 7 联机数据项是否需要在多屏幕或多操作之间切换以完成输入 8 需要联机更新主文件吗 9 输入 输出 文件或查询很复杂吗 10 内部处理复杂吗 11 代码需要被设计成是可复用的吗 12 设计中需要包括转换及安装吗 13 系统的设计支持不同组织的多次安装吗 14 应用的设计方便用户修改和使用吗 2006年9月28日6时52分 总计数值 2006年9月28日6时52分 估算14个复杂度加权因子 Fi 根据问题对项目的影响取值范围是0 5 表3给出了因子值 FP 总计数值 0 65 0 01 Fi 366 2006年9月28日6时52分 工作量估算 2006年9月28日6时52分 工作量估算 2006年9月28日6时52分 工作量估算 用java2完成上述项目 366功能点 时 将大约需要下列SLOC数 L 366 46 16836行 16 836KLOCE 5 2 L0 91 5 2 16 3860 91 66人 月DOC 49 L1 01 49 16 3861 01 826页 2006年9月28日6时52分 成本估算 项目的成本估算包括许多因素 人力成本 办公费用 管理费用 设备和软件等的购置费用 场地租金 旅差费等等 对项目成本的估算取决于公司所采用的成本核算方法 有的公司某些费用并没有计入项目成本中 而是按管理费用等分摊 有的从历史数据求出生产率度量和每行成本 即行 PM 人月 和元 行 则LOC的值与元 行相乘得到成本 用LOC的值与行 PM相除得到工作量 具体可按公司的具体情况选择 2006年9月28日6时52分 成本估算 E 5 2 L0 91 L是源代码行数 以KLOC计 E是工作量 以PM计 D 4 1 L0 36 D是项目持续时间 以月计 S 0 54 E0 6 S是人员需要量 以人计 DOC 49 L1 01 DOC是文档数量 以页计 2006年9月28日6时52分 制定计划 对软件项目进行估算的第三步是根据工作量制定项目计划 目的是用文件的形式 把对于在开发过程中人员安排 工作量分解 开始和完成时间 开发进度 所需经费预算 所需软 硬件条件等问题作出的安排记载下来 以便根据本计划开展和检查本项目的开发工作 可以根据自己的历史数据或行业模型决定所需的资源并落实到项目计划 可以采用上述的IBM模型或McConnell给出的方法粗略地给出项目持续时间 以IBM模型为例 项目需要的人员S 0 54 E0 6 0 54 660 6 7人项目持续时间D 4 1 L0 36 4 1 16 3860 36 11月 2006年9月28日6时52分 成本 效益分析的方法 成本 效益分析的第一步是估计开发成本 运行费用和新系统将带来的经济效益 应该比较新系统的开发成本和经济效益 以便从经济角度判断这个系统是否值得投资 投资是现在进行的 效益是将来获得的 不能简单地比较成本和效益 应该考虑货币的时间价值 2006年9月28日6时52分 贷币的时间价值 假设年利率为i 如果现在存入P元 则n年以后可以得到的钱数为 F P 1 i n就是P元钱在n年后的价值 反之 如果n年后能收入F元线 那么这些钱的现在价值是 P F 1 i n修改一个已有库存清单系统 使它能在每天送给采购员一份定货报表 修改已有的库存清单程序并且编写产生报表的程序 估计共需5000元 系统修改后能及时定货将消除零件短缺问题 估计因此每年可以节省2500元 五年共可省12500元 但是 不能简单地把5000元和12500元相比较 因为前者是现在投资的钱 后者是若干年以后节省的钱 假定年利率为12 利用上面计算货币现在价值的公式可以算出修改库存清单系统后每年预计节省的钱的现在价值 如表所示 2006年9月28日6时52分 2006年9月28日6时52分 投资回收期 所谓投资回收期就是使累计的经济效益等于最初投资所需要的时间 例如 修改库存清单系统两年以后可以节省4225 12元 比最初的投资 5000 元还少774 88元 第三年以后将再节省1779 45元 774 88 1779 45 0 44因此 投资回收期是2 44年 2006年9月28日6时52分 技术可行性 1 在给定的时间内能否实现需求说明中的功能 如果在项目开发过程中遇到难以克服的技术问题 麻烦就大了 轻则拖延进度 重则断送项目 2 软件的质量如何 有些应用对实时性要求很高 如果软件运行慢如蜗牛 即便功能具备也毫无实用价值 有些高风险的应用对软件的正确性与精确性要求极高 如果软件出了差错而造成客户利益损失 那么软件开发方可要赔惨了 3 软件的生产率如何 如果生产率低下 能赚到的钱就少 并且会逐渐丧失竞争力 在统计软件总的开发时间时 不能漏掉用于维护的时间 软件维护是非常拖后腿的事 它能把前期拿到的利润慢慢地消耗光 如果软件的质量不好 将会导致维护的代价很高 企图通过偷工减料而提高生产率 是得不偿失的事 技术可行性分析可以简单地表述为 做得了吗 做得好吗 做得快吗 2006年9月28日6时52分 社会环境 社会环境的可行性至少包括两种因素 市场与政策 市场又分为未成熟的市场 成熟的市场和将要消亡的市场 涉足未成熟的市场要冒很大的风险 要尽可能准确地估计潜在的市场有多大 自己能占多少份额 多长时间能实现 挤进成熟的市场 虽然风险不高 但油水也不多 如果供大于求 即软件开发公司多 项目少 那么在竞标时可能会出现恶性杀价的情形 国内第一批卖计算机的 做系统集成的公司发了财 别人眼红了也挤进来 这个行业的平均利润也就下降了 将要消亡的市场就别进去了 尽管很多程序员怀念DOS时代编程的那种淋漓尽致 可现在没人要DOS应用软件了 学校教学尚可用用DOS软件 商业软件公司则不可再去开发DOS软件 政策对软件公司的生存与发展影响非常大 整个90年代 中国电信的收费相当高 仅此一招就把国内互联网企业打得奄奄一息 某些软件行业的利润很高 但可能存在地方保护政策 使竞争不公平 政策不当将阻碍软件公司的健康发展 可最怕的还是政府干预企业的正当行为 2006年9月28日6时52分 人 有句名言 人分四类 人物 人才 人手 人渣 董军 软件工程思想 如果一个软件公司里上述四类人齐全了 那么最好的分工是让 人物 当领导 人才 做第一线的开发人员 人手 做行政人员 人渣 负责市场 行贿 这里只谈公司的领导与开发人员 行还是不行 人物 毕竟是少数 人才 可是济济的 举重若轻的那类 人才 可以做领导 举轻若重的那类人才适合做软件开发人员 假如一群持有学士 硕士和博士文凭的毕业生到软件公司应聘 该如何录用呢 董军的建议如下 先选择本科毕业生 因为他们正当青春 干劲十足 不摆架子 不耻下问 要求不高 奉献甚多 其次选择硕士毕业生 如果该生没象范进中举时那么老 并且在读硕士时没有天天去造文章而丢弃了编程工作 那么让有经验的学士程序员带他们煅练几个月就可以用了 如果学士 硕士被其它公司取光了 那只好捡几个博士充数 博士到了软件公司有什么用呢 我想不出有什么用 只知道他们挺值得可怜的 从硕士读到博士出头 这六七年时间 真本事没学多少 倒学会 眼高手低 甚至 弄虚作假 2006年9月28日6时52分 6 推荐行动方针 可行性分析的关键是提出是否继续进行这项开发工程 并且说明选择这个解决方案的理由 2006年9月28日6时52分 7 草拟开发计划 除了工程进度表之外还应该估计 对各种开发人员 系统分析员 程序员 资料员等 各种资源 计算机硬件 软件 数据 工具等等 的需要情况应该指明什么时候使用多长时间还应该估计系统生命周期每个阶段的成本 2006年9月28日6时52分 8 书写文档提交审查 应该把上述可行性研究各个步骤的结果写成清晰的文档 请用户和使用部门的负责人仔细审查 以决定是否继续这项工程以及是否接受分析员推荐的方案 OVER 2006年9月28日6时52分 3 Analysis Specification需求分析 不论是为客户做软件项目还是为自己做软件产品 都要进行需求分析 需求分析最恼人之处是难以在项目刚启动时搞清楚需求 如果在项目做了一大半时需求发生了变化 那将使项目陷入困境 3 3节解释需求分析为什么困难 3 4节讲述如何进行需求分析 本章的需求分析均不涉及编程 所以不考虑结构化 面向对象等分析方法 Requirementselicitation 需求获取 Theprocessofdiscoveringtheclient srequirements Requirementsanalysis 需求分析 Theprocessofrefiningandextendingtheinitialrequirementsdetermined 2006年9月28日6时52分 RequirementsDefinition RequirementsDefinition 需求定义 Customer orienteddescriptionsofthesystem sfunctionsandconstraintsonitsoperation 功能描述与操作约束 Arequirementisafeatureofthesystemoradescriptionofsomethingthesystemiscapableofdoinginordertofulfillthesystem spurpose 实现 2006年9月28日6时52分 RequirementsDefinition IEEE用户解决问题或达到目的所需的条件或能力 系统或系统部件要满足合同 标准 规范或其它正式规定文档所需具有的条件或能力 一种反映上面两条所描述的条件或能力的文档说明 真正的 需求 实际上存在人们的脑海中 任何文档形式的需求 例如 需求规格说明 仅是一个模型或一种叙述 2006年9月28日6时52分 需求分析的重要性 开发软件系统最为困难的部分就是准确说明开发什么 最为困难的概念性工作便是编写出详细技术需求 这包括所有面向用户 面向机器和其它软件系统的接口 同时这也是一旦做错 将会最终给系统带来极大损害的部分 而且以后再对它进行修改也极为困难 2006年9月28日6时52分 WhatisthisPhaseFor Majormisconception 误解 determiningwhatclientwants IknowyoubelieveyouunderstoodwhatyouthinkIsaid butIamnotsureyourealizethatwhatyouheardisnotwhatImeant 我知道你相信你理解了你认为我所说的 但我不能确定你是否认识到你所听到的并不是我所意指的 GeorgeRomney Mustdetermineclient s user sneeds Nottheclientwants chancesforsuccessslimifyoudon tfigurethisout 2006年9月28日6时52分 thegoalofthespecificationorsystemanalysisphase thegoalofthespecificationorsystemanalysisphaseistobuildamodelofthesoftwareproductthattheclientrequires Theinformationdomainofaproblemmustberepresentedandunderstood 理解和描述问题的信息范围Thefunctionsthatthesoftwareistoperformmustbedefined 定义软件的功能Thebehaviorofthesoftware asaconsequenceofexternalevents mustberepresented 描述软件对外部事件的响应Themodelsthatdepictinformation function andbehaviormustbepartitionedinamannerthatuncoversdetailinalayered orhierarchical fashion 描述信息 功能和行为的模型必须以分层的方式显示细节来划分开Theanalysisprocessshouldmovefromessentialinformationtowardimplementationdetail 描述 2006年9月28日6时52分 需求分析为什么困难 1 客户说不清楚需求 有些客户对需求只有朦胧的感觉 当然说不清楚具体的需求 有些客户心里非常清楚想要什么 但却说不明白 如果客户本身就懂软件开发 能把需求说得清清楚楚 这样的需求分析将会非常轻松 愉快 如果客户全不懂软件 但信任软件开发方 这事也好办 分析人员可以引导客户 先阐述常规的需求 再由客户否定不需要的 最终确定客户真正的需求 最怕的就是 不懂装懂 或者 半懂充内行 的客户 他们会提出不切实际的需求 2 需求自身经常变动 需求肯定会变动 1 尽可能地分析清楚哪些是稳定的需求 哪些是易变的需求 以便在进行系统设计时 将软件的核心建筑在稳定的需求上 否则将会吃尽苦头 2 在合同中一定要说清楚 做什么 和 不做什么 如果合同含含糊糊 日后扯皮的事情就多 3 分析人员或客户理解有误 客户表达的需求 不同的分析人员可能有不同的理解 写好需求说明书后 要请客户方的各个代表验证 如果问题很复杂 双方都不太明白 就有必要请开发人员快速构造软件的原型 双方再次论证需求说明书是否正确 由于客户大多不懂软件 他们可能觉得软件是万能的 会提出一些无法实现的需求 2006年9月28日6时52分 如何进行需求分析 应该了解什么 Toelicittheclient sneeds themembersoftherequirementsteammustbefamiliarwiththeapplicationdomain 熟悉客户领域知识 Tobuildaglossary 术语表 用正确的术语进行正确的交流应该先了解宏观的问题 再了解细节的问题 2006年9月28日6时52分 1 最好为每个需求注释 为什么 这样可让程序员了解需求的本质 以便选用最合适的技术来实现此需求 2 需求说明不可有二义性 更不能前后相矛盾 如果有二义性或前后相矛盾 则要重新分析此需求 2006年9月28日6时52分 TypeofRequirements BussinessrequirementsAsystemrequirement alsocalledabusinessrequirement isadescriptionoftheneedsanddesiresforaninformationsystem Arequirementmaydescribefunctions features attributes andconstraints 系统需求是对信息系统的需求描述 Userrequirements用户使用产品必须要完成的任务 业务需求 2006年9月28日6时52分 TypeofRequirements Functionalrequirements 功能需求 Afunctionalrequirementisafunctionorfeaturethatmustbeincludedinaninformationsystemtosatisfythebusinessneedandbeacceptabletotheusers 满足系统需求的 被用户认可的系统功能或者特征 Afunctionalrequirementdescribesaninteractionbetweenthesystemanditsenvironment 系统与环境间的交互 2006年9月28日6时52分 TypeofRequirements non functionalrequirementsAnonfunctionalrequirementisadescriptionofthefeatures characteristics andattributesofthesystemaswellasanyconstraintsthatmaylimittheboundariesoftheproposedsolution 限定范围 Anonfunctionalrequirementoraconstraintdescribesarestrictiononthesystemthatlimitsourchoicesforconstructingasolutiontotheproblem 限定选择的解决方案 2006年9月28日6时52分 Non functionalRequirements Definesystempropertiesandconstraintse g reliability responsetimeandstoragerequirements ConstraintsareI Odevicecapability systemrepresentations系统表现 etc Processrequirementsmayalsobespecifiedmandating要求aparticularCASEsystem programminglanguageordevelopmentmethod 过程要求 Non functionalrequirementsmaybemorecriticalthanfunctionalrequirements Ifthesearenotmet达到 thesystemisuseless 2006年9月28日6时52分 Non functionalRequirements Non functionalRequirements 法制 2006年9月28日6时52分 LevelofRequirements 业务需求 2006年9月28日6时52分 TypesofRequirements Therequirementsdefinitionandspecificationdocumentsdescribeeverythingabouthowthesystemistointeractwithitsenvironment Includedarethefollowingkindsofitems PhysicalEnvironmentWhereistheequipmenttofunction Isthereonelocationorseveral Arethereanyenvironmentalrestrictions suchastemperature温度 humidity湿度 ormagneticinterference磁干扰 2006年9月28日6时52分 InterfacesIstheinputcomingfromoneormoreothersystems Istheoutputgoingtooneormoreothersystems Isthereaprescribedwayinwhichthedatamustbeformatted Isthereaprescribedmediumthatthedatamustuse UsersandFactorsWhowillusethesystem Willtherebeseveraltypesofusers Whatistheskilllevelofeachtypeofuser Howeasywillitbeforausertounderstandandusethesystem Howdifficultwillitbeforausertomisuse误用thesystem TypesofRequirements 2006年9月28日6时52分 FunctionalityWhatwillthesystemdo Whenwillthesystemdoit Arethereseveralmodesofoperation Howandwhencanthesystembechangedorenhanced Arethereconstraintsonexecutionspeed responsetime orthroughput DocumentationHowmuchdocumentationisrequired Shoulditbeon line inbookformat orboth Towhataudienceiseachtypeofdocumentationaddressed TypesofRequirements 2006年9月28日6时52分 DataForbothinputandoutput whatshouldtheformatofthedatabe Howoftenwilltheybereceivedorsent Howaccuratemusttheybe Towhatdegreeofprecisionmustthecalculationsbemade Howmuchdataflowthroughthesystem Mustanydataberetainedforanyperiodoftime TypesofRequirements 2006年9月28日6时52分 ResourcesWhatmaterials personnel orotherresourcesarerequiredtobuild use andmaintainthesystem Whatskillsmustthedevelopershave Howmuchphysicalspacewillbetakenupbythesystem Whataretherequirementsforpower heating orairconditioning Isthereaprescribedtimetablefordevelopment Istherealimitontheamountofmoneytobespentondevelopmentoronhardwareandsoftware TypesofRequirements 2006年9月28日6时52分 SecurityMustaccesstothesystemortoinformationbecontrolled Howwilloneuser sdatabeisolatedfromothers Howwilluserprogramsbeisolatedfromotherprogramsandfromtheoperatingsystem Howoftenwillthesystembebackedup Mustthebackupcopiesbestoredatadifferentlocation Shouldprecautionsbetakenagainstfire waterdamage ortheft TypesofRequirements 2006年9月28日6时52分 QualityAssuranceWhataretherequirementsforreliability availability maintainability security andtheotherqualityattributes Howmustthecharacteristicsofthesystembedemonstratedtoothers Mustthesystemdetectandisolatefaults Whatistheprescribedmeantimebetweenfailures Isthereamaximumtimeallowedforrestartingthesystemafterafailure Howcanthesystemincorporatechangestothedesign Willmaintenancemerelycorrecterrorsorwillitalsoincludeimprovingthesystem Whatefficiencymeasureswillapplytoresourceusageandresponsetime Howeasyshoulditbetomovethesystemfromonelocationtoanotherorfromonetypeofcomputertoanother TypesofRequirements 2006年9月28日6时52分 CharacteristicsofRequirements Aretherequirementscorrect 正确Aretherequirementsconsistent 一致Aretherequirementscomplete 完整Aretherequirementsrealistic 现实Doeseachrequirementdescribesomethingthatisneededbythecustomer 必需 Aretherequirementsverifiable 可证明Aretherequirementstraceable 可跟踪 2006年9月28日6时52分 ProblemsofSoftwareRequirements Stakeholdersdon tknowwhattheyreallywant Stakeholdersexpressrequirementsintheirownterms Differentstakeholdersmayhavesomeconflictingrequirements Organisationalandpoliticalfactorsmayinfluencethesystemrequirements Therequirementschangeduringthedevelopmentprocess Newstakeholdersmayemerge Requirementsspecificationistoosimple Requirementsproblemsresultin40 60 softwareproblems 2006年9月28日6时52分 RequirementsDevelopment 确定产品所期望的用户类 获取每个用户类的需求 了解实际用户任务和目标以及这些任务所支持的业务需求 分析源于用户的信息 以区别用户任务需求 功能需求 业务规则 质量属性 建议解决方法和附加信息 将系统级需求分为若干子系统 并将需求中的一部分分配给软件组件 了解相关质量属性的重要性 商讨实施优先级的划分 将所收集的用户需求编写成规格说明和模型 评审需求规格说明 确保对用户需求达到共同的理解与认识 并在整个开发小组接受说明之前将问题都弄清楚 2006年9月28日6时52分 RequirementsManagement 定义需求基线 评审提出的需求变更 评估每项变更的可能影响 从而决定是否实施它 以一种可控制的方式将需求变更融入到项目中 使当前的项目计划与需求一致 估计变更需求所产生影响并在此基础上协商新的承诺 让每项需求都能与其对应的设计 源代码和测试用例联系起来以实现跟踪 在整个项目过程中跟踪需求状态及其变更情况 2006年9月28日6时52分 RequirementElicitation 需求获取的工作内容聆听用户需求分析人员应与各种层次的客户交流和沟通 尽量清楚理解 分析和整理所获取的信息从用户一般性的陈述中提取用户的真正需求 形成文档化的描述问题和需求都需要形成文档化的描述 使各种人员一致理解和认可 需求获取的关键沟通和交流正确和清楚地理解 2006年9月28日6时52分 Stakeholders 2006年9月28日6时52分 RequirementsAnalysisTechniques Interviewing 访谈 Questionnaires 问卷 consultanexpert askforadvice 请教专家 Formsanalyses 表格分析 Existingsystemsanalysis 现存系统分析 Scenarios 情景 Rapidprototyping 快速原型 2006年9月28日6时52分 Interviewing 直接与客户交谈 如果分析人员生有足球评论员的那张 大嘴 就非常容易侃出需求 或名记者的提问技巧 Structuredvs Unstructured 程式化和非程式化 whatisthedifference whatarethetradeoffs折衷 Asweknow Thereareknownknowns Therearethingsweknowweknow WealsoknowThereareknownunknowns ThatistosayWeknowtherearesomethingsWedonotknow Buttherearealsounknownunknowns Theoneswedon tknowWedon tknow DonaldRumsfield February12 2002 DepartmentofDefensenewsbriefingSpecific preplaned close endedquestionsvs Open endedQuestions 谨防满无目的地 ContextualInquiry 打破砂锅问到底 顺藤摸瓜 Why Wayofunderstandingusers needs workpracticesmaster apprenticemodel 师徒 allowscustomertoteachuswhattheydo masterdoesthework talksaboutitwhileworkingweinterrupttoaskquestionsastheygoTheWhere How andWhatexposetheWhy 2006年9月28日6时52分 Communication 用户 采购者 市场人员 需求分析员 开发人员 产品代表 用户管理员 系统设计员 2006年9月28日6时52分 ContextualInquiryPrinciples Contextgototheworkplaceothermodels noavoidinterviewer interviewee stopswork allowsmoreapprenticeinteraction alternate watching probing寻根究底 Interpretation 解释 goodfactsonlythestartingpoint designsbasedoninterpretationsValidate 确认 runinterpretationsbytheusertoseeifyouarerightFocusinterviewerneedsdataaboutspecifickindofwork steer conversationtostayonusefultopics 驾驭谈话主题 2006年9月28日6时52分 UIDesignProcess SpecProduction DesignRefinement DesignExploration Discovery Assessneeds评估需求understandclient sexpectations 期望 determinescopeofprojectcharacteristicsofusersevaluateexistingsiteand orcompetition 2006年9月28日6时52分 CommentonHumanFactors HUIHuman computerinterfaceKeyaspectofsuccessfulsoftwareproductintendedusersmustinteractw itNeedtoconsider 考虑的因素 expertiseofintendedusers 资深专家型 cognitiveabilities who whattaskstheydonow willdo what Becarefulofbook shintthatgoodUIdesignmightjustbe commonsense canonlybemadesuccessfulbyinvolvinguserinrepeatedprocessofdesign prototype test 使用户成功参与设计 原型 测试的重复进程 showntobetruetime timeagaindesigneregobias 自我偏见 wearenottheusersanymoreUser friendlinessTakeSSD4ifyouwanttoreallylearnthis 2006年9月28日6时52分 Scenarios Illustratethemajorevents actionstousersAscenarioisawayausermightutilizethetargetproducttoaccomplishsomeobjective 利用目标产品完成某一功能的方式oftenusestoryboards 情景板 p