标签：blog http ar os 使用 sp 数据 log bs
软件开发的过程，就是用户最需求的东西在项目开发过程中不断削减、丢失的过程。所以做好对用户的需求分析很重要，这就需要软件工程小组采取高效且合适的调研方法。
解释：找到一群目标用户的代表来讨论用户想要什么, 用户对软件的评价等等。
分析：抽取的目标用户的代表数量少，并且每个代表对于产品的需求有很强的个人因素的影响，不能准确地表示他所代表的群体的需求，具有很大的不确定性。
可行度：★★★★☆
有效度：★☆☆☆☆
解释：通过详细的面谈，广泛而深入地了解用户的背景，心理，需求等。
分析：由于详细面谈需要一对一的采访，这也就使得软件小组的需求分析人员需要耗费很大的精力和时间，也占用了用户的宝贵的时间。
可行度：★☆☆☆☆
有效度：★★★★☆
解释： 在卡片上列出所希望的软件有什么样的特点, 然后把这些特点归类。
分析：卡片更加明确了需求的定量成分，将卡片上的信息进行整合，可以得到一个很好的软件的信息架构，但是对于我们大学生来说“将几个不同背景的人聚在一起”的可行度不高。
可行度：★☆☆☆☆
有效度：★★★★☆
解释：向用户发问卷（电子问卷或者纸质问卷），收集用户反馈的数据，进行需求分析。
分析：对于大学生软件工程小组的可行性很不错，可以收集到大量的数据反馈；但是可能会收到很多的无效信息，或者不代表个人意愿的信息。
可行度：★★★★★
有效度：★★★☆☆
解释：要求用户记录自己日常工作或生活中和所用软件相关的行为, 供以后分析。
分析：要求用户必须像记日记一样的方式对软件相关的行为进行记录，可是有些人根本没有记笔记的习惯，更不要想他会每天对软件相关的行为进行记录了。
可行度：★★☆☆☆
有效度：★★★☆☆
解释：和目标用户同吃同住同劳动。
分析：所得到的需求反馈的信息很高效，但是需要耗费调研人员的大量的精力以及时间，对于大学生软件工程的可行度低。
可行度：★☆☆☆☆
有效度：★★★★★
解释：研究用户在使用软件的时候有哪些困难, 并如何改进软件，让软件更好用
分析：可行性不错，但是对于发现用户真是的需求的有效度不是很高，而对于发现UI的缺点，针对于如何使得UI更加人性化，简单化倒是有更大的帮助。
可行度：★★★★☆
有效度：★★☆☆☆
解释：通过研究分析用户打开应用时候的眼睛关注点使设计者能够将最希望用户看到的东西设计在合适的位置。
分析：眼动跟踪研究需要专业的设备，并且已经有对于眼动跟踪所得出的诸多结论可以利用，所以大学生软件工程小组采用这种方法可行度不高，并且也不必要。
可行度：☆☆☆☆☆
有效度：★★☆☆☆
解释：拿一些”纸张“模型, 让用户去使用, 得到反馈，其中模型不一定非要用纸，可以是其他材料做出来的模型。
分析：对于通过模型试用之后得到的用户的反馈还是很有价值的，有效性不错。但是制作模型需要小组成员的脑力和体力以及时间的很大程度的付出，成本高，导致了其可行性低。
可行度：☆☆☆☆☆
有效度：★★★★☆
解释：首先决定进行测试的对比对象A和B，然后通常在5%---10%左右的用户中进行试用的测试，最终得到用户的反馈。
分析：A/B测试可以通过对比得到用户的反馈，对于版本的更新会有很大的帮助；选取少部分的用户进行试用的方法也使得其可行性不错。
可行度：★★★★☆
有效度：★★★☆☆
综上分析以及各种方法的所得星级，我们小组选取星级最高的调研方法---用户调查问卷的方式来收集用户的需求以及反馈信息。
标签：blog http ar os 使用 sp 数据 log bs
原文地址：http://www.cnblogs.com/ourteam/p/4072700.html
