workflower的博客

原创 避免使用实例陷阱

• 太多的使用实例如果你发现自己陷入使用实例的爆炸之中，你就可能不能在一个合适的抽象级上为之编写文档。• 试图把每一个需求与一个使用实例相联系使用实例可有效地捕捉大多数所期望的系统行为，但是你可能有一些需求，这些需求与用户任务或其他执行者之间的交互没有特定的关系。为了避免重复，可以使用“包括”关系，在这一关系中，将公共函数分离出来并写到一个单独的使用实例中，当其它使用实例需要该函数时，可以请求调用它。• 使用实例中的用户界面的设计使用实例应该把重点放在用户使用系统做什么，而不是关心屏幕上是怎么显示的。

原创 需求获取-对客户输入进行分类

4) 功能需求客户所说的诸如“用户应该能<执行某些功能>”或者“系统应该<具备某些行为〉”，这是最可能的功能需求。9) 解决思想如果一个客户描述了用户与系统交互的特定方法，以使系统产生一系列活动（例如：用户从下载清单中选择一个所需要的项），这时你正在听取建议性的解决方案，而不是需求。3) 业务规则当一个客户说，一些活动只能在特定的条件下，由一些特定的人来完成时，该用户可能在描述一个业务规则，例如，“如果一个药剂师在危险化学制品培训方面是可靠的，那么他就可以在一级危险药品清单上订购化学制品”。

原创 需求获取-使用实例的益处

使用实例方法给需求获取带来的好处来自于该方法是以任务为中心和以用户为中心的观点。比起使用以功能为中心的方法，使用实例方法可以使用户更清楚地认识到新系统允许他们做什么。在许多e b开发工程中，用户代表发现，使用实例的方法真正有助于他们弄清We b站点的访问者可以做什么。进而，当业务过程随时间而变时，内嵌在特定的使用实例中的任务也会相应改变。使用实例技术防止了“孤立”的功能—这些功能在需求获取阶段似乎是一个好的见解，但没有人使用它们，因为它们并没有与用户任务真正地联系在一起。

原创 使用实例和功能需求

虽然你仍可能需要用一个独立的软件需求规格说明来记录与特定的使用实例无关的需求，但是一种可能的方法是把功能需求包括在每一个使用实例的说明之中。一种方法是可以通过先前讨论的“包括”的关系来阐述，在这一关系中一些公共功能（如用户身份验证）被分割到一个独立的，可重用的使用实例中。另一种方法是把使用实例说明限制在抽象的用户需求级上，并且把从使用实例中获得的功能需求编入软件需求规格说明中。然而，你需要确定冗余的功能需求，或者对每个功能需求仅陈述一次，并且无论需求是否重复出现在其它使用实例中，都要参考它的原始说明。

原创 需求获取-基于使用实例的方法

虽然使用实例来源于面向对象的开发环境，但是它也能应用在具有许多开发方法的项目中，因为用户并不关心你是怎样开发你的软件。执行者是指一个人，或另一个软件应用，或一个硬件，或其它一些与系统交互以实现某些目标的实体（ Cockburn 1997a，b）。例如，“化学制品跟踪系统”中的“请求一种化学制品”使用实例包括一个名为“请求者”的执行者。在理论上，使用实例的结果集将包括所有合理的系统功能。在现实中，你不可能获得完全包容，但是比起我所知道的其它获取方法，基于使用实例的方法可以为你带来更好的效果。

原创 使用实例和用法说明

被包括的使用实例对于任务的完成是必不可少的，但一个扩充其它实例的使用实例则是可选的，因为普通过程可以完全替代它（ Rumbaugh 1994）。举一个例子：在图8 - 1中，“请求一种化学制品”实例是那些包含一个称为“输入货物编号”独立实例的许多使用实例中的一种。在这幅图中，主要的使用实例是“请求一种化学制品”。其它的使用实例：“查看仓库中可用的化学制品容器”和“输入货物编号”，描述了两种可能的使用实例中《e x t e n d》和《i n c l u d e》的关系，这将在这一章的后面部分介绍。

原创 需求获取的指导方针

