之所以用「
**」代替，是因為我認為軟體設計、開發測試等方面太多了，我只說軟體需求這一方面。
上篇文章中提到兩個「買土豆的故事」（
）故事一中的張三和故事二中的甲，都屬於「聰明」的人，他們為老闆想得周到，老闆一句：看看市場上有賣土豆的嗎？和一句：買點土豆回來。引發了張、李和甲乙的不同的反應。但是給人比較統一的感覺就是：張和甲考慮了老闆的各種需求，做得十分完美，而李和乙卻像木頭一樣，老闆說一句做一句。對映到軟體需求的調查的時候，張和甲的表現自然很好，但是李和乙的做法也並非一無是處。聽我道來：
這四個人都犯了了巨大的錯誤：不做任何調查就去做事。老闆要土豆，但是要什麼樣的土豆、要多少土豆都沒有說，他們當時的情況是每個人都有機會和時間問清楚再出門。但是張和甲是沒有得到老闆的只是，一切為老闆「假設」好了，而實際上這些假設真的是符合老闆的需求的嗎？就說甲吧，用了乙個小時的時間把市場上的土豆情況調查的蠻仔細的，但是老闆需要什麼呢？最終老闆不買土豆，你所做的所有的努力都是白費。而乙呢？隨時和老闆溝通了，雖然老闆很煩，但是卻可以得到老闆第一手需求。至少工作不會白做。軟體開發是給使用者使用的，所有應該首先考慮使用者的需求，什麼都替使用者「假設」好了不一定是好事哦！
這是我的小小想法。
從需求分析看軟體開發的挑戰
近年來，軟體開發行業的發展勢頭非常強勁，但是不斷變化的市場需求給軟體行業的生存和發展帶來了巨大的衝擊和挑戰。在市場需求的指導下，中國軟體開發行業正在實施一系列改革措施，以確保已開發的軟體專案能夠更適合現代社會的發展需求。如果您想在第一時間掌握軟體專案的實際市場需求，就需要在開發過程中合理地進行需求分...
從需求分析看軟體開發的挑戰
至今位置，本組進行了多次高強度的線下小組討論，對這一題目的需求有了較為精準的理解。最初拿到 基於家庭工廠的訂單協作系統 這一題目時，我們五位組員對這一標題各有一些自己的簡單遐想，能夠達成的共識是系統的核心是訂單的分解分配，而無需關心消費者下單這一外部流程。從一開始能夠將系統的邊界劃分清楚，對於我們來...
從需求分析看軟體開發的挑戰
這次需求分析做的確實不如人意，在評審前本來有一次需求模型整理問答的機會，我們小組由於時間原因沒有能夠去做展示，這一定程度上導致我們的需求評審做的比較偏離重點，不過更主要的原因是我們本身沒有能夠把握好需求設計應該做些什麼。這是我們在需求方面沒有做好的地方，之後我對需求分析這部分的真正目的也進行了思考。...