workflower的博客

回想一下，在化学制品跟踪系统中有一个主要功能是允许称为请求者的操作员提出对化学制品的请求，这一请求可以由化学制品仓库中的存货清单来执行完成，也可以通过向外界供应商发出订单来执行完成。这样的系统是有限状态机的例子。实时系统的状态转换图除了包括一个空闲状态外，与图1 0 - 3所示的相类似，在这种系统中，当系统不再执行其它处理时就返回空闲状态。当“化学制品跟踪系统”的用户代表评审最初的化学制品请求的状态转换图时，他们发现有一个不必要的状态，另外有一个必不可少的状态但分析者却没有记录，还有两个不正确的转换。

需求案例原文来自：Component and Connector Views in Practice:An Experience Report。戴姆勒汽车设计需求案例的补充材料。

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

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

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

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

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

把高水平的需求人员组织起来，通过良好的信息交流，了解应用领域并有效地应用需求工程中的成熟技术。2) 培训软件需求的用户代表和管理人员参与软件开发的用户代表应接受为期一天左右关于需求工程的培训，开发管理者和客户管理者也应参加。这样的培训将使他们明白强调需求的重要性，以及忽略需求带来的风险。这能减少误解及工程中的返工。4) 编写项目术语汇编为减少沟通方面的问题，编一部术语汇编将项目应用领域的专用词汇给予定义说明，既要包括那些有多种含义与用法的术语，也要包括那些在专用领域和一般使用中有不同含义的词。

建立原型的主要原因是为了解决在产品开发的早期阶段不确定的问题。• 明确并完善需求原型作为一种需求工具，它初步实现所理解的系统的一部分。用户对原型的评价可以指出需求中的许多问题，在你开发真正产品之前，可以最低的费用来解决这些问题。• 探索设计选择方案原型作为一种设计工具，用它可以探索不同的用户界面技术，使系统达到最佳的可用性，并且可以评价可能的技术方案。• 发展为最终的产品原型作为一种构造工具，是产品最初子集的完整功能实现，通过一系列小规模的开发循环，你可以完成整个产品的开发。

如果有可重用的机会出现，同时你又能调整你的需求说明，那就能降低成本和节省时间，而不必严格按原有的需求说明开发。权利# 6：要求开发人员对需求及产品实施提供建议，拿出主意通常，客户所说的“需求”已是一种实际可能的实施解决方案，分析人员将尽力从这些解决方法中了解真正的业务及其需求，同时还应找出已有系统不适合当前业务之处，以确保产品不会无效或低效。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的，所以，你有权利要求开发人员通过分析给出一个的确真实可信的评估，包括影响、成本和得失等评估。

一些很忙的客户可能不愿意积极参与需求过程（也即，他们不太接受软件客户需求义务书），而缺少客户参与将很可能导致不理想的产品。如果遇到分歧，通过协商以达成对各自义务的相互理解，这样能减少今后的摩擦（如一方要求而另一方不愿意或不能满足要求）。双方的管理者都只想自己的利益而搁置用户提供的需求从而产生摩擦，在这种情况下，不会给双方带来一点益处。软件客户需求权利书列出了十条关于客户在项目需求工程实施中与分析人员、开发人员交流时的合法要求。而软件客户需求义务书也列出了十条关于客户在需求过程中应承担的义务。

在必要时或为维护每一需求变更历史记录时，应该修订S R S。这就要求每项需求要独立标出，并与别的需求区别开来，从而无二义性。应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（ f i n e - g r a i n e d）的方式编写并单独标明，而不是大段大段的叙述。第1 8章将详细说明需求的可跟踪性。遗漏需求将很难查出。在开始开发之前，必须解决需求中所有的T B D项。一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。

做出正确判断的参考是需求的来源，如用户或高层的系统需求规格说明。若软件需求与对应的系统需求相抵触则是不正确的。只有用户代表才能确定用户需求的正确性，这就是一定要有用户的积极参与的原因。为避免不可行的需求，最好在获取（ e l i c i t a t i o n）需求(收集需求)过程中始终有一位软件工程小组的组员与需求分析人员或考虑市场的人员在一起工作，由他负责检查技术可行性。对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。

水文管理与用水追踪系统的软件需求规范-基于地理信息系统的技术应用与需求分析

用例描述和工作流模型通常在不同的抽象层次上运行，这是有意为之的，因为它们在系统分析和设计中有着不同的目的。用例是问题空间工件（更接近利益相关者的需求）。重点： 它们是可视化的（如 BPMN、UML 活动图），强调流程、任务、决策和依赖关系。抽象程度： 通常是高层（如 “用户下订单”）或中层（如参与者与系统之间的逐步交互）。抽象程度： 通常更细化（如 “验证付款 → 更新库存 → 通知发货”）。用例描述中的需求和工作流模型的设计几乎不在同一抽象层次上。重点： 它们是文字性的，强调用户目标、场景和功能需求。