对需求问题的全面考察需要一种技术，利用这种技术不但考虑了问题的功能需求方面，还可讨论项目的非功能需求。Gause 和We i n b e rg（1 9 8 9）提出使用“上下文无关问题”—这是一个高层次的问题，它可以获取业务问题和可能的解决方案的全部信息。需求获取是一个需要高度合作的活动，而并不是客户所说的需求的简单誊本。然后，把任务描述成功能需求，这些功能需求可以使用户完成其任务，也可以把它们描述成非功能需求，这些非功能需求描述了系统的限制和用户对质量的期望。对系统错误情况的反映，用户是如何想的？

原创 聆听客户的需求

从这些任务中，分析者能获得用于描述系统活动的特定的软件功能需求，这些系统活动有助于用户执行他们的任务。同时，你将处理这些信息以理解它们，并把它们分成不同的类别，还要把客户需求同可能的软件需求相联系（分析）。获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。参与需求获取者只有在他们理解了问题之后才能开始设计系统，否则，对需求定义的任何改进，设计上都必须大量的返工。对于需求的任何子集，一旦你完成了第十三步，那么你就可以很有信心地继续进行系统的每一部分的设计、构造，因为你将开发出一个好的产品。

原创 产品的代表者

当我们组建开发组时，决定我们的每一个工程项目都包括为数不多的核心参与者，这些参与者来自相关的用户团体，并提供客户的需求。一个优秀的产品代表者对新系统有明确的认识并有极大的热情，因为他们知道新产品将使他们以及他们的伙伴受益。通常，许多产品代表者在工作中又去承担其它的任务，因此，你必须有令人信服的观点，阐明一些特殊个人的参与对项目的成功具有重要意义。我曾经见过产品代表者工作失误，因为充当核心联络角色的产品代理者没有与他们的同行进行充分的交流，而仅仅代表了他们自己的需求和对产品的概念。

原创 寻找用户代表

如果建立起一个用户组，必须明确，这些参与者是否真正代表了各个方面的用户，而这些用户的需求是否可以促进产品的开发。虽然你必须把重点放在最重要的用户代表身上，但是你还是需要广泛的用户参与者来代表不同的用户类和不同的专业层次。你必须确信，插入的这些层次是具有价值的，就像一个有经验的需求分析员可以与用户或其他参与者一起工作，为开发者收集、评价并组织整理需求信息。虽然要获得最优的用户代表是困难的，且可能要花很多钱，然而，如果你不与能提供最佳信息的人交流，那么你的产品和用户将蒙受损失。

原创 寻找客户的需求

对当前系统的用户和将来系统的有潜力的用户，分析员观察“日常工作”以获得经验，这些经验能提供很有价值的信息。分析员可通过观察用户与所关联的任务环境的工作流程来预见用户在使用当前系统时所遇到的问题，并能分析新的系统可有效支持工作流程的方面（McGraw and Harbison 1997;通常通过开发具体的情节（ s c e n a r i o）或活动顺序（有时称作“情节”），可以确定用户利用系统需要完成的任务，分析员由此可以获得用户用于处理任务的必要的功能需求。2. 把对目前的或竞争产品的描述写成文档。

原创 寻找客户的需求-用户类

我听说过一个给6 5个团体用户开发一个专门的业务产品的公司，当他们意识到可以把用户分成6个截然不同的用户类时，这些用户对未来发行的产品的需求就被简化了。产品的用户在很多方面存在着差异，例如：用户使用产品的频度、他们的应用领域和计算机系统知识、他们所使用的产品特性、他们所进行的业务过程、他们在地理上的布局以及他们的访问优先级。产品的用户在很多方面存在着差异，例如：用户使用产品的频度、他们的应用领域和计算机系统知识、他们所使用的产品特性、他们所进行的业务过程、他们在地理上的布局以及他们的访问优先级。

原创 Multisim 疑难问题。

电路拓扑复杂、元件参数极端（如极大/极小电阻或电容）。：元件参数未理想化（如未考虑寄生参数）、仪器设置错误。确认激活码是否与软件版本匹配（如教育版/专业版）。检查仪器量程是否合适（如万用表在交流/直流模式）。检查电路是否包含射频专用元件（如 S 参数模块）。使用中间格式（如 PDF 原理图）手动重建电路。减少高频率元件（如高频信号源）的仿真时间步长。调整屏幕分辨率或缩放比例（如 100%）。确保元件支持温度参数（如电阻温度系数）。启用元件的寄生参数（如电感串联电阻）。

