卢晓东：在写软件设计模式大作业时才会感觉到书上讲的东西的含义，没有好的计划让我的进度一度被搁浅，想说做一个小书店的程序，然后想着要用到数据库存储数据，然后就上网找怎么连接我在学的SQL Server2012，接着就是配置我的数据库的TCP/IP协议啦，然后当天晚上电脑运行速度直线下降QAQ我的心在滴血的TAT，配置好了以后又遇到了一个问题，就是我先做程序界面呢还是先做数据库的读取呢？思索了很久还是决定从读取数据库数据开始吧，这样做界面的时候才会有数据支持。整个过程我都是一边做一边想，没有制定具体的计划，也没怎么注意细节这些，发现想做好一个程序有时真的特别凌乱，不知道从哪下手，当自己以为有思路就可以了的时候，发现不知道从哪里下手-_-嗯，不说了，还得去继续思考细节问题
王彦凯：
软件需求
1、获取和引导需求
2、分析和定义需求
3、验证需求
4、在软件产品的生命周期中管理需求
对软件的需求，也可以从不同角度做下面的划分：
1、对产品功能性的需求
2、对产品开发过程的需求
3、非功能性需求
4、综合需求
用户调研方法：
1、焦点小组
2、深入面谈
3、卡片分类
4、用户调查问卷
5、用户日志研究
6、人类学调查
7、眼动跟踪研究
8、快速原型调研
9、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）来判断好坏；从用户的角度考虑问题需要我们有“同理心” ； 软件服务过程中始终都应该要记住用户的选择，做到“软件用得越多，越来越好用”；在用户体验这个问题上，还要特别考虑到短期刺激和长期影响；在设计软件时要考虑到用户在使用时不会犯简单的错误；在必要的时候，可以牺牲软件质量去追求用户体验；诺尔曼阐明了设计的三个层次——本能层次、行为层次、反思层次。
在第二节中，介绍了用户体验设计的步骤和目标。用户体验设计的一个重要目标就是降低用户的认知阻力，即用户对于软件界面的认知和实际结果的差异；用户体验设计的步骤——概要设计、行为交互设计、界面设计。
在第三节中，介绍了一个好的软件用户界面的评价标准。这些标准原则包括尽快提供可感触的反馈、系统界面符合用户的现实惯例、用户有控制权、一致性和标准化、适合各种类型的用户、帮助用户识别诊断修复错误、有必要的提示和帮助文档。