要求和技術設計作爲一項努力？

Question

我一直在做一個大型的，多年的項目作爲網頁設計師。

到目前爲止，我的責任是提取客戶分析師提供的需求文檔，並將其轉化爲技術設計文檔。

'權力是'建議我接管需求文檔，並將它們與我在技術設計上的努力結合起來。

在將要求和技術設計合併到一個步驟中時是否存在特定問題？

請注意，我們已經很好地進入開發階段，所以很多技術選擇（操作系統，應用程序框架，數據庫，服務器等）已經成爲現實。

Answer 1

「您是否遇到了將需求和技術設計合併爲一個步驟的特定問題？」

是的。

要求幾乎與技術設計無關。

需求定義「什麼」必須發生。設計解釋了它將如何構建以實現這一目標。

例如，我想要一杯啤酒 - 這是我的要求。

技術設計可能是

1. 下車我的椅子走下樓。低成本。這裏有風險。可能沒有啤酒。

2. 下車，走到酒吧。成本更高。這裏風險很小。除週日關閉。

3. 問我的妻子。這裏有巨大的風險。可能的意外後果。然而，我已經委託了這個問題，她現在不得不在房子裏找啤酒，跑到商店，或者告訴我要自己買。如果她無論如何要外出，我們會回到低成本，沒有風險。

一個要求。解決方案的多種設計。 你無法在一個步驟中同時處理這兩件事情。

必須文件的要求（演員，用例，概念數據模型，概念處理模型）

然後你必須設計一個解決方案。解決方案可能 - 也可能不 - 涉及創建新軟件。

在學習要求時，你經常會發現用戶需要改變他們工作方式的情況。要求可以通過多種方式來滿足。

一個人既可以記錄要求，也可以進行設計。但你必須分開做。您必須以用戶理解並同意問題性質以及宣佈解決問題所需的方式來記錄需求。

然後 - 單獨決定如何最佳地優化成本，風險，交付時間，技能和可用技術，以便爲問題提供一些解決方案。

Answer 2

如果你「很好的開發」，我希望大多數的需求都相當穩定。我並不認爲在開發開始之前（天堂禁止）需要將需求置於石頭上，但我希望能夠確定你到底在做什麼樣的事情。因此，如果現在的觀點只是「需求文檔」（而不是真正挖掘客戶的需求），我看不出任何深層次的問題。

儘管將開發與「客戶倡導」角色分開有一定的優勢，但專業開發人員不應該在追蹤需求時不會產生任何利益衝突。還有其他一些你關心的問題嗎？在這一點上，需求文檔是一項大任務嗎？減少客戶和開發者之間的層數實際上聽起來像是一件好事。

Answer 3

我認爲在由同一個人完成需求和設計方面有很大的價值。

如果您正在獲得要求，那麼您實際上正在與業務交談。它會給你一個學習生意的機會，並聽取他們真正需要的東西，沒有變化，沒有過濾。您將有機會說服他們用商業術語談論問題，而不是假設技術解決方案並跳躍設計（例如，「將此列添加到此表並將其綁定到此頁上的此文本框中」。 ）也許你會看到攻擊他們甚至不知道存在的問題的方法。

Answer 4

我沒有機會在敏捷團隊或Scrum團隊工作，也沒有機會應用他們。我爲客戶做了大量的一次性開發工作1〜3個月。但有一兩件事，我在這種環境下，當得知是：

項目的每一個階段，簽署與客戶。

這將回答你的問題： 永遠不要混淆需求和設計文檔。

實際上，它超越了這一點。

1. 首先，簽署工作範圍（SoW）。
2. 然後，簽署要求。

我們很多時候看到不合理的客戶，他們不斷變化的要求。但是，他們不希望爲這些變化付費。如果管理不當，項目成本將大大超過並超過項目收入。

擁有已簽名的SoW可以保護您不受範圍要求的影響，例如。 「供應商將安裝應用程序xxx」，並且突然間，「客戶希望安裝完整的PKI基礎設施以保護與應用程序xxx的通信」。

有一個簽署過要求保護您免受突如其來的，不合理的規定，從上面下了類似的情況，「沒有必要保護和加密通信應用XXX」。

請注意，這些是法律保護。您應該決定是否應該完成客戶的新要求。然而，強調他們不符合要求並純粹是出於善意，這仍然是件好事。

將設計文檔合併到主要需求文檔中會阻止您簽署需求文檔。客戶會對此非常高興，但我認爲您的開發團隊會討厭可能的緊縮時間。

我確實看到了人們可以採用的另一種方法（但並未將設計與需求合併）。

將需求文檔拆分爲具有獨立附錄文件的主文件。在要求文件中保留重要和具體的東西。這允許您簽署需求文檔，同時允許在稍後階段更改附錄。作爲附錄，我們主要使用這種方法作爲支持文檔。它可能與設計文檔一起作爲附錄，但我沒有看到作爲附錄的設計文檔。

此外，在某些項目中，您甚至可能希望在開發開始前簽署設計文檔。或者這些設計/需求/ SoW是交付或里程碑付款。

真的，儘量避免合併它們。

Answer 5

要求參考什麼需要完成。 技術設計是指如何滿足的要求。

缺點：

• 一個結合他們的缺點是 ，如果你是一個技術傢伙， 你會盡力影響 要求做出的技術 任務更容易，着眼於如何。在 結尾中，您可能會開發一個系統 ，該系統實際上並未解決（全部） 系統的用戶問題。
• 另一個缺點是，雖然 明確要求， 技術解決方案將需要 適合滿足 的新功能/那是澄清 或在需求 啓發發現的細節。這意味着 在 需求說明期間多次修改/重新考慮技術解決方案。

可能的優勢：

• 擁有的技術方案的概述，而討論的要求，你可能「彎曲」或談判的要求，以避免的技術問題後發現（例如性能問題，不可行或代價高的特徵，附加值與實施它們的成本不成比例）。但在真正澄清要求之前，您必須小心，不要在技術設計上投入太多。

Answer 6

是的。將需求和技術設計結合起來可以讓你的想法變得更加複雜 - 它可以防止你後來提出關於如何通過採用不同的技術方法/優化來改進系統的新想法。

特別是在新技術領域，您可能會以錯誤的方式開始。將技術設計和需求相結合可以誘導您將技術方法視爲一種需求，並且可以很好地廢棄和完成不同的工作。

另外，當談到時間測試（其實那個時候應該是設計之前），那麼你可能會測試你的技術方法，而不是什麼porgram真正需要做的。

Answer 7

兩個另一個區別是，要求發展需要與客戶（內部或外部客戶），並廣泛接觸很多優秀的技術人員根本不具備人際溝通技巧來管理客戶關係好或交談actaul用戶無需侮辱他們。只有你可以說，如果你這樣做。如果你沒有這樣做，你會發現它比你想象的要困難和複雜得多。另外，您可能會發現自己提出錯誤的問題，因爲您無法看到用戶的觀點，因爲您的專業知識來自開發人員和設計人員的觀點。

我個人還發現，讓多個人參與設計過程（收集需求並將它們轉化爲設計）對於創意以及他人可能錯過的事物的思維方面是有幫助的。從團隊合作的角度來看，從兩個人做這個事情可能不是一個好主意。當同一個人做這兩件事情時，只用習慣的方式去做事情是很容易的，而且沒有其他人蔘與挑戰你的假設，直到你在更難以改變的道路上走得更遠。