原创 研究生面试千人一面

做过图像识别科创或者毕设的，如果问车牌识别算法，回答都是调用现成的，要是问系统里如何处理数据或者只能问答的，回答都是调用的API。面试通过后，个个都是人才，选导师就像翻牌子，今天跟这个明天换另一个，或者给导师个试用期，不行半年就换导师，不让换就去天台直播。自述部分流畅，声情并茂，无论英文还是中文的，但用英文一提问，回答基本全都支支吾吾的，有的直接放弃了，听不懂问的什么；要是问对研究生阶段的规划，回答都是第一年上课，第二年做研究，第三年写论文，其实心里都想说第三年考公，只是不能说；那一套，或者小程序。

原创 软件项目范围-关联图

关联图( C o n t e x t d i a g r a m )通过正在开发的系统或正在讨论的问题和外部世界之间的联系来描述这一界线。关联图确定了通过某一接口与系统相连的外部实体（称为“端点”或“外部实体”），同时也确定了外部实体和系统之间的数据流和物流。别忘了，公司总是发购买化学制品的订单给化学制品供应商，并从供应商那里得到装有化学制品的容器和发票，而供应商则得到支票。虽然某些端点与所规划的系统没有直接联系，但有时关联图将给出与项目的问题域有关的端点之间的联系（ Jackson 1995）。

原创 把注意力始终集中在项目的范围上

第三种可能性是“所提出的新需求在项目范围之外，但这是一个很有价值的方案，此时可以改变项目的范围来适应这一需求。当改变项目的范围时，你必须重新商议计划预算、资源及进度安排，也许还有开发人员（特别是在需要新的技术和技巧时）。当一些有影响的人企图往有许多约束的项目中添加更多的特性时，可以合理地拒绝这些要求。如果这种建议与已经为某一确定产品所制定的需求相比，具有更高的优先级，则这些新的并符合要求的需求就可以加入到项目中。当某些人提出新的需求或改变需求或特性时，你必须问的第一个问题是：“这是否包含在项目范围之内？

原创 项目视图和范围的文档

项目视图和范围文档包括了业务机遇的描述、项目的视图和目标、产品适用范围和局限性的陈述、客户的特点、项目优先级别和项目成功因素的描述。包括对现存产品的一个简要的相对评价和解决方案，并指出所建议的产品为什么具有吸引力和它们所能带来的竞争优势。总结首次发行的产品所具有的性能。总结开发（或不开发）该产品有关的主要业务风险，例如市场竞争、时间问题、用户的接受能力、实现的问题或对业务可能带来的消极影响。客户概述明确了这一产品的不同类型客户的一些本质的特点，以及目标市场部门和在这些部门中的不同客户的特征。

原创 通过业务需求确定项目视图

例如，业务需求的确定可以从售货亭软件产生最大收益考虑，这意味着软件性能的最初实现是与销售更多的产品或对客户服务有直接关系，而不是去强调只吸引少量客户的软件性能。业务需求不仅决定了应用程序所能实现的业务任务（使用实例）的设置（所谓的应用宽度），还决定了对使用实例所支持的等级和深度。支持的深度可以从一个很小的实现细节到具有许多辅助功能的完全自动化的操作。开发商业软件的公司经常编写市场需求文档，其实这种文档也是为了类似的目的，但这种文档较为详细地涉及关于目标市场部分的内容，这是为适应商业的需要。

原创 ai距离能理解人类的要求还有多远？

背景知识和常识的缺乏：人类在交流中常常依赖大量的背景知识和常识，而AI可能缺乏这些知识。例如，询问“苹果从树上掉下来，会怎样”，AI可能知道会落地，但对于为什么会落地等常识性原理可能理解不深。- 多模态理解能力发展：一些AI系统可以处理图像、音频等多种模态的数据，能理解图片中的内容、识别语音并转化为文字进而理解其含义。像“他是个老狐狸”，AI可能无法理解这是在形容人狡猾。虽然AI在理解人类要求方面不断进步，但要达到人类水平的理解能力，还需要在技术上取得更大的突破，以及对人类认知和语言有更深入的研究。

原创 ai搞不清楚的文字

