至今位置，本組進行了多次高強度的線下小組討論，對這一題目的需求有了較為精準的理解。最初拿到「基於家庭工廠的訂單協作系統」這一題目時，我們五位組員對這一標題各有一些自己的簡單遐想，能夠達成的共識是系統的核心是訂單的分解分配，而無需關心消費者下單這一外部流程。從一開始能夠將系統的邊界劃分清楚，對於我們來說，算是開了乙個好頭，但僅有邊界還遠遠不夠，早期我們還無法定位到需求層面，更多的是在討論如何走通分解分配流程。直到第一次和老師交流，老師點出乙個關鍵的問題，即「如何吸引家庭工廠加入該系統」，同時也提醒我們，家庭工廠擁有極高的自由度，不能對其有過高的要求。自此，我們有了新的思考。
我們早期的討論中給家庭工廠這一使用者強加了較為嚴格的約束，這樣可以簡化分解分配流程，但是這違背了家庭工廠自主自由的使用者身份。所以我們考慮給家庭工廠提供更多的權力，例如家庭工廠可以對該系統上報產能，這一數值由家庭工廠自主提供，新任務到達時也依照工廠上報的產能數額進行分配。這一設定，可以讓家庭工廠安排自己流入該系統的生產能力，想同時參與多個協作系統，就可以適當調低本系統的產能設定，因為個人原因想停產休假，也允許將產能設定為0。
至於如何吸引別的工廠加入本系統，這一問題我們之前從未考慮過。當老師提出這一問題之後，我們也進行了多次討論，最終達成共識。我們認為吸引工廠加入系統的最好方式就是保證其收入的穩定，即分配任務時要盡可能雨露均沾。同時也要建立公平的獎懲機制，對於經常違約超時的工廠，需要調低它在系統內的評分，從而影響其獲取的訂單數量。而信譽良好的工廠則會有更高的評分，從而獲取更多的生產任務，達到更高的收入。
我們的**流程的設計主要體現在類圖上，核心流程均在圖中有所體現。
管理員通過介面函式uploadorder將新增訂單注入到控制器的orders陣列
訂單類的建構函式內，會呼叫函式order.generatetask，依照訂單的product陣列內容計算出tasks陣列的內容，task[idx].status均為「wait」，task[idx].orderid均為當前訂單的id，task[idx].factoryid均為null。
訂單的分配流程在控制器提供的介面內實現，將訂單注入控制器的orders陣列後需要呼叫controller.splitorder，該函式依照controller.factory.produceability的數值為末端order.task賦予factoryid，並將狀態修改為」doing」
家庭工廠完成任務並審核通過後，將會呼叫finishtask函式，該函式由controller提供的介面定義，由controller實現。該函式會修改task的status為「finish「，並通過task.orderid找到controller.orders中對應的order，對其進行下一次任務分配，若該order.task中每個任務的狀態均為「finish「，則修改訂單狀態為」finish「
家庭工廠任務超時後，會觸發failtask函式，該函式由controller提供的介面定義，由controller實現。該函式會依照controller.factory.producedability的數值和未完成任務的餘量進行任務再分配，並重新計算工廠評分。
除了分析之外，還依照分析的結果進行了部分前端**的實現，採用mock資料進行演示，效果如下。
個人認為軟體開發的大忌是尚未明確需求就開始著手進行開發，這樣的舉動會在早期有著較為不錯的成果，但很容易在中後期發現對需求理解存在偏差，從而花大量的時間去重構迭代。本組前期花了足夠的時間對需求進行分析，能夠精準定位到系統存在的價值以及需要解決的問題，同時從**實現角度整理出乙份類圖，依照這份類圖，可以很快速的梳理出核心**的邏輯並予以實現。這樣的做法雖然前期會顯得有些難以言喻，但是中後期的收益是顯著的。
同時團隊合作也是軟體開發的關鍵，五個人開發乙個專案和乙個人開發是有著明顯區別的。我們需要時刻保持每個人對這專案有著統一的看法，出現分歧就需要及時解決，否則各自開發到最後會出現難以對齊，無法聯調的現象。
需求分析是軟體開發的前提，明確了專案的需求，才能明確軟體開發的方向。團隊合作中，有必要將足夠的時間投入到需求分析階段，如此在後續**開發的過程中能夠更加清楚專案的意義和**實現的目標，磨刀不誤砍柴工便是如此。
從需求分析看軟體開發的挑戰
近年來，軟體開發行業的發展勢頭非常強勁，但是不斷變化的市場需求給軟體行業的生存和發展帶來了巨大的衝擊和挑戰。在市場需求的指導下，中國軟體開發行業正在實施一系列改革措施，以確保已開發的軟體專案能夠更適合現代社會的發展需求。如果您想在第一時間掌握軟體專案的實際市場需求，就需要在開發過程中合理地進行需求分...
從需求分析看軟體開發的挑戰
這次需求分析做的確實不如人意，在評審前本來有一次需求模型整理問答的機會，我們小組由於時間原因沒有能夠去做展示，這一定程度上導致我們的需求評審做的比較偏離重點，不過更主要的原因是我們本身沒有能夠把握好需求設計應該做些什麼。這是我們在需求方面沒有做好的地方，之後我對需求分析這部分的真正目的也進行了思考。...
從需求分析看軟體開發的挑戰
我們小組的題目是 基於訂單的家庭工廠協作系統 系統目的是幫助一組家庭式工廠通過本系統進行協同配合，共同生產和組裝，完成最終訂單。專案要求實現基於網頁或手機端的系統。就課程當前幾個關鍵的時間任務節點，我想談一談我的感悟。在需求分析之前老師首先讓我們進行了領域分析，並完成乙個領域分析報告。這個任務是本科...