非人類演員的用戶故事和非功能性需求

Question

我有一個主要應用程序。我有兩個主要應用程序的典型人類演員，並編寫了許多用戶故事。但是爲了工作，主應用程序需要一個爬蟲程序，一個調度程序和一個管理應用程序。這些論文是否被視爲演員？我知道它們在我的主應用程序的外部，並且它們直接與它互動以實現目標，但它們不會爲非開發團隊利益相關者提供明顯的業務價值。

我也有一些關於系統如何處理不良數據的非常重要的規範，除了主應用程序本身作爲描述這些場景的參與者之外，我想不出任何人。

以上部分內容在功能和非功能需求方面進行了描述，但我不知道它們是否可以在用戶故事中進行介紹。這是預期的嗎？

我應該繼續我的課堂設計圖和順序圖以及其他地方的文檔實現細節嗎？

在許多情況下，分析（功能，非功能需求，用戶故事，概念圖......）和設計（類圖，序列圖......）之間存在這種差距嗎？如果是，你如何彌合它（例如開發者文檔，代碼評論）？

用戶故事開始減慢我的速度，因爲我知道如何做到這一點，不能遵守術語，我找不到真實世界的應用案例研究。

Answer 1

我認爲用戶故事會讓你失望，因爲如果你來自瀑布「用例」背景，他們很難掌握。

不，系統不是用戶故事中的角色，因爲故事是關於獲取價值，而這些故事沒有價值。

你說你的系統在沒有抓取工具的情況下無法工作。如果這是真的，那麼你實在無法提供任何東西，因爲一個破碎的系統顯然沒有價值。

我假設你正在研究某種形式的搜索引擎。搜索引擎不一定需要自動爬蟲才能返回結果。它當然需要一些索引。

在這種情況下，你可以有一個故事

當用戶想搜索的網站，這樣......，

建立對一個固定的，不變的用戶前端簡約的指數，但你可以有另一個故事（用於履帶）

正如我想要的搜索結果是新鮮的，以便用戶...，

再往故事

，我想搜索的PDF文件，以便用戶...「，

延長爬行。

請注意，這些故事都沒有提及抓取工具。這是通過設計。故事不應該設計一個系統，只需指定它的用途。這避免了過早的架構：如果您只是通過其目的需要某個組件，那麼您可能會發現您可以使用更簡單的解決方案，或者可以大幅延遲其實施。