原创 与需求有关的风险

从客户代表方获得参与需求评审的赞同（承诺），并尽早且以尽可能低的成本通过非正式的评审逐渐到正式评审来找出其存在的问题。1) 变更需求将项目视图与范围文档作为变更的参照可以减少项目范围的延伸。产品未说明白的地方将耗费比预料中更多的工作量，而且按最初需求所分配好的项目资源也可能不按实际更改后用户的需求而调整。2) 需求变更过程需求变更的风险来源于未曾明确的变更过程或采用的变动机制无效或不按计划的过程来做出变更。需求变更过程包括对变更的影响评估，提供决策的变更控制委员会，以及支持确定重要起点步骤的工具。

原创 运用风险管理来提高对造成项目损失的条件的警惕

精明的管理者不仅能认识到它能带来风险的条件，而且将它编入风险清单，并依据以往项目的经验估计其可能性和影响。我曾说服管理人员把项目延期是由于缺少用户的积极参与，我告诉他们不能把公司的资金投入一项注定要失败的项目。周期性的风险跟踪能使管理人员保持对风险危害变化的了解，对那些并未得到完全控制的风险能得到高层管理人员的注意。即使不能控制项目可能遇到的所有风险，风险管理也能使你看清形势，做出的决策是有所依据。• 明确你当前项目面临的一些与需求有关的风险，不要把当前的问题当作风险，一定要是那些还未发生的事情。

原创 与需求有关的风险

记录你参与的每个项目中实际需求开发的工作量，这样就能知道所花的时间是否合适并改进将来项目的工作计划。3) 需求规格说明的完整性和正确性为确保需求是客户真正需要的，要以用户的任务为中心，应用使用实例技术获取需求。9) 给出期望的解决办法用户推荐的解决方法往往掩盖了用户的实际需求，导致业务处理的低效，或者给开发人员带来压力以至做出很差的设计方案。确定出主要的客户，并采用产品代表的方法来确保客户代表的积极参与，确保在需求决定权上有正确的人选。7) 未加说明的需求客户可能会有一些隐含的期望要求，但并未说明。

原创 与需求有关的风险-需求分析

1)需求理解开发人员和客户对需求的不同理解会带来彼此间的期望差异，将导致最终产品无法满足客户的要求。2) 时间压力对T B D的影响将S R S中需要将来进一步解决的需求注上T B D记号，但如果这些T B D并未解决，则将给结构设计与项目的继续进行带来很大风险。3) 具有二义性的术语建立一本术语和数据字典，用于定义所有的业务和技术词汇，以防止它被不同的读者理解为不同的意思。3) 不熟悉的技术、方法、语言、工具或硬件平台不要低估了学习曲线中表明的满足某项需求所需要的新技术的速度跟进情况。

原创 SQL Server 2022常见问题解答

检查系统要求：确保操作系统为 Windows Server 2016+ 或 Linux 受支持版本，内存 ≥ 2 GB。通过系统化的问题分类与主动监控，可显著降低 SQL Server 2022 的运维风险。：SQL Server 2022 默认强制使用 TLS 1.2，旧客户端驱动不支持。：操作系统版本不兼容、硬件资源不足（如内存/磁盘空间）、权限问题。：数据库兼容级别过低、已弃用功能（如旧版备份加密）。：新版本优化器行为变化、统计信息未更新、索引失效。：长时间未备份日志、复制/CDC 未清理。

原创 Android Studio常见问题解决

Android Studio 作为主流的 Android 开发工具，虽然功能强大，但在使用中常会遇到各种问题。通过合理配置工具链、及时更新版本，并善用日志与社区资源，可高效解决大多数 Android Studio 问题。：依赖下载被墙（如 Google Maven 仓库）、Gradle 版本缓存问题。：自定义 View 或主题兼容性问题、Android API 版本不匹配。：库版本不一致、Gradle 插件与 Gradle 版本不匹配。：JDK 版本不兼容、系统内存不足、磁盘权限问题。

原创 VMware安装Ubuntu实战分享

