第四次小组报告

卢晓东：在写软件设计模式大做业时才会感受到书上讲的东西的含义，没有好的计划让个人进度一度被搁浅，想说作一个小书店的程序，而后想着要用到数据库存储数据，而后就上网找怎么链接我在学的SQL Server2012，接着就是配置个人数据库的TCP/IP协议啦，而后当天晚上电脑运行速度直线降低QAQ个人心在滴血的TAT，配置好了之后又遇到了一个问题，就是我先作程序界面呢仍是先作数据库的读取呢？思索了好久仍是决定从读取数据库数据开始吧，这样作界面的时候才会有数据支持。整个过程我都是一边作一边想，没有制定具体的计划，也没怎么注意细节这些，发现想作好一个程序有时真的特别凌乱，不知道从哪下手，当本身觉得有思路就能够了的时候，发现不知道从哪里下手-_-嗯，不说了，还得去继续思考细节问题

王彦凯：

软件需求

一、获取和引导需求

二、分析和定义需求

三、验证需求

四、在软件产品的生命周期中管理需求

　　对软件的需求，也能够从不一样角度作下面的划分：

　　　　一、对产品功能性的需求

　　　　二、对产品开发过程的需求

　　　　三、非功能性需求

　　　　四、综合需求

用户调研方法：

一、焦点小组

二、深刻面谈

三、卡片分类

四、用户调查问卷

五、用户日志研究

六、人类学调查

七、眼动跟踪研究

八、快速原型调研

九、A/B测试

 

竞争性需求分析的框架

　　NABCD模型

　　　　N（need，需求）

　　　　A（approach，作法）

　　　　B（benefit，好处）

　　　　C（competitors，竞争）

　　　　D（delivery，推广）

 

功能的定位和优先级

　　两种不一样类型的功能

　　　　杀手功能/外围功能

　　　　必要需求/辅助需求

　　　　杀手功能：OCR文字识别技术，能够在屏幕上取词解释，拥有独家权威辞典、等等

　　　　外围功能：良好的界面设计，在各个平台上都能运行

　　　　必要需求：单词短语释义的准确性（若是达不到这一点，用户就不会来使用）

　　　　辅助需求：能够作各类皮肤（这也许能让一些用户更喜欢这个软件，但不是决定因素）

李凯城：

Agile——敏捷开发，做为CMM神话崩溃后被引入的一套新的软件开发模式，这几年来被普遍引发关注，并被寄予厚望。

敏捷流程及其原则告诉咱们个体和交互赛过过程和工具，尽早为客户需求作准备和交付有价值的软件，时时总结如何提升团队效率才能得到更大的进步。

敏捷流程重视团队，重视需求，重视效率。

若是说Agile只是比较侧重于效率的话，那MSF是在这基础上更加注重学习跟规划。

首先，MSF提倡信息共享和沟通，开展项目的时候对项目的信息都要公开，让你们能了解这个项目。

若是信息不能共享，更加达不到分派任务，各司其职。

学习全部的经验。

这一原则告诉咱们不只要多总结经验，结合以前的信息共享，经验一样也要共享，共同进步。

保持敏捷，效率确定是不可或缺的，同时作好预期规划，客户的需求会致使项目的变化，项目的变化要提早作好规划，不要到头来白忙一场。

重视团队合做。

固然，这个在信息共享的时候就开始体现了，团队的合做，各司其职，才能作到更加敏捷。

奚佳峰：

需求分析方法：

1.获取和引导需求

软件团队须要找到 软件的利益相关者，了解和挖掘他们对软件的需求，引导他们表达出对软件的需求。

 不一样的项目须要不一样的手段，这一步骤也被叫作“需求捕捉”，形容真正的需求稍纵即逝，须要靠火眼金睛和敏捷的身手来发现并抓住它们。另外，不少时候用户并不知道本身确切的需求，或者不肯意表达完整的需求，软件团队须要设身处地，替用户着想，引导出需求。有些需求在实现以前，并无用户明确表达具体的需求（例如：没有用户说“我但愿有一个偷菜的软件，我能够偷别人家的菜”），可是，成功的团队仍是能够从“用户须要和朋友之间玩游戏，用户有证实本身能力的需求”这些角度出发，挖掘出需求。另外，软件团队能够分析技术的发展趋势以及产业的变化、社会发展的大趋势，推测用户会产生哪些新的需求。例如，看到全球定位系统（GPS）技术的成熟、地理信息系统的发展、私家车的普及和智能手机性能的不断提升，咱们能够推测出利用手机给汽车导航将是一个广泛的需求

