這個問題很大，這篇不想再去重復一個軟件需求分析員的知識體系結構，而是挑重點來談下成為一個合格的軟件需求分析人員的關鍵點。

我原來對軟件需求的定義或描述更多是偏于對現實世界的定義，而對軟件架構的描述為現實到實現之間的第一層抽象。在這里糾正一下即：用戶需求是對現實世界的定義，而軟件系統需求是現實到實現的第一層抽象，即業務建模和軟件系統用例建模。在原來的軟件工程里面我們更多談到的一個詞是系統分析員，我現在將其拆分為了軟件需求BA和系統架構SA兩個角色。而實際上一個真正優秀的軟件需求人員必須具備兩方面的能力。

從軟件需求在整個軟件生命周期中的定位來看，其上接業務，下接設計和技術。從這個概念上來講軟件需求人員必須具備業務和技術兩個方面的能力。

對于業務，首先要解決的是對業務的理解，然后才是在理解后業務的形式化表達和業務建模能力。而對業務如何理解，最核心的仍然是頂層的流程建模和分析能力，底層的業務活動和規則清晰的描述能力。在這里里面涉及到流程梳理和定義能力，業務單據和對象的抽取和定義能力，業務規則的清晰闡述能力，和流程配套的相關的崗位角色，交互等描述能力。要知道在這塊往往并不需要太多的IT背景和軟件工程的知識，更多的是對業務的熟悉，對流程管理和分析方法的了解。

上面一步的業務更多的是屬于頂層方面的內容，而第二個層面往往會過渡到系統軟件需求層面的內容，在這里我們更加強調的是類似面向對象的用例分析和建模的方法，這包含了業務用例和系統用例分析和建模，是一種很好的形式化的方式來定義和描述業務的方法。包括從流程分析轉入到用例，單個具體的用例分析和建模，每個用例詳細的基本流，擴展流，業務規則，參與角色，界面原型，業務對象和對象屬性等各個方面內容的描述，要知道我們做用例建模的目的是能夠按用例驅動的核心，平滑的轉入到架構設計中去，因此用例分析建模已經不是簡單的描述現實世界的問題，已經涉及到業務或用戶需求到系統需求的第一層抽象轉換。

要做好需求的第二步的事情，那么單純的只有業務背景就不足夠的，必須還具備相應的IT和軟件工程的技術背景。這個背景往往并不是說要做過多久的軟件設計開發，但是只是是做過，通過軟件開發你能夠很清楚的知道一個軟件從需求調研和分析開始，最終是如何形成一個軟件系統的。這個背景知識可以更加方便我們去考慮用例建模，去認識到為何要采用這種方式去用例建模，真正理解用例中每個描述點如何影響到最終業務系統的實現。

沒有技術背景很難真正成為一個優秀的軟件需求分析師，最多也就是一個業務需求分析師。

要知道，當你進行用戶需求調研后，往往收集到的都是一個個的用戶需求點，而一個軟件需求分析員要做的是最終將這些需求實現為一個完整的業務系統。這里面就涉及到業務模塊的劃分，模塊間的分析，需求層面的復用能力分析，各種性能，可靠性，安全等非功能性需求。這些更加已經是一個完全的系統分析方面的內容，或者說軟件需求已經會兼顧部分軟件架構設計的內容，因此作為一個軟件需求人員更加需要去了解業務組件化，服務化，軟件模塊集成，復用等方面的技術內容。也需要去了解涉及到UCD，交互設計方面的內容，這些都是形成一個高質量的軟件業務系統的重要輸入。

一個優秀的軟件需求人員既不應該因為具備技術和開發背景而導致在需求分析和建模中的各種程序員思維，也不應該完全拋棄技術單純的去描述業務不管實現的難易度。軟件需求人員銜接了最終用戶和內部的設計開發，是兩者之間重要的溝通和協同橋梁。各種溝通和人際關系處理技巧，各種軟技能的要求更是必不可少的，在此不再展開去描述。

一個優秀的軟件需求人員不存在是否能做新領域的軟件需求的問題，因為最終真正有用的需求分析的方法論和模式，去理解和熟悉業務和快速形式化描述和建模的方法，有不斷的實踐總結出來的快速理解業務的能力。