我有一个主要的应用程序。我有两个典型的主要应用程序的人类演员，并编写了许多用户故事。但是主应用程序需要爬虫，调度程序和管理应用程序才能工作。这些论文被认为是演员吗？我知道它们是我的主应用程序的外部，并且它们直接与它进行交互以实现目标，但它们不会为非开发团队的利益相关者提供一些明显的商业价值。
我还有一些关于系统如何处理不良数据的非常重要的规范，除了主应用程序本身作为描述这些场景的参与者之外，我无法想到任何人。
上面的一些内容在功能和非功能要求中有所描述，但我不知道它们是否可以在用户故事中描述。这是预期的吗？
我应该继续使用我的班级设计图和序列图，并在其他地方记录实施细节吗？
在许多情况下，分析（功能，非功能需求，用户故事，概念图......）和设计（类图，序列图......）之间是否存在差距？如果是，你如何桥接它（例如开发人员文档，代码注释）？
用户故事开始减慢我的速度，因为我知道如何做到这一点，并且不能遵守术语，我无法找到真实世界的应用案例研究。
答案 0 :(得分：0)
我认为用户故事会让你失望，因为如果你来自瀑布“用例”背景，他们很难掌握。
不，系统不是用户故事中的参与者，因为故事是关于获取价值的，而这些故事没有任何价值。
您说没有抓取工具您的系统无法运行。如果这是真的，那么你真的无法提供任何东西，因为一个破碎的系统显然没有任何价值。
我假设你正在研究某种形式的搜索引擎。搜索引擎不一定需要自动搜寻器才能返回结果。它当然需要一些索引。
在这种情况下，你可以有一个故事
作为用户，我想搜索网站，以便......，
针对固定的，不变的极简主义索引构建用户前端，但是你可以有另一个故事（对于爬虫）
作为用户，我希望搜索结果新鲜，以便......，
然后是进一步的故事
作为用户，我想搜索PDF以便...“，
扩展抓取工具。
请注意，这些故事都没有提到抓取工具。这是设计上的。故事不应该设计一个系统，只需指定它的目的。这避免了过早的架构：如果您只是通过其目的而被迫要求组件，那么您可能会发现您可以使用更简单的解决方案，或者您可以大大推迟其实现。