需求还能够来自各类 管理机构 

例如一些互联网服务对不一样年龄用户的内容管理\“敏感词屏蔽”、快速删除网上内容，等等

需求不只来自外界，还能够来自 软件企业自己 

软件企业＝软件+商业模式。企业所采用的商业模式会对软件提出需求。一个免费的互联网服务到达必定规模后，企业就会考虑如何让这个服务带来收入，例如一个免费的互联网电子邮件服务会考虑对用户收费，支持几种不一样等级的用户，在邮件中附带广告，或者在页面显示广告，等等。这些“需求”并非来自用户，事实上绝大部分用户都反感这样的“需求”，可是企业须要一个能维持它生存和发展的商业模式，尽管这个模式的种种需求未必都是对用户有利的

需求还能够来自技术团队自己 

团队在考虑软件的代码、架构、所依赖平台的长期演化的时候，会提出技术性的需求，包括代码的迁移、架构的演化、平台的变化，或者引入新的技术。例如，为了提升未来的开发效率，一个手机软件的开发者决定逐步引入跨平台的语言和框架；一个依赖客户端/服务器（Client/Server）架构的软件须要支持新的HTTPS协议；原来后台的数据服务使用了专用的数据库和专门的小型机，如今改成基于开源技术的软件和硬件；软件前端代码须要支持某种自动测试工具，以便更有效地进行自动测试，等等

有些需求的目的是要 更好地了解用户的行为和需求

例如，咱们要在软件的各个功能点加上收集信息的代码，并在后台实现数据收集、整理、报告和数据挖掘（Data Mining）工做。此类技术在一些公司叫Telemetry—遥测技术

2. 分析和定义需求（Analysis & Specification）

这是指对从各个方面获取的需求进行规整，定义需求的内涵，从各个角度将需求量化（需求实现的最后期限，实现需求大体所需的时间和资源成本，各个不一样需求的优先级，需求带来的收益，等等）

3. 验证需求（Validation）

软件团队要跟利益相关者沟通，经过分析报告、技术原型、用户调查或演示等形式向他们验证软件团队对于这些需求的认知

4. 在软件产品的生命周期中管理需求（Management）

在软件的生命周期中，需求在发生变化，技术在发展，团队成员的能力也在提升。原来认为重要的事情可能再也不重要，有些功能原来技术上很难实现，如今出现了捷径，一些相关的法规会发生变化，外部的合做伙伴忽然发生变化，这些都要求咱们不断对需求进行从新审核并作出相应的调整

 

 

获取用户需求：

用户最须要的> 
　　用户表达出来的> 
　　　　软件团队能理解的 + 团队的商业目标> 
　　　　　　　软件团队成员具体表达出来的（PM写Spec）> 
　　　　　　　　　在各类约束条件下，具体执行表达出来的（Dev写代码）> 
　　　　　　　　　　　验证经过的（Test）> 
　　　　　　　　　　　　　经过各类渠道告诉目标用户（发布/推广）> 
　　　　　　　　　　　　　　　用户终于能用上了，可是他们不满意

 

竞争性需求分析的框架 —— NABCD模型：

1. N（需求） 
你的创意解决了用户的什么需求？这个需求能够是明确的、公开的（例如：但愿能上网玩三国杀）也多是说不清道不明的，例如——之前没人说：嗯，若是我能找到这样一个网站，我能够去偷菜，就行了……咱们要充分了解用户的痛苦，他们对已有软件、服务不满意的地方。可是用户每每也不了解颠覆型的创新。例如，亨利·福特是汽车行业的先驱，若是他深刻用户（马车夫），征询他们的需求，马车夫会告诉他：我但愿个人马跑得更快一些

