經典案例
  • 金融大数据解決方案
  • 汽车大数据解決方案
  • 当局大数据解決方案
  • 铁路大数据解決方案
  • 电力大数据解決方案
  • 军工大数据解決方案
  • 解放军总装备部
  • 中国航天科工集团
  • 航天科技集团

軟件開發需求分析工作内容和流程

發布于:2020-01-03 21:15來源:北京軟件開發公司 作者:北京軟件開發公司 點擊:
    【北京沙巴体育怎么玩科技有限公司 ——(hivekion)是一家软件定制开发公司,专注IT产品研发与服务,坚持妥当经营、持续创新、开放合作,在安全生产、大数据处理等领域构筑了端到端的解決方案优势,为企业客户提供有竞争力的IT解決方案、 产品和服务
     当軟件開發公司在承接软件外包项目时,需求公司團隊進行項目開發,交付産品,需求分
是一個非常主要核心的過程,以是我們對需求分析進行分解。

1到用戶前的准備

1.1 构造队伍

       根据实际的工作量及其他情况,组建需求调研团队,提供办公设备,明确岗位职责、召开项目启动会。

1.2准備相應文檔

       乙方的体系分析师同甲方的需求提供职员正式接触前,订定一个询问表及需求分析计划。
       一般情况下只需要完成一个团体细节询问表,询问用户为明确需求已经完成的文档情况(如果可以在进行正式接触前可以得到并了解完成好)、营业目的、当前目标、长远目标、当前准备情况、完成的营业功能列表、将来体系操作职员的营业及电脑技术了解情况、终操作用户、当前及将来的硬件、软件及收集环境等问题。
      由軟件開發公司的体系分析师根据对营业的了解程度,适当编写各营业功能细节询问表。不过营业功能细节询问表的使用,是在营业需求调研过程中用户表明其需求后,再根据问题还没有明确的情况下再进行询问的。
      其他营业相干政策法规、技术文档、技术支持职员的通信录等也要进行相应的准备。

1.3 联系及了解用户方

      同用户进行联系并取得对方的职员名单、分工情况、权重、工作计划、工作时间、节假日安排(特别是用户公司内部的额外规定),如果可能的情况下请求也有用户的IT职员参加需求过程,实际的需求如果没有IT职员的参加,在后面的更改一般是IT职员提出的。应在需求过程中把用户IT职员的需求调研,作为营业调研中一部分。

1.4 编写计划

       根据当前情况,编写需求分析计划,明确正式开始日期,中间阶段性日期(时间段可多个,调研时间不大于3天),结束时间,职员名单,分工情况,需用户提供的帮助等。將計劃發送給用戶請其確認,在可能的情況下協調用戶和開發商的計劃,以便共同開展工作。對于計劃如果能編寫及控制到每日是好的,但是否可以達到真正可控制到日,那就看你的能力了。如果每3天爲一個中間性階段進行控制,延遲的時間可以通過加班來彌補。計劃好根據一天工作8小時進行。如果要去用戶地点地進行工作,還要准備相應的辦公工具,人手一台筆記本電腦(電源插座及網絡互連線也要考慮)是比較好的資源配置。

2需求調研

2.1 需求调研启动

      本次所说的第一日是軟件開發公司的体系开发职员到用户处正式需求调研过程的第一日。如果是异地调研,那末在第一日前一日軟件開發公司的体系开发职员应到达用户地点地,留宿,了解留宿地周边情况。好是早些休息,为第一日工作开始做好准备。一般第一日的上午是軟件開發公司的体系分析职员和用户营业需要者进行团体介绍,了解办公环境,建立需求调研过程办公环境。如果是小型项目触及职员未几(双方职员共同未几于3人),一般上午可以进行调研工作1到2小时,不然下午才能正式开始工作(也就说做计划时第1天一般只有半日的工作时间)。

2.2 调研过程

      调研的过程推荐軟件開發公司系統開發人員有專人進行會議記錄,並在每日會議結束後,當場宣布本次會議的結果,並由參加會議人員進行簽字。第二日複印或發送電子文件給參加會議人員及相關人員。以便做到有據可查,明確過程。軟件開發公司系統開發人員每周對用戶提供開發周報,告訴用戶當前開發的進展、是否有問題、是否用戶協助等,這是一個好的加強雙方溝通的方法。
      注意:在調研過程的中系統開發人員的變更會對計劃産生重大的影響,不要簡單認爲是人員更換的問題。因爲在調研過程中對業務的理解,不是通過看看文檔就可以達到。3天通過討論達到對需求理解的程序,9天對文檔的學習也不一定能達到。

