主要解決的問題：
涉眾是否就專案設想基本達成一致，專案是否值得繼續進行認真研究。
很短，如果專案必須開發的話，那麼基本很短。
要做的工作：
1.對10%～20%的用例。（高風險和優先順序的用例）
產品：1.用例模型。
包括大部分的參與者，目標和用例名稱。
以摘要形式編寫的用例，10～20%詳細編寫的用例。
確定大多數具有影響和風險的質量需求。
2.補充規格說明書。
3.設想說明書。
4.風險列表。
5.介面原型。
6.對候選的高層架構給出建議。
7.候選工具列表。
需求管理：
一種系統的方法來尋找，記錄，組織和跟蹤系統
不斷變更
的需求。
用例2023年11月28日
14:37
應用於需求的發現和記錄工作中。
用例強調了使用者的目標和觀點。
參與者：具有行為的事物。
1.主要參與者，具有使用者目標，並通過系統的服務實現。
！使用者目標驅動用例。
2.協助參與者，為系統提供服務。！明確外部介面和協議。
3.幕後參與者，在用例行為中具有影響和利益。
場景：參與者和系統之間的一系列特定的活動和互動。
用例：一組用例的例項，其中每個例項都是系統執行的一系列活動，這些活動產生了對某個參與者而言，可觀察的返回值。
用例是文字文件，而非圖形，用例建模主要是編寫文字的活動。
用例的組成部分。
主要參與人員。涉眾及其關注點列表。
前置，後置條件。
基本流程。
擴充套件部分。
用例書寫準則
使用動詞開頭。
為每個目標定義乙個用例，除了cuid，統一為管理。
有些關注問題最好是作為非功能性需求在補充規格說明中描述，如使用者要求顯示作品列表，這樣的問題屬於可用性需求。
用例驅動開發！
補充性規格說明書
2023年12月2日
14:57
1.包括系統範圍的 urps+ ，可用性，可靠性，效能，可支援性，其他。
設想2023年12月2日
15:10
一般順序如下：
1.編寫簡要的設想草案。
2.確定使用者目標和對應的用例名稱。
3.詳細編寫一些用例，並且開始編寫補充性規格說明。
4.精化設想，對以上製品中的資訊進行概括。
論專案初始階段
今天接到手乙個以前的老專案，需要更改需求，原本的包還是有的，就是eclipse工作空間較亂，整理清楚 1，在專案跟蹤備份 2，建立新的工作空間，調整自己開發環境 3，做好修改記錄，調節領導安排 4，把握工作量 5，幫助一塊開發的同事調整工作環境，整理原先的資料，建立svn，包括共享檔案 半天的專案把...
開發過程 初始階段
剛剛學習軟體開發過程 在專案初始階段主要做如下工作 b 1 統一各專案成員對開發過程的認識 b 開發過程的流派很多 xp rup 等等，每個公司又有其獨特的開發過程 必須在專案開始前統一開發過程 b 2 專案前景文件 b 統一專案成員的價值觀，相信專案的價值 不認可的可以離開了 b 3 獲取初始需求...
Android遊戲開發初始階段建議
原文出處 獲取sdk 學習應用程式架構 學習activity生命週期 activity生命週期由android作業系統來管理。你的activity建立 恢復 暫停 銷毀都受作業系統的支配。正確處理這些事件是很重要的，這樣應用程式才能表現良好，做使用者認為正確的事。在你設計你的遊戲之前了解所有這些是如...