2. A（作法） 
好，你找到了需求，下一步怎么办，得看看你有什么招数，特别是独特的招数，来解决用户的痛苦。你不能说我会C++，因此我必定能够写好这个软件。你得有独特的办法，例如，有人脸识别技术，会作超大规模的数据处理。那你（你的团队）会什么呢？只会冒泡排序？这些招数不光是技术上的，也能够是商业模式上的（例如，咱们第一个作众包的服务）、地域的（例如，咱们对本市的公交线路很熟）、人脉的（例如，咱们认识不少大学生）、行业的（例如，咱们有地图测绘行业的资质），或者是成本上的（例如，咱们能找到更便宜的资源来维护网站）。

3. B（好处） 
这时候你已经有了独特的作法，那你这个产品/服务会给客户/用户带来什么好处呢？若是用户已经有一个解决方案（例如用户已经在用QQ聊天），那你的新的聊天软件具体有哪些好处，能让用户离开现有产品，使用你的产品呢？这还有一个用户迁移成本的问题——用户要花费多少精力、时间、金钱才能获得你的产品的好处？若是你要求用户必须有8GB内存、最好的显卡、10Mbps以上的宽带链接，才能使用你的“更好的”视频聊天工具，那么会有多少用户愿意支付这个成本呢？

4. C（竞争） 
竞争对手也没有闲着，这个市场有多大，目前有多少竞争者在瓜分，你了解么？你的产品若是不是最早进入某个市场的，你还能赢么？先进入市场的产品，有所谓的先发优点，固然也有劣势。后面进入市场的产品，有种种不利的因素，可是也有后发优点。

 5. D（推广） 

在实际项目中经历屡次的NABC以后，许多人意识到这个框架还应该加一个元素D：Delivery。怎样把你的创新产品交到用户的手中？例一，你想到了一个好主意，建一个比hao123更好的导航页面！咱们姑且认为NABC都没问题，那如何把这么好、这么简单的产品交到（Deliver）用户手中呢？例二，你想到了一个手机的应用，NABC都不错，那如何把产品交到千万个用户手中呢？不少同窗会说，把它提交到应用商店去啊！可是在中国大陆有多少个手机应用商店？你的应用提交上去以后，会在相应的产品类别中名列第几？有多少人会看到？

杨嘉豪：

第十一章的内容是软件设计与实现。

在第一节中，讲的是关于分析和设计方法，向咱们介绍在“需求分析”、“设计与实现”阶段、“测试”“发布”阶段该搞清楚的问题。

在第二节中，讲的是关于图形建模和分析方法。在表达实体和实体之间的关系时，能够用到思惟导图（Mind Map）、实体关系图（ERD）、UCD ;在表达数据的流动时，能够用到DFD工具；在表达控制流的时候能够用到FSM工具；前面提到的这些图形建模方法各有特色，UML却能够有一个统一的表达方式，但人们对UML倒是褒贬不一。

在第三节中，为咱们介绍了在软件发展过程当中科学家和工程师尝试过的其余设计方法，包括形式化的方法、文学化编程等等。

在第四节中，介绍了从Spec到实现的具体过程、把修改集集成到代码库中的具体步骤还有开发人员的标准工做流程。

第五节介绍的是开发阶段的平常管理。

第六节则说明了代码完成后还须要注意的问题。

第十二章的内容是用户体验。

在第一节中，讲的是用户体验的要素。在给用户一个好的第一印象时，咱们能够用5W1H（who、when、where、what、why、how）来判断好坏；从用户的角度考虑问题须要咱们有“同理心” ； 软件服务过程当中始终都应该要记住用户的选择，作到“软件用得越多，愈来愈好用”；在用户体验这个问题上，还要特别考虑到短时间刺激和长期影响；在设计软件时要考虑到用户在使用时不会犯简单的错误；在必要的时候，能够牺牲软件质量去追求用户体验；诺尔曼阐明了设计的三个层次——本能层次、行为层次、反思层次。

在第二节中，介绍了用户体验设计的步骤和目标。用户体验设计的一个重要目标就是下降用户的认知阻力，即用户对于软件界面的认知和实际结果的差别；用户体验设计的步骤——概要设计、行为交互设计、界面设计。

在第三节中，介绍了一个好的软件用户界面的评价标准。这些标准原则包括尽快提供可感触的反馈、系统界面符合用户的现实惯例、用户有控制权、一致性和标准化、适合各类类型的用户、帮助用户识别诊断修复错误、有必要的提示和帮助文档。