自动安装： 虚拟机菜单 → 安装VMware Tools → 挂载虚拟光驱 tar -xzf /media/ubuntu/VMware\ Tools/VMwareTools-*.tar.gz -C /tmp cd /tmp/vmware-tools-distrib/ sudo ./vmware-install.pl -d # -d 表示默认选项自动安装 # 验证： sudo apt install open-vm-tools-desktop # 补充安装图形驱动 reboot。

原创 JavaScript性能优化实战

性能优化需要结合具体场景进行权衡，建议通过Chrome DevTools的Performance面板进行运行时分析，优先解决对用户体验影响最大的瓶颈点。// 仅渲染可视区域DOM元素（使用 IntersectionObserver 实现）list.appendChild(item);// 每次都会触发重排。// WeakMap 中的条目会自动清除。// 组件销毁时未清除。// 渐进式注水（Progressive Hydration）// 触发强制同步布局。// 使用 OffscreenCanvas。

原创 Keil5调试技巧

（Memory Access Breakpoint）：监控特定内存地址的读写操作（如检测数组越界）。：查看函数调用链，快速定位程序崩溃或异常的位置（如 HardFault 时回溯调用路径）。：查看当前触发的异常（如 HardFault、MemManage）及上下文信息。：查看外设寄存器状态（如 GPIO、UART、TIMER），确认配置是否正确。：手动添加变量或表达式，实时查看其值（支持十六进制、十进制等格式）。：查看代码覆盖率，确保测试充分（需在工程选项中启用）。），变量可能被优化掉。

原创 Keil5安装全攻略

其他资源：部分芯片厂商（如 ST、NXP）会提供定制版 MDK 安装包（含对应芯片支持包）。检查调试器驱动是否安装（如 ST-Link 驱动需从 ST 官网下载）。操作系统：Windows 7/10/11（推荐 64 位）。硬盘空间：至少 4GB（根据芯片支持包大小可能增加）。驱动（若已安装其他调试器驱动，无需重复安装）。，确认设备连接正常（SWD/JTAG 接口）。：安装时暂时关闭杀毒软件（可能误删破解文件）。：使用版本管理工具（如 Git）备份关键代码。检查芯片是否处于低功耗模式（尝试复位芯片）。

原创 需求管理过程的积累材料

3) 需求变更影响分析清单和模板估计提出的需求变更的成本费用和影响是决定是否执行变更的重要步骤。2) 变更控制委员会过程变更控制委员会( C C B )是由风险承担者的主要成员组成的，对提出的需求变更决定执行哪一项，拒绝哪一项，以及在各产品发行版本中包括哪些变更。C C B的主要活动是对提出的变更进行影响分析，为每项变更作出决定，并且告知那些将受到影响的人。5) 需求跟踪能力矩阵模板需求跟踪能力矩阵列出了S R S中的所有功能需求及相应的设计模块，源文件和实施需求的过程，还有验证需求实施正确性的测试用例。

原创 需求开发过程的积累材料

3) 需求分配过程把高层的产品需求分成若干特定子系统是非常重要的，尤其是当开发的系统既含有软件又含有硬件或是包括多个子系统的软件产品时尤为重要（ Nelsen 1990）。需求分配是在系统级需求完成和系统体系结构确定后才进行的，这个过程包含的信息是怎样执行分配以确保功能分配到合适的系统组件中，同时也说明分配的需求怎样才能追溯回它们的上两级系统需求以及在其它子系统中的相关需求。另外，你也可将使用实例与S R S模板合并为一个文档，既包括产品的使用实例，又包括软件功能需求，第8章介绍了一种使用实例模板。

原创 新时代人的觉醒

二十知天命，三十开始觉醒。如果寿命还在，四十而立，六十不惑，七十重新知天命。大学高中化，硕士本科化，博士职业化大专化，除了毕业用的那个算法别的都不会。

原创 软件过程改进的基础

我的意思并不是要人为地制造痛苦（比如管理者强加的进度压力使开发人员工作异常痛苦），而是你曾在以前项目中经历过的真正艰辛。1) 改进过程应该是革命性的、彻底的、连续的、反复的不要期望一次就能改进全部的过程，并且要能接受第一次尝试变更时，可能并没做好每一件事。当你有一些新技术的经验后，可逐渐调整你的方法。3 ) 过程变更是面向目标的在开始运用高级过程之前，先确保你知道变更的目标。任务纳入工程项目的总计划中。的改进，缩减改进项目的规模。行计划的情况，看是否获得了预期的资源并知道改进过程实际消耗的费用。

