新的需求，由需求負責人加入需求的backlog中，定期有同步會議將需求指派到某個系統設計師。
系統設計師需要了解需求的**，盡可能多的了解需求的背景資訊，這些資訊會讓自己對功能的優先順序有初步的判斷。因為乙個系統設計師可能會同時工作在多個不同的任務上，新需求的加入，需要調整任務順序。當然，後續也可能根據實際變動更新需求的優先順序。定期會有針對整個需求backlog的同步會議，主要為了需求負責人與系統設計師的資訊互通，如新需求的加入，已有需求優先順序的變動。
從需求負責人確認需求的細節，將其作為技術分析的輸入資訊。當然，這個時候的需求不一定是最終版本，後續通過系統設計師的技術分析，可能發現某些細節從技術上不能或難以實現，和需求負責人確認後，可能會被移除或更新。也可能由於市場變動，需求被相應負責人取消。難以實現的情形，如團隊的技術儲備不夠，或者需要的成本太大不可能被相關負責人接受。
指派的新需求，需要實現的功能（不僅限於功能開發，也可能是一些其他工作，如支援其他團隊做一些驗證支援）。
計畫什麼時候呈現該需求的技術分析報告。
同步會議後，系統工程師通過分析得出大概時間後，通過郵件告知（郵件主要為了有乙個正式記錄，便於追溯）。
或者，經過分析得出大概時間後，可以在下一次同步會議上說明更新。
技術分析報告，即technical analysis(ta) report。ta報告主要包括兩方面：
該需求從技術層面能不能實現。
能實現的話，大概需要的cost。這個時候的cost是乙個大概的量級，如500mhours，1000mhours。
基於需求的細節並結合自己的經驗，整理出ta report的大概時間計畫，如發生在week14，給相關的stakeholder乙個大概時間。自己需要對ta report前的整個時間進行時間段劃分，如week09檢視技術資料，week10~week13也技術人員討論和調查，week14準備ta report。
從技術層面確認需求是否可實現，能實現的情況下需要多少cost的（大概給乙個初期估計的量級）。當然這個cost後續可以根據實際情況更新，正常情況下這個更新的量級差距不能太大，如果太大，需要很strong的理由，得到相關stakeholder的認可。
ta report。
計畫什麼時候呈現該需求的可行性分析報告。
可行性分析報告，即opportunity analysis(oa) report。字面意思的話，更多的是機會分析，但這個術語應該是對需求負責人更實用，他們需要考慮市場的機會。但對系統設計師來說，可行性分析可能適合。
這個是乙個粒度較粗的分析過程，可以提供多個可實現功能的方案，並給出各個方案的優勢和劣勢。可以結合自己的經驗和團隊實際情況，給出建議的方案。
可行性分析報告，主要內容包括：功能實現的必要描述、收益描述、功能實現的原理、功能的技術複雜度、影響整個產品的哪部分、功能驗證的影響、是否依賴其他功能的實現等資訊。
這個過程可能需要軟體架構師或者軟體開發工程師的支援，因為整個產品可能有很多模組，很難做到了解每個模組的技術細節，自己分析的話可能難以在一定時間內給出結論。
之前作為軟體設計師的時候，考慮的點大概只有：功能實現的必要描述、功能實現的原理、功能的技術複雜度和功能驗證的影響。其他點都不會去考慮，其它點的考慮算是乙個面的擴充套件。
oa report。
pre-study report，詳細的預研究報告。
基於oa推薦的方案，進行更細節的技術研究，給出較詳細的技術文件描述。相對oa階段，這個過程針對推薦的方案，進行的是更細節的技術分析，細化粒度是具體的軟體模組。
梳理整個功能需求的實現，不是該階段結束的必要條件。只要有乙個完整的solution package(sp)或preliminary user story，就可以讓其進入pd階段，避免team資源的空置。
這個階段不能以軟體設計師的側重點只考慮實現階段，還包括cost，收益，可驗證性等方面。
這一過程，我的理解，對系統工程師來說是其中重要的一環。需要提供較詳細的實現說明，指導實現團隊進行具體的工作，如何開發，如何驗證等。根據計畫，stakeholder什麼時候需要驗收功能。
準備用單獨的文件詳細描述這一階段。
psr。
功能實現，專案得到交付。
這個實現階段，不只是軟體層面的功能實現，還包括功能驗證，專案驗收等過程。
為開發工程師提供必要的支援，技術，協調資源。
實現階段，一些重要點的審核工作。如，審核實現團隊對系統文件的更新，確認驗證報告的結果符合期望等。
相關的會議，如該功能的驗證case是否需要加入到legacy體系中，作為日常驗證的一部分。加入到legacy體系這個動作，就是關注功能整個生命週期的乙個動作（在軟體工程師的角度，這部分工作一直被弱化），這個動作更體現在後期維護階段。防止後續功能開發影響到該功能等情況，出現問題時可以及時發現。
支援和協調實現團隊，向stakeholder進行功能的驗收。
實現的功能，按照整個產品的發布計畫，按季度，半年等週期進行發布。 這個過程，系統工程師需要提供當前功能的必要資訊，記錄到整個產品的發布資訊中。
實際工作中，這個過程和系統設計師沒有直接聯絡。寫在這裡是為了體現需求的整個生命週期。
在後期維護過程中，出現與該功能相關的問題，需要從系統設計層面提供支援，解決問題。
我的2007雜談
回顧逝去的時光，那些並不久遠的日子，接觸的人，說過的話，經歷的情感，都似乎淡得提不起了。然而 的風風雨雨卻記憶猶新。年初遇到了這家創業型公司，公司團隊和諧 有創業激情，人脈強，是我理想的創業型公司。工作具有挑戰性，開發周期快 時間緊 任務急，有時通宵達旦。還是感覺不到累，因為是在創業。建築工人累的是...
我所知道的軟體架構
兼談軟體引擎的概念 前一久，跟朋友聊天，他強烈要求我寫一些關於軟體架構方面的文章，這幾天總算有點時間來完成此事，算是給朋友交差吧。首先宣告，我不是軟體架構方面的科班出身，也不是這方面的專家，只能算是這個方面的草根。這篇文章只是10多年來我在c c 程式設計中摸爬滾打之後的一點經驗之談，謹代表個人觀點...
分享我的iOS app 開發雜談
結果可想而知。然後，我還是能進到乙個創業型公司。我把能找到工作的原因歸咎在兩點 一 市場對ios程式設計師需求很剛性。二 我不是畢業生。第一點是至關重要的。然後我在公司的經歷，讓我覺得有點意外。1 公司重視 使用者體驗 這次的開發我覺得難點就在uitableviewcell的動態高度上。但是複雜度還...