Q1. 在泛读《构建之法》这本书时，我在第一章看到这样一段文字（历史学家们说计算机系统的第一个Bug是一个蛾子，因此大家把软件的缺陷叫做Bug.其实不少工程师在那之前都用”Bug“来统称系统中的问题），有这个问题（Bug究竟是什么？究竟是软件使用或者测试过程中，突然出了需要维护的问题；还是软件开发人员和用户的需求之间产生的分歧？为什么对于Bug没有一个明确的解释?）。我查了资料发现存在这样的说法（所谓“（Bug）”，是指电脑系统的硬件、系统软件（如操作系统）或应用软件（如文字处理软件）出错。硬件的出错有两个原因，一是设计错误，一是硬件部件老化失效等。软件的错误全是厂家设计错误。那种说用户执行了非法操作的提示，是软件厂商不负责的胡说八道。用户可能会执行不正确的操作，比如本来是做加法但按了减法键。这样用户会得到一个不正确的结果，但不会引起bug发作。软件厂商在设计产品时的一个基本要求，就是不允许用户做非法的操作。只要允许用户做的，都是合法的。用户根本就没有办法知道厂家心里是怎么想的，哪些操作序列是非法的。），但是根据我为数不多的实践，我有这样的经验（硬件中的Bug我不太了解，但是软件中的Bug仅仅是来自程序代码的出错。）。但是我还是不太懂，我的困惑是（虽然bug不可消除，但是用户和软件开发人员之间的表述不清和功能分歧这是属于沟通领域，已经不关软件本身的问题了，怎么可以以偏概全都叫bug），希望在以后的学习中可以解决这一问题，并深化自己对软件工程整体的理解。
Q2.我在第七章看到这样一段文字（软件工程，唯一不变的就是变化。所以干脆干脆别幻想用户的需求会在第一时刻很明确。然后保持不会变。但要注意，我们是预期变化，不是期望变化。），有这个问题（虽然软件开发过程是一个连续修改的过程，力求最合适用户，但是一直变化，会不会出现太多次大幅度的修改，然后出现开发方向严重偏离或者打击开发者的信心？）。我查了资料发现存在这样的说法（这就需要在需求分析阶段多沟通多了解，先确定方向，再寻求长期的比较广度的发展，也需要团队保持敏捷的应对方式，符合msf团队模型），但是我依旧觉得（需要团队之间的默契和协作，必须让团队中的每个人都明白彼此的想法，但需求变化依旧是不可控的，希望能有更好的解决办法。）
Q3.我在第八章看到竞争性需求分析的框架，有这个问题（最新型，有创新点的软件设计，一定就是最符合用户心目中的软件吗？）。我仔细看了书发现存在这样的说法（从需求、做法、竞争、推广多方面分析来看，软件开发市场需要一定的创新和竞争力，但一个公司可能有多种软件产品和服务，它们各有不同的战略意义。一个软件或服务也由很多功能组成，它们有机地结合起来，才能解决用户的问题，产生效益，要更用心地去优化软件，后期准确的表达与介绍产品的核心价值，体现不同类型的功能，就也许可以取得好评。），基本解决了我的疑惑。