ClarusClarusFigure 4 –ClarusClarusClarusJune 2005DraftPMP01.00July 2005FinalPMPClarusClarusClarusClarusClarusClarusClarusTheClarusClarusClarusClarusClarusClarusClarusClarusClarussystem.ClarusClarusClarusTheClarus。

1Marc Weber23None56process.7tampering.891011121314151617>>>3. OrderPicture 1John Doe02/9918192021same time.pages.22site.23knowledge.242526Goal:

遇到页眉自行删除（Inventory Management Software Requirements Specification Version 2.00）遇到页脚自行删除（如：Confidential and Proprietary Page 2 of 62 October 1st, 2009）

Staffsystem;

03/15/20041.003/22/20041.11.2FinalCUCECFSIDOLIJISLEAOCAPALMSAPTFIDDefendantMagistrate。

1.0>GUICPUSGEwithinCapacity。

Product Features: Account Management (AM) (High Priority): AM allows users to create, edit, and view accounts information. It also allows the user to login/out of the system.Search Engine (SE) (Medium Priority): SE is the tool that assists the user in find

Goal:Actors:CustomerSystemTriggers:cart.Actors:CustomerTriggers:methods.

包含状态（State）、转换（Transition）、动作（Action）、守卫条件（Guard）。包含协议状态（Protocol State）、协议转换（Protocol Transition）。使用前置条件（Precondition）和后置条件（Postcondition）约束操作。：明确状态转换时的具体动作（如启动电机、播放声音）。示例：订单处理（“已支付”状态执行扣款逻辑）。（What），如操作合法性、协议顺序。（How），如执行动作、处理事件。，执行动作“加载文件内容”。，执行动作“启动电机”。

然而，许多能够访问装备有P H P服务器的人没有重新编辑P H P的权限，因为他们只是能够使用服务器的空间，所以还没有足够的权限，或者另外可能的原因是P H P的某种特定设置。通过这一点，每一个聊天进程在共享存储器中寻找自己的变量，无论什么时候它找到用户输入区域设置的变量，它就指定一个数据库的查询。当创建一个为广泛传播而设计的应用程序时，要时时提醒自己并非每个人都有和你相同的设置—可能也没有重新创建你的非常特殊设置的可能性。虽然P H P 9 9 %是不依赖于系统的，但是仍然有一些是依赖于系统的。

既然主进程是基于事件的，我们要不断的获取应用程序的控制权，做我们希望做的事情。p h p I R C具有空闲的回调特性，这个特性是在p h p I R C没有事情可做的时候才调用的，它仅仅是在等待网络传来消息。我们的情况就是需要能连接一个运行的进程和另一个短程进程的接口。而且它还会造成数据丢失，因为在退出和再登录的这段时间中，可能有许多信息已被传送了（这对于刚登录的用户来说是看不见的）。因此，我们至少需要两个独立的进程：一个处理不允许干扰的I R C信息交流，另一个从用户那里接收输入信息。

如果一个聊天服务器在同一时间被许多用户访问，耗掉所有的物理内存并开始使用映像内存，这时操作系统必须不断的在部分物理内存和映像内存之间交换数据（因为程序不能在映像内存中执行），这就造成了一个死循环：操作系统通知在映像内存中的一个进程需要运行，并把它加载到物理内存中，但是又要把另外一个运行着的进程从物理内存中放到映像内存中。当然，也有多成分文档和自动刷新，但是这些选项在网页再次加载时都引入一个非常令人讨厌的跳动，它需要一个输出的数据库缓冲区，而且由于不断的从服务器传来的重新连接和数据而造成了延迟。

在设置的过程中，这个应用程序不得不为每一个要处理的事件（例如：输入的私有信息、输入的服务器信息等等）注册一个回调动作。这些函数可以依次进入p h p I R C中的另外一个空闲循环中，以等待另一次事件的发生，或者它们可以使用p h p I R C的应用程序接口在网络上执行某种特定的功能（发送私有信息、加入/离开通道等等）。这个非常基本的布局允许下游的信息交流，这意味着p h p I R C能够接收来自于其他用户的信息。p h p I R C构成I R C用户端的部分应用程序，它还负责所有的网络信息交流。

只要有一个事件被发送过来，所有的要处理要刚才发生的这个事件的过程就被调用，调用时使用这个事件指定的参数（例如：输入的网络信息流的打包数据）。另一方面，如果外来的产品不能够改善自身或者不能跟得上时代，你自己受制于外来的产品已经被证实是非常消极的，就像项目中有BUG一样是不正确的。代码开放的产品的改进和扩展速度非常快，通常面向于通用的和开放的很有潜力的标准。• 程序的任何部分都可以引发任何种类的事件，因而加强了在这个应用程序中对任何类型的事件的处理能力（换一句话说，你可以从你的代码的任何部分来控制其他部分）。

