需求規格書¶
前言¶
從一個笑話講起。
劇本¶
出場角色¶
- 小明,路人
- 阿土伯,里長
- 番仔火文聰,代表
- 精實強,承辦人
- 歡喜婆婆,清潔員
故事¶
路人小明走在路上驚奇地在眼前的地上發現了一張垃圾,那居然是“有用過”的衛生紙,基於強烈的愛國心及公德心,不願讓這張“不可愛”的紙屑汙辱臺灣美麗的土地。說是遲,那是快,他拿出了內載「眼見為憑 APP」的手機 [copyright] ,把垃圾拍了下來,所謂的有圖有真相,既然有了真相,他也就心滿意足地繼續往便利商店前進,因為老媽說,家裡的銅葉綠素不夠了,要買罐回家,而他心想的是買大罐的,可以用比較久。
[copyright] | (1, 2) 安裝「眼見為憑 APP」前,或是註冊請求票網站前,都需要有「無償分享著作權」的條款,因為不管是相片或是任何意見都屬於個人著作權的範圍, 非常有必要 在使用者上傳相片、意見前即要求他們「同意分享」,不然就不給上傳。 |
那張垃圾的真相,被「眼見為憑 APP」上傳到請求票網站後 [1] [copyright] ,建立了案號為垃圾我清清(#24577 編號)的任務,從相片的 GPS 座標來看,它直接被丟給了阿土里的阿土伯來管理。
[1] | 「眼見為憑 APP」應支持離線儲存,上線自動上傳的功能 |
還好他的平板電腦的音量有切到最大,來信的“叮咚”有提醒到阿土伯,戴上老花眼睛後,看了看請求票網站的來信,他知道在公園路那邊,有那麼一張垃圾,所以他就把它歸給了市公所清潔隊。這樣請求票網站就可以利用一個叫蟲洞 [2] [3] 的技術,把這張請求票(也就是 #24577 的任務),傳送到市公所清潔隊的公文桌上。
[2] | 請求票系統乃利用 SMTP 協定與各級公務、國營事業單位的意見信箱作對接。所以當一任務被歸類到某一市政、市長、公害…信箱後,請求票系統即整理整個任務的內容、 GPS 座標及相片會以 task24577_45637@magpie.ho600.com 的名義寄出。爾後,該意見信箱把處理過程中的所有通知信回覆到 task24577_45637@magpie.ho600.com 時,請求票網站可將 email 內容轉至網頁內容,供使用者方便瀏覽。 task24577_45637@magpie.ho600.com 中的 _45637 乃 #24577 的檢查碼,以防止有垃圾軟體亂寄信件,無謂增加我們系統負荷。 |
[3] | 蟲洞的實作技術使用 Postfix ,可參考下面範例: http://www.postfix.org/OVERVIEW.html http://serverfault.com/questions/132576/run-script-on-incoming-email-message-to-postfix |
然而在公所未作處理前,就被番仔火文聰給攔胡了,文聰留言說:『阿土伯呀!你要帶老花眼睛了,這張相片明明就在公園路旁的阿土公園入口,那個地方要算市政府公園管理處管的啦~』,所以他就手動地把承辦單位換成了「市政府公園管理處」 [4] 。
[4] | 那份在「市公所清潔隊的公文桌」上的請求票怎麼辦?因為蟲洞不是時光機,所以也不能怎麼辦!就只能讓市公所清潔隊的承辦人點擊上面的超連結,回到請求票網站上看看,當他看到這份任務不關他的事時,就當是中樂透囉~ |
看到蟲洞送來的任務,精實強心下一樂,想起過去沒有請求票系統的時光,接到民眾陳情,他也只能眉頭一皺,雖說案情很單純,不過就是張垃圾,但精實強就是很精實呀,所以轄區 200 處公園,全由他一人承辦,這那有那麼多美國時間可以親自去到現場探勘、調研。現在光是靠這張有真相相片,他就能淡定地撥個電話給歡喜婆婆,請她扮好清潔包商的角色。精實強也只在滑鼠上一滑,這任務就滑進蟲洞,來到歡喜婆婆的信箱(或手機 [5] )。
[5] | 眼見為憑 APP 的進階功能之一,就是擁有 push mail 。 |
歡喜婆婆看到有事作,當然歡喜囉~從相片上,她清楚地知道,這個任務只要她本人到即可,不用掃具、不用垃圾車,空手拾起,放進口袋,就能打到回府。不過,在回府前,要作一件事: 「用眼見為憑 APP 搞自拍」。把自己跟乾淨的地板拍下來,傳回請求票系統,這樣精實強,才能打分數,發工程款呀!
精實強在辦公室內透過請求票系統比對了「嗶否」及「A福特」的相片後,確認了歡喜婆婆的確完成掃地的任務,給她記了 1 點,等月底時就依開口合約規定給予歡喜婆婆請款。當然,這個請款工作不會包含在請求票系統上,這是機關的內部作業。
原則上,請求票系統的目標就是無縫、快速地讓外部(公共設施)使用者、泛公部門承辦人及外包施工廠商三者進行資訊傳遞。任何太陽光照得到的東西,都適合放進請求票系統內。若不是太陽光看得到,但承辦人認為可填入此類資訊方有助其他人的了解,則由承辦人權衡。在任務的處理上,以承辦人為最大權限者。
當承辦人完成此項任務後,即可開放給公眾瀏覽,請求票系統同時也會通知協調人(里長、代表或議員,乃有參與該任務分配的成員)、發票人(也就是路人),此任務已解決歡迎回系統為任務處理的相關人員喝個采、拍個手、留留感性的、呼天搶地的讚頌之言。
票的轉換流程¶
票的狀態 [6] :
狀態 | 操作者 | 任務負責人 |
---|---|---|
上傳附件中 | APP | 無 |
創建 | 路人 | 里長、里幹事、代表、議員或請求票系統管理員 |
搗蛋任務 | 里長、里幹事、代表、議員 | 無(需填寫理由,在隱藏不適當內容後公開,路人會被計大點) |
無法執行任務 | 里長、里幹事、代表、議員 | 無(需填寫理由,路人會被計點) |
重覆任務 | 里長、里幹事、代表、議員 | 無(需指定與那一個任務重覆) |
已分配 | 里長、里幹事、代表、議員 | 泛公部門 |
已受理 | 泛公部門的信箱管理者 | 泛公部門的信箱管理者 |
承辦中 | 泛公部門的信箱管理者 | 泛公部門承辦人 |
發包中 | 泛公部門承辦人 | 外包廠商 |
施工中 | 外包廠商 | 外包廠商 |
已施工 | 外包廠商 | 泛公部門承辦人 |
已驗收 | 泛公部門承辦人 | 泛公部門承辦人 |
重新處理 | 除泛公部門承辦人外 | 泛公部門承辦人 |
狀態值依序定義如下:
[6] | 要好好地跟隊友討論 ( #3 ) 。 |
註解
<技術說明> 搗蛋任務、無法執行任務、重覆任務、已驗收等狀態時, in_working 要等於 False
畫面¶
案件明細頁¶
案件基本欄位¶
參考 bitbucket 的 issue 頁面,案件基本欄位有:
- 創建者
- 創建時間
- 最後更新時間
- 任務負責人
- 操作者
- 狀態
- 類型
- GPS
- 所屬村里
- 所屬單位
- 標題(由網站管理員下)
- 主要相片附檔(限.jpg, 1 張)
- 相片附檔(限.jpg,數量至少 1 張)
- 內容(無內容則必須有錄音檔)
- 錄音檔(限.ogg,限 1 分鐘, 1 個檔) [7]
- 錄音逐字稿(若路人使用錄音檔,則可由網站管理人員手動鍵入)
- 是否公開
- 是否允許評論
[7] | 強迫用戶長話短說。 |
意見基本欄位¶
每一個案件可擁有多個回覆意見,意見乃由參與者自由回覆,參與者依不同案件狀態可有不同人選,如案件剛創立時,參與者為路人、該寄件所在村里之里長、里幹事、代表、議員。在確定承辦單位後,參與者即多了承辦單位的承辦人,案件發包給施工廠商後,參與者即包含施工廠商。
意見呈現的方式則 不採用 bitbucket 模式,而改用 FB 模式,即新意見是在上方,並在使用者將網頁向下捲動時,才會依序秀出舊意見。
意見的基本欄位有:
- 發表者
- 內容(純文字)
- 是否公開
- 附檔(任何格式,數量不限,也獨立設定是否公開)
- 任務負責人變動資料
- 狀態變動資料
- 類型變動資料
- 所屬單位變動資料
案件列表頁¶
案件可依下列欄位查詢:
- 狀態
- 類型(路面、堤防、水溝、路燈、電線桿、人孔蓋...)
- 所屬村里(依縣市、鄉鎮市區階段搜尋)
- 所屬單位(依機關層級搜尋)
- 創建時間
- 結案時間
- 案件是否公開(未公開者,僅秀 GPS 座標、村里)
- 內文關鍵詞