需求開發管理規範及管理流程
-
目的
通過定義需求開發和管理過程,規範公司軟件開發項目的需求開發和管理活動,提高需求質量,從而提高軟件生產率,降低開發成本,改進軟件質量。
應調查用戶的需求,通過需求分析工作將用戶需求轉化為軟件需求,同時評審需求的正確性,獲得需求的承諾;應控制需求的變更,並確保項目計劃、工作產品與需求的一致性。
2.需求開發階段的工作文件
產品名稱 |
說明 |
需求開發階段計劃 |
描述需求開發階段的人員、分工、時間、主要工作內容及必備條件。 |
需求開發問題表 |
現場調研需解決的問題 |
需求開發實施日誌 |
記錄任務執行情況 |
現場調研訪談表 |
現場調研記錄(包括需求階段的會議記錄、紀要) |
現場資料收集清單 |
所有現場收集的資料清單 |
需求規格說明書 |
階段性成果、描述需求的綜合性報告 |
需求變更申請單 |
外部需求請求變更時申請,記錄變更過程 |
需求變更表 |
在形成階段性成果後編製的需求列表 |
需求階段資料彙編 |
所有需求工作產品總編目 |
3.需求開發階段工作流程
-
入口準則
項目立項、合同簽定
-
出口準則
用戶確認需求
-
輸入
用戶的需求
-
輸出
1、軟件需求規格說明書
2、需求變更表
-
主要步驟
6.1 需求獲取
1.明確需求獲取的信息。
需求分析師應在需求獲取前明確需要獲取的需求信息,以確保在實施需求獲取時有的放矢。通常需求獲取要獲取的信息包括三大類:
-
與問題域相關的背景信息(如業務資料,組織結構圖,業務處理流程等);
-
與要求解決的問題直接相關的信息;
-
用戶對系統的特別期望與施加的任何約束信息。
2.明確需求信息的來源。
需求分析師在明確了所需要獲取的信息之後,應確定獲取需求信息的來源與渠道,以提高需求分析師在需求獲取階段的工作效率,使得所收集的信息更加有價值、更加全面。需求信息的來源通常包括:
-
來自客戶的需求
-
實施所滿足的需求
-
競爭對手的產品優勢與不足
3.獲取需求信息的方法。
在明確須獲取什麼需求、需求的來源與獲取渠道後,應選擇至少一種需求獲取技術獲取相關的需求,作為需求分析的依據。需求獲取技術包括但不限於:
-
客戶訪談
-
客戶調查
-
現場觀摩用戶的工作流程,觀察用戶的實際操作
-
需求討論會
4.需求信息的保管。
根據所採用的需求獲取技術,在需求獲取過程中將產生不同的記錄和原始資料,項目組應將這些記錄納入開發庫進行配置管理。需求獲取的記錄與資料包括但不限於:
-
用戶編寫的原始需求文檔;
-
用戶填寫的需求調查表;
-
用戶訪談的訪談紀要;
-
需求研討會的會議紀要;
-
相關的政策法規文件,業務規則文件以及行業標準文件;
-
需求原型。
5.需求分析工作方法。
根據以往的工程經驗,需求分析工作方法,應該定位在”三個階段”(也稱”三步法”)。
第一階段:”訪談式”(Visitation)
這一階段是和具體用戶方的領導層、業務層人員的訪談式溝通,主要目的是從宏觀上把握用戶的具體需求方向和趨勢,了解現有的組織架構、業務流程、硬件環境、軟件環境、現有的運行系統等等具體情況、客觀的信息。建立起良好的溝通渠道和方式。針對具體的職能部門以及各委辦局,最好能指定本次項目的接口人。
實現手段:訪談、調查表格
輸出成果:調查報告、業務流程報告
第二階段:”誘導式”(Inducement)
這一階段是在承建方已經了解了具體用戶方的組織架構、業務流程、硬件環境、軟件環境、現有的運行系統等等具體實際、客觀的信息基礎上,結合現有的硬件、軟件實現方案,做出簡單的用戶流程頁面,同時結合以往的項目經驗對用戶採用誘導式、啟發式的調研方法和手段,和用戶一起探討業務流程設計的合理性、準確性、便易性、習慣性。用戶可以操作簡單演示的DEMO,來感受一下整個業務流程的設計合理性、準確性等等問題,及時地提出改進意見和方法。
實現手段:拜訪(誘導)、原型演示
輸出成果:調研分析報告、原型反饋報告、業務流程報告
第三階段:”確認式”(Afirm)
這一階段是在上述兩個階段成果的基礎上,進行具體的流程細化、數據項的確認階段,這個階段承建方必須提供原型系統和明確的業務流程報告、數據項表,並能清晰地向用戶描述系統的業務流設計目標。用戶方可以通過審查業務流程報告、數據項表以及操作承建方提供的DEMO系統,來提出反饋意見,並對已經可接受的報告、文檔簽字確認。
實現手段:拜訪(回顧、確認),提交業務流程報告、數據項表;原型演示系統
輸出成果:需求分析報告、數據項、業務流程報告、原型系統反饋意見(後三者可以統一歸入需求分析報告中,提交用戶方、監理方進行確認和存檔)
需求分析的三個階段是需求調研中不可忽視一個重要的部分,三個階段或者說三步法的實施和採用,對用戶和承建方都同樣提供了項目成功的保證。當然在系統建設的過程中,特別在採用迭代法的開發模式時,需求分析的工作需一直進行下去,而在後期的需求改進中,工作則基本集中在後兩個階段中。
6.需求分析應注意的問題。
需求說明書應該對於那些只想了解宏觀需求的領導,和需要了解細節的技術員都合適。在寫需求說明書時應該注意兩個問題:
1.最好為每個需求注釋”為什麼”,這樣可讓程序員了解需求的本質,以便選用最合適的技術來實現此需求。
2.需求說明不可有二義性,更不能前後相矛盾。如果有二義性或前後相矛盾,則要重新分析此需求。
7.獲取需求過程中的原則
原則1 永遠不要顯得比客戶更聰明
第一條:了解需求,而不是去批評客戶;
第二條:客戶比你更熟悉業務的環境;
第三條:客戶總是知道問題在哪兒,你的工作就是要讓他們自己願意說出來;
原則2 尊重用戶的現實選擇
第一條:客戶永遠是對的;
第二條:提供最合適的解決方案,而非最好或最貴的方案;
第三條:不要把客戶當傻瓜;
原則3 轉述需求的人也是客戶
第一條:轉述者一般會把自己想像成設計者;
第二條:轉述者可能會遺漏或補充一些額外的需求;
第三條:對轉述者的自由發揮不應抱怨和生氣,而是將其視為客戶;
原則4 客戶和用戶要區別對待
第一條:產品為最終用戶設計,需求的功能轉換為最終用戶的使用要求而確定;
第二條:為客戶尋找價值上的需求;
第三條:用戶的利益高於一切;
原則5 用最簡單的文字工具記錄需求
第一條:所有人都能懂的東西,最不容易出錯;
第二條:不需要再學習的東西,最不容易出錯;
第三條:不要希望客戶能花更多的時間來了解需求轉換後的模型;
第四條:保持溝通的通暢,是了解需求的保障;
原則6 天下沒有免費的午餐
第一條:客戶從來沒有不合理的需求;
第二條:客戶的要求都是可以實現的;
第三條:我們能做這事-這是所需的費用;
6.2 需求分析的內容
名稱 |
內容 |
適用性 |
功能分析 |
實現該需求軟件所須提供的功能及其含義、工作內容 |
所有需求必須,非原子級需求需給出下一級的功能結構圖 |
角色分析 |
分析該需求涉及的角色及在本需求內容的行為 |
原子級需求必須,其它可選 |
業務流程分析 |
分析該需求涉及的業務流程,以流程圖或用例圖表示,並根據需要配合一定的文字說明 |
原子級需求必須,其它可選 |
數據分析 |
分析該需求涉及數據項的名稱、含義、格式、規則。以表格形式給出 |
原子級需求必須,其它不適用 |
權限分析 |
定義各角色在該需求中的行為。以表格形式給出 |
原子級需求必須,其它不適用 |
界面分析 |
實現該需求的界面風格、表單樣式、報表格式及頁面布局。 |
報表類需求或客戶明確要求的必須,其它可在需求說明書中統一分類說明 |
性能分析 |
分析該需求的最大數據量、訪問頻度,定義用戶響應時間等要求 |
有特殊要求必須說明,其它可在需求說明書中統一分類說明 |
偶合性分析 |
分析該需求和其它需求間的相互關係及影響,與其它需求有關的應以表格詳細說明相互關係 |
原子級需求必須,其它可選 |
6.3 需求分解
按照功能結構圖進行分解,原則上以每一條完成工作的實際業務流程為一個需求最小單位(原子級需求),單個流程以下的作為該需求的功能,不向下細分。每個原子級需求必須滿足以下條件:
1)僅存在一條主要業務流程;
2)操作同一業務數據;
6.4 需求定義
1.標識需求
為了確保需求的易跟蹤、易修改,需求分析師應通過需求編號的方式唯一標識每一個軟件需求,明確需求的跟蹤粒度,並體現於軟件需求分析文檔。
編碼規則:<系統代碼>-XQ-<1級需求編號>.<版本號>[-<2級需求編號>.<版本號>…]
例:設備系統(EMS)的第一個功能”基礎數據管理”的第二個功能”供應商管理的第3版需求編號為:EMS-XQ-1.1-2.3
說明:需求編號按照合同方案中排列順序編排,如合同方案中未出現的功能需求則排在合同所列所有需求之後。
2.定義需求優先級別
需求分析師應確定每個需求的優先級並寫入軟件需求分析文檔,需求的優先級的評價標準如下:
級別 |
判斷標準 |
採取的措施 |
高 |
滿足以下任意一條時:
|
對於這些需求在項目實施過程中需重點投入資源,優先實現,只有在這些需求上達成一致意見,軟件才會被接受;必須完美地實現。通常這類需求在當前版本必須實現。 |
中 |
滿足以下任意一條時:
|
這些需求必須被實現,但如果項目實施中出現進度、資源等方面的衝突時,如果有必要,可以延遲到下一版本;需要付出努力,但不必做得太完美。 |
低 |
滿足以下任意一條時:
|
實現或不實現均可;可以在項目組有較足夠的時間時考慮這些需求的實現 |
優先級的定義有利於幫助項目組在項目的範圍、進度、資源、預算等相關制約因素之間產生衝突時,能夠正確地對需求實現的範圍或實現的優先程度做出取捨。一個實現這種權衡的方法是:當接受一個新的高優先級的需求或者其它項目環境變化時,刪除低優先級的需求,或者把它們推遲到下一版本中去實現。
3.定義需求與現有管理的差異級別(流程差異性)
需求分析師應確定每個需求實現的管理流程與客戶現行管理流程間的差異性大小並寫入軟件需求分析文檔,流程差異性的評價標準如下:
級別 |
判斷標準 |
採取的措施 |
無 |
滿足以下全部條件時: 1)現有流程和設計流程一致 |
無需過多考慮,設計時實現原流程既可 |
有 |
滿足以下全部條件時: 1)現有流程和設計流程不一致; 2)客戶認可新流程。 |
在需求設計說明書中需要反映原始流程和設計流程,並描述兩者區別及調整原因,在培訓階段應加強此部分的力度。 |
建議 |
滿足以下全部條件時: 1)現有流程和設計流程不一致; 2)雙方對新流程未達成共識; 3)我方認為新流程有先進性; 4)流程改變與否不會影響功能實現; 5)流程改變與否不會影響系統總體目標。 |
改變或不改變均可;在需求設計說明書中以原始流程為最終流程,但在需求說明書中反映建議的新流程,並描述原始流程實現後可能帶來的問題及新流程的先進性。 |
保留 |
滿足以下全部條件時: 1)現有流程和設計流程不一致; 2)雙方對新流程未達成共識; 3)客戶明確要求保留的; 4)我方堅決反對的; 5)流程改變與否會影響功能實現或者會影響系統總體目標。 |
必須改變的流程,但客戶堅決不改變的。需先和客戶負責人進行溝通,在明確客戶負責人(必須是客戶的主管高層)了解該問題並堅持的情況下,明確闡明我方持保留意見的觀點。需求說明書中應描述原始流程和設計流程,詳細說明原有流程存在的問題並註明客戶主要負責人意見,應作為該項目的重要風險優先採取措施解決。 |
4.編寫需求分析文檔
需求分析師在需求分析過程中根據分析步驟逐步編製形成《軟件需求分析文檔》(其中《產品功能列表》可作為附件提交)。編寫需求分析文檔應遵循以下規則:
-
相關的需求都得到了識別與描述,以確保需求的完整性;
-
各個需求之間不衝突,算法之間不相互矛盾,以確保需求的一致性;
-
正確描述系統需求,引用的資料有正規的出處,以確保需求的正確性;
-
定義必要的術語,適當結合圖形、結構圖等方式進行描述,以確保需求無二義性;
-
使用較好的文檔結構與需求標識,使需求能夠方便地與其它工作產品相對應,以確保需求易於追溯;
-
確保所描述的需求可以通過適當的手段得到驗證,即需求的可測試性;
-
考慮了各個層次的需求,確定了需求的優先級,以確保需求的可行性。
6.4需求確認
1.需求評審
應對所形成的需求文檔進行評審,以便作為下一階段工作的基礎。需求評審的方式為”部門評審會議”。
部門評審成員:
評審組長:項目經理
1.測試代表
2.開發代表
3.項目經理
4.客戶代表
2.需求承諾
項目經理將評審通過的《軟件需求規格說明書》提交給客戶(或客戶代表)、系統關聯項目組進行確認,確認的方式可以是以下方式之一:
直接簽字:由承諾方在評審報告上直接簽字或蓋章確認
3.建立基線
項目的軟件需求分析文檔經過評審與確認後,應根據要求建立需求基線。
6.5需求變更
對一個軟件項目來說,無論最初的需求分析有多麼明確,開發過程中的需求變化也還是不可避免的。這主要有以下幾種原因:
-
軟件所應用的外部環境發生變化;
-
隨着用戶對軟件的熟悉和應用,又提出新的需求;
-
項目組進行需求分析時未能徹底分析用戶的需求,或分析錯誤;
-
用戶在開始時不能很全面的知道所需軟件的功能。
1、需求變更申請
項目組外的需求變更,由變更申請人通過填寫《需求變更申請單》向項目組提出進行;項目組內部的需求變更通過《軟件變更申請單》提出。
當項目組接收到項目管理部門的《需求變更申請單》時,應先根據要求進行需求的評估,判斷需求的類型、分析需求變更影響到的範圍、估算需求實現的工作量(含需求、設計、編碼、測試、用戶文檔編寫)、預計可以完成的時間等內容,填寫於《需求變更申請單內部評審表》,並回復項目管理部門。若估算的開發工作量大於10人月時,項目組可以根據《立項管理過程》的要求向項目管理部提出項目立項申請;若小於10人月,且評估結果與申請部門達成共識,則開發項目組根據《變更管理規程》實施變更,若無法達成共識,則提交研發部進行最終裁定。
2、需求變更的實施
在變更完成後,若需要發佈新的需求基線,項目組應根據《S_CM000_配置管理過程》中”基線發佈”的要求重新建立需求基線,並通知相關的人員。
6.6需求跟蹤
對一個軟件項目來說,當需求確定下來以後,應該保證在軟件設計過程中每個需求都被實現,且項目的其它工作產品與需求保持一致。
需求分析文檔經過評審後,需求開發人員負責建立需求跟蹤矩陣。
在軟件開發的各階段(設計、編碼及測試),相關的開發人員應負責維護需求跟蹤矩陣。
以下文章點擊率最高
Loading…