2.3 三个阶段

       分析的初期,即团体分析阶段,需要得到团体意义上的轮廓需求,此时,应与客户方总工以上层次的职员进行交流,这一层次的人,对未来的体系会有完整的描绘,可以划分出子体系、及其之间的关系,这也是高级管理层对体系的期望。可以以此作为纲领性的文档指导进一步的分析,并束缚后续的分析过程,避免需求范围漫无边际的扩展;專業系統分析階段,通常,客戶單位都會有專業分工,彼此之間既相互獨立,又會在某些點上發生聯系。此階段應與客戶方專業人員進行深入的討論。這一層次的人,對自己的專業相當熟悉,對專業內的需求會非常到位,大都年富力強,有相當的閱曆和理解能力,甚至自己都可以繪制業務流圖,總結業務功能點。對他們應充分鼓勵,盡量調動其積極性;系統關聯分析階段,在各專業系統得到充分分析的基礎上,緊接著就要理清它們之間的關系,這是提拔需求檔次的關鍵階段,也是高級領導層和專業人員都關心的階段。通常,客戶單位都會有一些零散的軟件,如財務軟件,部頒軟件等,這些專業軟件都發揮著重要的作用,但都是些信息孤島,客戶會很自然的希望能把這些信息融合到整個系統中來,爲更多的人所共享。同時,也希望數據能夠在各專業系統間順暢的流動,從而減少重複勞動,提高工作服从。此階段應把總工層和專業人員调集到一起,共同理清系統間的接口。經過這三個階段,對需求的描述將比較准確和完整。

3 一般情况下需明确的问题


當前整體業務需求的目的
请求提供的需求功能列表
將來發展的設想
明確服務器、客戶機的軟、硬件及性能请求(容量、速率、可操作性等)
用戶目前相關的技術人員和業務人員情況
將來終系統操作人員的技術及業務人員情況
用戶需求的系統及用戶本身或其它系統的接口请求
用戶的其它请求

 

4 需求完全明确情况

     
       对于团体调研过后就要进行各个具体营业需求的调研,对于具体需求调研如果是用户提供的现有文档,
軟件開發公司的系統分析人員只是對業務進行了解及進行修改爲系統分析人員及業務人員全可以看懂的需求說明書,那麽這個過程就比較容易。只需系統分析人員把業務文檔看懂看明白,並且對于一些難理解的業務描述修改爲易懂(有些業務名詞有一定的專業性就要進行額外的說明)、明確進出的單據(數據項)就可以。當然編寫需求說明書具體的細節可以參見其他的衆多的書籍及文件模版。

5 需求不完全明确情况

     
       如果用户对于自己的需求在调研开始并没有完全明确,需要进行引导及细化,那末这个过程就比较麻烦了。
對于用戶本身需求不明情況下,對于業務要先從基本業務進行細化,對于不明業務或不確定業務在後面進行。對于進出的單據一般在這種情況下用戶當沒有現存文檔,這個過程只需明確單據進出的必須數據源就可以,如果做到細節,由用戶在需求調研期確定單證,是不太可能的----只是設計單據的樣式、風格就不是短時間可以完成的。對于報表也只能明確基本報表请求及數據項。一般這種情況使用原型法進行,先做一個簡單的,在簡單的上面再進行完善。對于用戶本身需求不明情況下的調研要做每日(或2到3天,多3天爲間隔)的工作(分析進展)記錄,由雙方簽字,因爲調研過程會出現爲用戶请求添加一支新業務,對新業務進行分析後,因某些原因發現不能添加。這個過程的結果是一個0,但爲證明是0這結果可能花了很長的時間。要記錄這個過程,說明調研過程中做了什麽事情,有時有些人可能會說爲什麽這麽長時間才出這點點東西,到時以便說明原因。


6 需求分析的方法

  1.  
  2. 繪制系統關聯圖,這種關聯圖是用于定義系統與系統外部實體間的界限和接口的簡單模型。同時它也明確了通過接口的信息流和物質流。
  3. 創建用戶界面原型,當開發人員或用戶不能確定需求時,開發一個用戶界面原型——一個可能的局部實現,這樣使得許多概念和可能發生的事更爲直觀明了。用戶通過評價原型將使項目參與者能更好地相互理解所要解決的問題。
  4. 分析需求可行性,在允許的成本、性能请求下,分析每項需求實施的可行性,明確與每項需求實現相聯系的風險,包括與其它需求的沖突,對外界身分的依賴和技術障礙。
  5. 確定需求的優先級別,應用分析方法來確定使用實例、産品特性或單項需求實現的優先級別。以優先級爲基礎確定産品版本將包括哪些特性或哪類需求。當允許需求變更時,在特定的版本中加入每一項變更,並在那個版本計劃中作出需要的變更。
  6. 为需求建立模型,需求的图形分析模型是軟件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。如许的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
  7. 依據分析階段確定合適的客戶方配合人員。
  8.  多方位描述同一需求
      有一些需求贯穿了从基层职员到高层领导,对此需求应该从各个角度、各个方位给以描述,总结以后才能得到完整的表达,否则可能会漏掉一些信息。这也为后续的设计工作打好基础。比如,在設備管理類軟件中,有一個概念叫"缺点",指由于材料老化或外力作用,使得設備處于不正常的運行狀態,但還沒有到立刻就釀成"变乱"的程度,但如不及時檢修,就可能出事。對于設備缺点業務,就触及到從班組人員到領導,上上下下對此都非常關心,但各層次的人關心的側重點卻不盡相同:領導關心"消缺率"(即缺点消除率)、"消缺及時率";專業人員關心缺点類型和處理方法;班組人員關心消缺工作的人員安排及時間地點。缺点的業務處理流程依賴于"設備缺点單"(用于記錄缺点及消除情況),如果僅僅局限于從由基層得到的設備缺点單上的數據結構(設備名稱、缺点發現人、發現時間、二級單位確認時間、缺点性質、安排消缺時間、消缺人員、消除日期、處理方法),無法滿足專業人員的分析请求:對設備的缺点情況按類型、零部件、型號、生産廠家等分類統計,爲設備采購時作爲選型參考、調整設備及其零部件的檢修周期以減少缺点發生的頻率等,因此需要在原來的設備缺点單上增长一些相關信息。
  1. 清晰化每一數據項