这是我们实际上介绍给大家的东西，但这并不是要大家去做，因为这些是不必要的，现在各个系统已经有了许多很好的服务器软件。那么怎样使用现有的服务器？因此，我们要做的唯一事情就是去编写这个客户端的软件，另外，在我们的互联网服务中客户端也需要这个软件。I R C知道所有设置一个完美的聊天程序所必需的命令，这个网络问题可以通过使用标准的服务软件来解决，这些软件就像架上的书一样唾手可得。既然这个聊天程序只是通过H T T P与它的用户交流（没有被过滤），那么只有这个聊天服务程序本身需要一个到I R C服务器的开放连接。

如果一个服务器的连接超过它的剩余容量，它可以采用比其他服务器多的叶结构（连接许多叶节点到只有一个小的中枢服务器上是没有意义的）。但是如果波兰自己没有海外连接的话，从法兰克福到波兰的这个路径的连接就需要找到其他的出口到达大洋彼岸—它可以绕到其他国家（甚至是两个，三个或者更多的国家）直到它找到一个自由的海外连接为止。I R C的R F C和互联网上所有开放的标准相似， I R C协议的基础是在一个R F C（Request For C o m m e n t s）中指定的。• 允许I R C的用户连接。

虽然I R C要求在每一个参与聊天的用户系统上安装特殊的用户软件，但是我们可以利用这种要求，使其转化为我们软件的优势：我们为什么不在服务器端提供一个用户软件，然后使用一个H T M L接口把它抽象化，并且允许每一个用户通过H T M L的客户端获得这些软件呢？在网络使用的颠峰时刻，如果服务器A加载时出现了问题，或者出现了未知的事件，仅仅只需连接到服务器B上，动态地建立一个服务器连接，然后进入现有的聊天室（I R C允许你这样做，而且是全自动的）—现在你就可以给额外的用户提供另外一个拥有足够空间的服务器。

当然，要素并不一定是有形的事物，一些无形的事物也可以是系统的要素。事实上，当你想罗列出一个系统中的所有要素时，你会发现那几乎是一项不可能完成的任务。构成系统的要素是比较容易发现的，因为它们多数是可见、有形的事物。如果更仔细地观察，你还会发现其中有一些更小、更具体的单元，如流动着液体的叶脉以及叶绿体等。为避免这种情况，你应该从细究要素转向探寻系统内在的连接关系，即研究那些把要素整合在一起的关系。素，并进而细分为子子要素，但很快，你就会迷失在系统中，正如人们所说的“见树不见林”。

当一个生物死去，使其成为一个有机系统的多种连接死去，使其成为一个有机系统的多种连接不再产生作用时，它就丧失了作为一个系统的存在状态，尽管它仍是一个更大的食物链系统中的组成部分。系统会产生各种变化，对各种事件做出反应，对各种错误或不足进行修补、改善和调整，以实现其目标，并生机勃勃地生存下去，尽管很多系统本身可能是由各种无生命的要素构成的。再如，一支足球队是一个系统，它的要素包括球员、教练、场地和足球等;因此，一个系统中可能包含很多子系统，而它也可以嵌入到其他更大的系统之中，成为那个更大的系统中的一个子系统。

参见：

Data FlowData Flow。

运用混合智能框架HITL4SE（Human-in-the-Loop for SE），当检测到以下指标时触发人工介入： ① 需求模糊度指数≥0.67 ② 领域术语消歧失败 ③ NFR实施成本预测差异>35% 通过配置参数化审批阈值实现流程柔性控制。当前技术代际内，大模型可承担软件需求密集型工作中约55-68%的初级分析任务，但需求确认与价值权衡的本质仍属人类工程师的核心领域。当系统状态空间超过10^6（McCabe复杂度≈45）时，大模型生成代码的正确性下降曲线斜率骤增（DARPA 2024报告）

实验表明，经过优化的Prompt可使LLM的需求理解准确率提升28-35%（参照NSF 2023需求工程基准测试），通过：约束生成空间、强制推理路径、格式规范化等机制，将用户的非结构化输入有效映射到结构化需求规格。当前工业界的最佳实践（如IBM的ReqPrompt框架）证明，系统化的Prompt Engineering可将需求分析周期缩短40%，同时需求变更率降低26%。实验数据显示，采用"假设您是系统架构师，请列举这个需求可能隐含的3个非功能性需求"的提示方式，隐性需求发现率是传统访谈的2.3倍。

对比软件需求是否合格可以从以下几个方面进行验证‌：‌验证方法包括‌：‌软件需求的合格标准还包括以下方面‌：

需要强调的是，量化指标的构建应该与具体的研究问题形成闭环，避免陷入"为量化而量化"的误区。开发"需求成熟度指数"（Requirement Maturity Index），整合需求文档的完整性（100%覆盖用例）、一致性（冲突需求数量）、可验证性（可测试需求占比）等量化维度。引入"需求熵"概念，通过自然语言处理技术量化需求描述的模糊性（如模糊词汇出现频率）和复杂性（需求间的依赖关系数量）开发"需求冲突检测竞赛平台"：定期举办需求分析竞赛，使用F1-score等指标评估不同方法的冲突检测能力。