1樓：雅痞
最後一句話文字是否有問題？沒看明白。
甲方處於被動局面的情況還真是少見，目前系統處於哪個階段呢？看題主的描述貌似是在驗收前的試執行階段，在驗收前的話，甲方肯定還是占有優勢的。
關於需求變更，比內容更重要的是變更流程，在你們的專案管理制度裡是否有變更控制和變更流程？變更流程主要包括變更的發起人、變更內容、變更評審、變更審批、變更執行。
這裡首先要明確一下雙方在溝通變更時是否是通過規範的介面人進行的有效溝通，甲方經常出現的乙個問題是很多人都在向乙方提需求，有效性，重要性，一致性都很有問題，新需求的提出最好是經過甲方內部評估，意見達成一致後再正式提出。提出後交予對方的正式介面人（如果有監理公司可以通過監理公司轉交），讓對方做出正式反饋，是否可以改，不可以改的話理由是什麼？
分析對方拒絕的原因，一般來說乙方拒絕修改主要有這麼幾種原因：超出原定需求範圍而未得到相應的資源（錢和時間）、在原需求範圍內的細化但時間不足（可能要保證剩餘主要功能的進度）、保證版本穩定性（需求提出的頻率較高，不能隨提隨修改，要積累到一定的程度進行完整考慮後再修改）。分析清楚對方拒絕的原因之後再進行有針對性的溝通和處理，也會更加有效。
如果有更具體的資訊可以繼續交流。
軟體需求分析怎麼轉產品經理或者專案經理？
Luo.David 看性格，外向點，有創意想法，對於軟體整個流程非常熟悉也願意設計軟體並且能夠說服客戶就轉產品經理。反之就專案經理，管理內部團隊，合適的崗位安排上合適的人就好了。特別注意的是，轉崗後可能需要暫時丟掉自己原來的身份，畢竟產品經理或者專案經理不能兼著需求分析的崗位的。 IT小蘭 從事企業...
軟體外包，需求分析由誰來做？
犇夢 如果甲方有能力寫需求分析，那是最好不過，需求分析是軟體開發的基礎，甲方來寫，嚴格按照該文件來開發和驗收，對雙方都是好事。但是大部分甲方都不具備需求分析編寫的能力，這就要求乙方來寫，甲方負責確認，這種情況下，甲方要提前把自己想要的功能描述清楚，比如做O2O，接單的規則是什麼樣的，平台收費規則是什...
軟體測試，黑盒測試能否發現需求的錯誤？
Arnold 可以，基本上在公司，你所經歷的第乙個階段就是需求評審。在需求評審的過程中，你就要盡力發現需求文件中的錯誤。之後你憑什麼需求之後下來肯定要寫測試計畫，或者說是有你的領導來編寫測試計畫。然後按照測試計畫來編寫測試用例。編寫完測試用例之後，就執行這些測試用例去發現軟體的錯誤。那麼很顯然，首先...