原创 需求开发过程的积累材料

3) 需求分配过程把高层的产品需求分成若干特定子系统是非常重要的，尤其是当开发的系统既含有软件又含有硬件或是包括多个子系统的软件产品时尤为重要（ Nelsen 1990）。需求分配是在系统级需求完成和系统体系结构确定后才进行的，这个过程包含的信息是怎样执行分配以确保功能分配到合适的系统组件中，同时也说明分配的需求怎样才能追溯回它们的上两级系统需求以及在其它子系统中的相关需求。1) 项目视图与范围模板项目的视图与范围文档明确了项目的概念性功能，并提供了确定需求优先级和变更的参考。

原创 改进需求过程-需求与其他项目过程的联系

采用设计评审的方法来确保设计正确地反映了所有的需求。而代码的单元测试能确定是否满足了设计规格说明和是否满足了相关的需求。产品的需求是编写文档的重要参考，低质量和拖延的需求会给编写用户文档带来极大的困难。通常，项目计划指出所有希望的特性不可能在允许的资源和时间内完成，因此，需要缩小项目范围或采用版本计划对功能特性进行选择。2) 项目跟踪和控制监控每项需求的状态，以便项目管理者能发现设计和验证是否达到预期的要求。3) 变更控制在需求编写成文档并制定基线以后，所有接下来的变更都应通过确定的变更控制过程来进行。

原创 软件需求对其他项目风险承担者的影响

如在改进过程中需要获得合作时，可以从这样的谈话开始：“这些是我们曾经经历过的问题，而我们认为进行这些变更将会有助于问题的解决。反对变更是由于害怕变更带来的影响，因此要指明你进行的过程变更所可能带来的影响，从而减少大家的恐惧感。许多反对是由于不了解情况而引起的恐惧所造成的，因此一开始就要给他们说清楚为什么要作这些变更，变更后他们将受到怎样的影响，将会带来什么好处以及为什么你在过程改进一开始就需要他们的参与等等。而实际上，它提供了结构化和有条理的变更过程，并使得知道的人能作出更好的业务决定。

原创 需求工程-需求管理

4) 跟踪所有受需求变更影响的工作产品当进行某项需求变更时，参照需求跟踪能力矩阵找到相关的其它需求、设计模板、源代码和测试用例，这些相关部分可能也需要修改。2) 建立变更控制委员会组织一个由项目风险承担者组成的小组作为变更控制委员会，由他们来确定进行哪些需求变更，此变更是否在项目范围内，估价它们，并对此评估作出决策以确定选择哪些，放弃哪些，并设置实现的优先顺序，制定目标版本。保存每项功能需求的重要属性，它包括状态（如已推荐的，已通过的，已实施的，或已验证的），这样在任何时候都能得到每个状态类的需求数量。

原创 需求工程-需求验证

当你阅读软件需求规格说明（S R S）时，可能觉得需求是对的，但实现时，却很可能会出现问题。3) 编写用户手册在需求开发早期即可起草一份用户手册，用它作为需求规格说明的参考并辅助需求分析。优秀的用户手册要用浅显易懂的语言描述出所有对用户可见的功能。1) 审查需求文档对需求文档进行正式审查是保证软件质量的很有效的方法。组织一个由不同代表（如分析人员，客户，设计人员，测试人员）组成的小组，对S R S及相关模型进行仔细的检查。4) 确定合格的标准让用户描述什么样的产品才算满足他们的要求和适合他们使用的。

原创 需求工程的推荐方法-需求获取

这对于内部信息系统的开发是最易实现的，因为此时，用户就是身边的职员。5) 建立起典型用户的核心队伍把同类产品或你的产品的先前版本用户代表召集起来，从他们那里收集目前产品的功能需求和非功能需求。2) 编写项目视图和范围文档项目视图和范围文档应该包括高层的产品业务目标，所有的使用实例和功能需求都必须遵从能达到的业务需求。10) 通过检查当前系统的问题报告来进一步完善需求客户的问题报告及补充需求为新产品或新版本提供了大量丰富的改进及增加特性的想法，负责提供用户支持及帮助的人能为收集需求过程提供极有价值的信息。