從一次專業實踐談需求分析感想

2021-09-08 23:27:24 字數 1568 閱讀 4416

正式接觸軟體需求分析可能只有乙個學期多一點的時間, 一直聽說做乙個軟體最重要的是需求, 開始的時候不太在意這句話,以為只要**實現了就沒有多大的問題了。直到接觸到了現實的專案才發現這句話真的是深藏不露啊。

記得專業實踐是幫乙個老師做乙個專案,使用者是某個部隊,專案是乙個政治教育評估系統,最早的時候好像並沒有給出太多的要求,只是說做出乙個他們想要的教育評估系統的中心部分就可以了,因為不能和使用者直接交流,沒辦法直接接觸到使用者的想法,只有通過指導老師來做中間橋梁。記得那一段時間,過得真是「痛苦」。。。

第乙個版本誕生以後,以為可以交差了,沒想到,使用者中途改需求了,加了一些功能,這個軟體的原型算是「作廢」了,唉,一時間,有一種「白做了」的感覺。。沒辦法,誰讓我們答應了老師要完成呢。。。

接受了改變後,我們又一次重新分析了使用者的需求,又乙個原型產生了,沒想到。。。。

一次又一次的改變原有的計畫,一次又一次地改變原有的需求,基本上每一次都是往原有的功能上新增別的功能,當時真的有一種「學生是廉價的勞動力」這種感覺,一度都想放棄這個專案。不知道是什麼力量在支援,我們還是一直走了下來。

記得當時那一段時間,事情特別多,所有的學科都到了期末交大作業的時候,一堆一堆的「專案」堆在手邊,這頭有人催做這個專案,那頭有人催做那個專案,那一段時間可以說是我大學裡過得最累的時候,不知道熬了多少個通宵,身體啊,那個時候真的被忘到了腦後....

中間的太多過程不想再提了,換過語言,改了n個版本,與老師辯論了n次,幾乎每一次的開會都是戰戰兢兢 的,唉。。。

其實我想說的是做需求分析真的很重要,乙個好的軟體首先要先弄清楚使用者的要求,一般的使用者往往不能很直接地提出他的要求,基本上他們自己也說不清楚他們想到的到底是什麼樣的軟體,他們只能說出他們最想要的功能是什麼,大部分的使用者都是想直接通過使用乙個初始版本的軟體來決定該版本的軟體有什麼缺陷。。。。

有一句話說的真的很有道理「使用者最喜歡做的就是——變化,變化,再變化」

做為乙個it人,我們能做的應該就是「說服自己擁抱變化」吧。。。。

需求分析的20條法則

1、    分析人員要使用符合客戶語言習慣的表達  

2、    分析人員要了解客戶的業務及目標   

3、    分析人員必須編寫軟體需求報告  

4、    要求得到需求工作結果的解釋說明   

5、    開發人員要尊重客戶的意見  

6、    開發人員要對需求及產品實施提出建議和解決方案  

7、    描述產品使用特性   

8、    允許重用已有的軟體元件  

9、    要求對變更的代價提供真實可靠的評估

10、 獲得滿足客戶功能和質量要求的系統  

11、 給分析人員講解您的業務

12      抽出時間清楚地說明並完善需求  

13、 準確而詳細地說明需求  

14、 及時作出決定   

15、 尊重開發人員的需求可行性及成本評估

16、 劃分需求的優先順序

17、 評審需求文件和原型  

18、 需求變更要立即聯絡  

19、 遵照開發小組處理需求變更的過程  

20、 尊重開發人員採用的需求分析過程  

希望這些法則能給所有在做需求分析工作的朋友們一點幫助

第一次作業 談計算機專業

1 高中畢業後,對著自己的高考成績,想過很多專業,在學醫和計算機之間,我選擇了計算機。大學之前對計算機的了解幾乎一片空白,俗稱萌新小白。只是覺得計算機的出路應該很廣,好找工作。之前也沒接觸過程式設計方面的知識,不懂計算機,當然談不上喜歡。2 大學的生活自主化感很強,需要安心和耐心,不可以情緒化學習。...

第一次作業 閱讀優秀博文談感想

第一部分 結緣計算機 1.你為什麼選擇計算機專業?你認為你的條件如何?和這些博主比呢?必答 我很喜歡看未來科技這方面的電影 在我高中的時候神盾局正熱播,而我也就很自然地被他所吸引。劇中skye是小組的專業黑客,看到她在神盾局中用 幫助隊友一次又一次地擺脫危險,我覺得很帥氣,有一種坐在後方運籌帷幄的感...

做過一次需求分析後的體會

需求工程分為需求開發和需求管理兩個部分.需求開發步驟如下 1 產品組與客戶討論,研究產品,或根據經驗來確定問題域 2 產品組分析問題域,得到系統需求 3 產品組把系統需求文件化,得到 系統功能需求說明書 4 開發組,測試組,sqa評審確認 系統功能需求說明書 5 開發組分析 系統功能需求說明書 得到...