在前文中提到了關於軟體規格的一些迷思,特別是有些人覺得軟體規格的形式,以及軟體規格的份量是重點。例如,投影片的文件格式能不能做為軟體規格呢?是不是愈厚重的規格書就愈好呢?

事實上,投影片的文件格式如果運用的好,未必不能做為軟體規格的文件格式。而厚重、描述一切細節的的規格書,也未必就能做為一份稱職的軟體規格,使得開發團隊得以據此開發出符合使用者預期及滿足他們需求的軟體。

更重要的是,軟體規格要用什麼文件形式,以及它的內容究竟如何組織、用什麼方式呈現規格、呈現的精細程度要到那裡,也是一個因專案條件不同而有所不同的事情。

大型的開發團隊因為參與的成員眾多,溝通的複雜度高,因此,規格的細節程度自然就需要提高。

而愈小型的團隊,成員愈少、溝通的成本愈低,就有機會減少對規格細節的要求。

另一方面,若是專案本身在需求面的變化傾向於頻繁,改版規格時所需付出的代價比較高,相反地,若是專案的需求很穩定,而且可以在初期就確定,那麼先將細節描述在規格裡,也可以避免日後的溝通成本。

總之,這是一個需要視情況取捨的事情,沒有絕對的標準。

形成一份規格所需要的基本條件
然而,不論規格的精細程度如何、厚重程度如何,一份規格都有它具備的條件,那就是規格必須描述出讓人得以依循做設計、做實作,以及做測試檢驗的內容。

因為,一份規格的好與壞,不是取決於份量,也不是取決於它繁文縟節的程度,而是取決於它有沒有在所設定的篇幅限制下,盡可能地表現出最重要的規格資訊。

規格是一個溝通、確認的媒介,它是用來表示出代表使用者端的客戶究竟想要什麼樣的東西,所以我們可以透過它向代表使用者端的客戶確認,也可以拿來跟開發團隊溝通,而測試團隊也可以據以檢驗所開發出來的產物。

所以從這個出發點來看,規格的要素就很清楚,它必須夠明確、夠精確到讓客戶可以確認是不是他想要的東西,也必須可以讓開發團隊知道要開發出什麼,當然也得要可以讓開發團隊和客戶之間進行驗收的確認。

那麼軟體的功能規格應該含有那些項目呢?我想基本上應該包括:

(1)「使用者」可以透過系統完成那些事情。
(2)系統可以接收那些來自於使用者的輸入,這些輸入值的形式及格式為何?
(3)系統在執行每個功能時,會產出那些輸出值,這些輸出值的形式及格式又為何?

對一個軟體來說,「使用者」可能是一個真實的使用者,也可能是一個外部的系統,透過某種介面和正要開發的這個系統溝通、提供一些輸入,並且執行特定的功能,最後得到輸出。使用者輸入的形式可能是API,也可能是人機介面。系統輸出的形式可能是人機介面上的資料呈現,也可能是一份報表、一個電子郵件。

當你在撰寫一份功能規格的時候,除了描述系統應該具備什麼功能之外,對於輸入及輸出的描述也是很重要的一部份。

此外,規格可以是多種不同的呈現方式所構成的,例如使用者介面的規格可以用示意圖,或我們現在常說的 Wireframe 來表示,而功能的描述則是透過 User Story 來描述。對於功能的敘述是重點

功能規格中最主要的,便是應該描述這個軟體所具備的功能,也就是使用者或是其他系統可以從這個系統中所得到的。

例如,User Story 就是一種從使用系統功能的情境,來逐一列出系統所能夠提供給使用者的功能。

就像是:「在系統中沒有帳號的使用者可以進行註冊的動作。」「在系統中已經有帳號的使用者,可以輸入 ID 及密碼來登入系統。」這樣的描述,都是在表示從使用者的面向來看,系統究竟應該具備什麼功能。

另一方面,功能規格也應該描述出具體的規則,這邊所指的規則不一定涉及演算方法,但有可能出現一種狀況:演算方法本身也是規格的一部份。所謂規則就像是,使用者在登入系統時,系統會隨機產生一組四位數的 CAPTCHA認證碼,並呈現於操作介面上,並提供一個輸入欄位允許使用者輸入所看到的認證碼。系統除了檢核 ID 及密碼的匹配是否正確之外,也檢核使用者所輸入的認證碼是否正確。此認證碼含有大小寫字母及數字,但檢驗認證碼時不區分大小寫。

所以,像上述的這一條規格,就有可能被制定者寫成像是:使用者在登入系統時,系統會隨機產生一組CAPTCHA認證碼於操作介面上,並提供一個輸入欄位允許使用者輸入所看到的認證碼。系統除了檢核 ID 及密碼的匹配是否正確之外,也檢核使用者所輸入的認證碼是否正確。

這是我們可能會見到的寫法,不過,這一則功能的規格描述有兩個問題。首先就是認證碼究竟是幾位數?這從規格中看不出來;再者是,認證碼的長相究竟是什麼從規格中也看不出來。

所以該條規格看起來很像一回事了,卻遺漏了兩個重要的資訊。這麼一來,設計者或實作者就沒有辦法據以做設計及實作,看了這樣的規格,只能自己隨興發揮。對測試者來說,一個六位數的認證碼及一個四位數的認證碼,都是符合規格的,因為規格裡根本沒有定義。

同樣的,沒有定義出認證碼裡究竟會含有那些「碼」,也是這條規格的問題之一,所以,加上了「此認證碼含有大小寫字母及數字」後,就使得這個該要有的部份得以補上。

從這個例子就可以看得出來,輸入值究竟有什麼?它有什麼規則和條件?什麼樣的輸入是合法的?這些時常會被撰寫規格的人所忽略。有些人在撰寫規格時,會著重在系統該有什麼功能,卻疏於描述一些規則,不論是在輸入值上的規則,或是輸出值上的規則。

同一個User Story,可以綜合文字及圖片一起描述,這不是必要的情況,端視實務上的需求。例如,你要描述使用者透過使用者介面對系統做了輸入之後,使用者介面上呈現的變化時,你就會需要搭配圖片一起表示。因為對圖形化的操作介面來說,運用實際的圖片來呈現輸出值的變化規則,會是比較便利的方式。

這也說明了,對有些系統來說,圖示的表現方式是重要的,尤其像以圖形化介面為主要操作介面的軟體來說。

但對某些系統而言,圖示方式不見得需要,就像是一個提供RESTful API的服務系統,就不需要利用圖片來表示輸入或輸出的方式。

所以說,「文無定法」,軟體規格亦同。沒有一定要套用什麼模版才能寫規格,或什麼模版才是好的規格模版的事,這些都是因地、因時、因人而制宜的。

最重要的是,你所運用的媒介,必須要充份表現出功能究竟是什麼、輸入究竟是什麼,以及輸出究竟是什麼。

把這些媒介妥善地組織好,並且精確表現出來,就可以是一份稱職的規格。

作者簡介


Advertisement

更多 iThome相關內容