需求和技術設計是單方面的努力？

Question

我一直作為Web架構師從事一個大型的多年項目。

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

“存在的力量”建議我接管需求文檔，並將其與我在技術設計上的努力相結合。

將需求和技術設計整合到一個步驟中，您是否看到一個特定的問題？

請注意，我們已經處於開發階段，因此許多技術選擇（操作系統，應用程序框架，數據庫，服務器等）已經確定。

Answer 1

“將需求和技術設計整合到一個步驟中，您是否看到一個特定的問題？”

是。

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

需求定義“必須”發生的事情。 設計解釋了“如何”實現這一目標。

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

技術設計可能是

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

2. 從我的椅子上下來，步行到酒吧。 成本較高。 這里沒有什么風險。 除周日關閉外。

3. 問我老婆 這里的風險很大。 可能的意外后果。 但是，我已經下達了問題，她現在必須在屋子里找到啤酒，跑到商店，或告訴我自己買啤酒。 無論如何，如果她要外出，我們將回到低成本且無風險的狀態。

一個要求。 解決方案的多種設計。 您不能一step而就。

您必須記錄需求（參與者，用例，概念數據模型，概念處理模型）

然后，您必須設計一個解決方案。 該解決方案可能會（也可能不會）涉及創建新軟件。

在研究需求時，您經常會發現用戶需要更改其工作方式的情況。 可以通過多種方式滿足要求。

一個人既可以記錄需求又可以進行設計。 但是您必須分別進行操作。 您必須以用戶理解並同意問題性質以及聲明已解決問題的要求的方式來記錄需求。

然后-分別-決定如何最佳地優化成本，風險，交付時間，技能，可用技術，以提供針對該問題的一些解決方案。

Answer 2

如果您正在“深入開發”中，我希望大多數要求都已經確定。 我不認為在開始開發之前就必須確定要求（禁止上天），但是我希望可以確定到現在為止您正在構建什么樣的東西。 因此，如果現在的重點只是“需求文檔”（而不是真正地研究客戶的需求），那么我在這里看不到任何嚴重的問題。

盡管將開發與“客戶支持”角色分開具有一定的優勢，但是專業的開發人員應該不遺余力地跟蹤需求，而不會產生任何利益沖突。 您還擔心其他問題嗎？ 此時需求文檔甚至是一項繁重的任務嗎？ 減少客戶和開發人員之間的層數實際上聽起來不錯。

Answer 3

是。 將需求和技術設計相結合會籠罩您的思想-它阻止您以后提出關於如何通過執行不同的技術方法/優化來改進系統的新想法。

特別是在新技術領域，您很可能會從錯誤的方法開始。 將技術設計和要求結合在一起，可以使您將技術方法視為一種要求，而這種方法很可能會被廢棄並以不同的方式進行。

另外，當需要進行測試時（實際上應該在設計之前進行測試），那么您可能正在測試技術方法，而不是測試表實際需要做的事情。

Answer 4

我認為由同一個人完成要求和設計具有很大的價值。

如果您有需求，那么您實際上就是在與企業交流。 這將使您有機會學習業務，並了解他們真正需要的東西，不加任何裝飾和過濾。 您將有機會說服他們用商業術語談論該問題，而不是假設采用技術解決方案並直接進行設計（例如，“將此列添加到此表中並將其綁定到此頁面上的此文本框中。”）。 ），也許您將能夠看到解決他們甚至不知道存在的問題的方法。

Answer 5

我沒有機會在敏捷團隊或Scrum團隊中工作，也沒有機會應用它們。 我為客戶做了很多一次性的開發工作，時間為1到3個月。 但是在這種環境下，我學到的一件事是：

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

這將回答您的問題： 不要將需求與設計文檔混在一起。

實際上，它不僅限於此。

1. 首先，簽署工作范圍（SoW）。
2. 然后，簽署需求。

我們已經多次看到不合理的客戶，他們的需求不斷變化。 但是，他們不希望為這些更改付費。 如果管理不當，項目成本將大大超過甚至超過項目收入。

簽署的SoW可以保護您免受超出范圍的要求，例如， “賣方將安裝應用程序xxx”，然后突然，“客戶端希望安裝整個PKI基礎結構以保護與應用程序xxx的通信”。

遵循已簽署的要求，可以保護您免受突然的和不合理的要求，遵循上面類似的情況：“無需保護和加密與應用xxx的通信”。

請注意，這些是法律保護。 您仍然可以決定是否應該執行客戶的新要求。 不過，仍然要強調，它們不在要求之內，純粹是出於善意。

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

我確實看到了人們的另一種方法（但是沒有將設計與需求合並）。

將需求文檔拆分為帶有單獨附錄文件的主文件。 在需求文檔中保留重要而具體的內容。 這使您可以簽署需求文檔，同時允許在以后的階段對附錄進行更改。 我們主要將這種方法用於支持文檔作為附錄。 可以將設計文檔作為附錄使用，但是我沒有看到設計文檔作為附錄。

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

確實，請嘗試避免合並它們。

Answer 6

要求是指需要做什么 。 技術設計是指如何滿足要求。

缺點：

• 結合使用它們的一個缺點是，如果您是技術人員，則將着重於如何影響需求以簡化技術任務。 最后， 您可能會開發一個不能真正解決（所有）該系統用戶問題的系統 。
• 另一個缺點是，在澄清需求的同時，還需要對技術解決方案進行調整，以實現在需求獲取過程中闡明或發現的新功能/細節。 這意味着在需求澄清期間多次修改/重新考慮技術解決方案 。

可能的優勢：

• 在討論需求時對技術解決方案進行概述，您可以“彎曲”或協商需求，以避免以后發現技術問題 （例如，性能問題，不可行或昂貴的功能，增加的價值與實現成本成比例） ）。 但您必須小心，不要在真正弄清要求之前在技術設計上投入過多。

Answer 7

兩者之間的另一個區別是，需求開發需要與客戶（外部或內部客戶）進行廣泛的聯系，而且許多優秀的技術人員根本沒有很好的人際關系技能來很好地管理客戶關系或與Actaul用戶交談而不會侮辱他們。 只有您可以說是否這樣做。 如果您沒有做過，您會發現它比您想的要困難和復雜得多。 另外，您可能會發現自己提出了錯誤的問題，因為您的專長是開發人員和設計師的觀點，因此您看不到用戶的觀點。

我個人還發現，在設計過程中涉及多個人（收集需求並將其轉化為設計）對於產生想法和思考他人可能錯過的事情很有幫助。 從團隊協作的角度來看，從兩個人轉移到一個人可能不是一個好主意。 當同一個人同時做這兩種事情時，就很容易以您習慣的方式去做事情，並且沒有其他人會挑戰您的假設，直到您走得更遠，這使得改變變得更加困難。