由于需求將作爲設計的基礎,弄清所有的數據項的來龍去脈對于設計是必不可少的。不能有模糊不清的地方,同時通過對數據項來源的分析,可以讓分析人員更清楚的看到數據的流動情況,也會發現一些新的需求點。
  1. 充分挖掘潛在需求
由于分析人員對軟件技術非常熟悉,一些由于技術所帶來的潛在需求對于客戶來說,一般很難被發現。不實現這些需求,對整個系統也沒什麽實質性的影響;實現這些需求,則會錦上添花。
對這些潛在需求,會有兩種處理方式:告訴客戶,客戶會得到啓發,可能進一步提出新的需求,會有一些更大膽的想法,從而擴大了需求範圍,增长了工作量,甚至會影響到工期;不告訴客戶,等客戶想到了再說。
這些需求如果對于産品軟件,可能會是一個賣點,要盡可能的去挖掘。但對項目軟件,考慮各種風險,有時候可能會回避,或對客戶隱瞞。

  1. 積累領域知識
領域知識對于分析人員很重要,這些知識的廣度和深度影響分析結果的准確性和分析進度。分析人員應該通過各種途徑去獲取這些,不斷積累,並進行比較和總結。
  1. 抱著學習與指導並存的態度
面對一個新的客戶時,分析人員首先必須抱著謙遜的學習的態度,把這看成是豐富領域知識的機會。但並非客戶單位的任何層次的人都有值得學習的東西,隨著分析人員接觸的領域客戶不斷增多,分析人員對該領域的理解也會越來越深,逐漸會成長爲領域專家,會有很多地方超過客戶對領域的理解,此時,要以自己的深入理解去指導客戶,說服客戶,甚至糾正客戶的一些錯誤的認識,得到客戶的信任與尊敬,這對迅速順利的完成需求分析會很有幫助。

7 完成需求确认



        对于需求终的确认需求先由体系开发职员对编写的文档进行内部考核及修订,然后交由用户营业职员进行确认,明确体系开发职员已经了解营业需求,并进行签字确认。


8 误区

       
       在进行需求分析的时候,容易陷入一些误区,导致分析结果不理想。

8.1 分析结果越复杂越好

      这是技术型分析职员经常碰到的情况,认为分析出错综复杂的关系,花哨的图表才能显示出分析水平高。其实,分析经常要经历"简单-复杂-简单"的过程,前一个简单表现为分析职员"认为简单";随着分析的深入,原觉得简单的问题会越来越复杂;后,经过概括、消化、分解,使得需求简单明了。

8.2 必须一次到位

      由于项目工期紧,或者客户单位地理地位偏远,不想反复去现场,希望通过一次需求分析就能得到完整的、不再改变的结果。有这类情况时,表现为分析职员对客户方配合职员穷追猛问,或坚持请求配合职员做出保证,承诺需求范围不再扩展等等。结果往往是双方关系紧张,配合职员怕担责任,提出过量的灵活的、可配置的一些请求,无端增长了后续设计和编码的工作量。一次到位的想法是不现实的,随着开发工作的进行,用户经常会提出从前没想到的需求,或者更改已有的需求。需求必然有一个迭代的过程,变是不可避免的,关键是对于变化的控制,比如通过正轨而繁复的流程提高需求变化时客户付出的代价:告知客户云云变化将会使工期延长,或需要追加资金等等,尽管对于"软件属于买方市场"的现状来说,开发方往往叫不起这个板,但如许的控制还是有一定的结果的。

8.3 客户的需求必须全部满足

      陷入这一误区的分析职员,往往自己的领域知识欠缺,对客户的需求是否合理,缺乏分辨能力,只能由客户牵着走,如许会带来很大的风险:造成需求冗余,项目返工,更有对需求变化失去控制的伤害,随着项目的开展,全部軟件開發团队会越来越痛苦。以是必须加深自己的领域知识,变被动接受为主动引导,进而拒绝客户的分歧理需求。

    【北京沙巴体育怎么玩科技有限公司 ——(hivekion)是一家软件定制开发公司,专注IT产品研发与服务,坚持妥当经营、持续创新、开放合作,在安全生产、大数据处理等领域构筑了端到端的解決方案优势,为企业客户提供有竞争力的IT解決方案、 产品和服务。
tag標簽:
------分隔線----------------------------
------分隔線----------------------------
QQ客服热线