需求規格書

前言

從一個笑話講起。

劇本

出場角色

  • 小明，路人
  • 阿土伯，里長
  • 番仔火文聰，代表
  • 精實強，承辦人
  • 歡喜婆婆，清潔員

故事

路人小明走在路上驚奇地在眼前的地上發現了一張垃圾，那居然是“有用過”的衛生紙，基於強烈的愛國心及公德心，不願讓這張“不可愛”的紙屑汙辱臺灣美麗的土地。說是遲，那是快，他拿出了內載「眼見為憑 APP」的手機 [copyright] ，把垃圾拍了下來，所謂的有圖有真相，既然有了真相，他也就心滿意足地繼續往便利商店前進，因為老媽說，家裡的銅葉綠素不夠了，要買罐回家，而他心想的是買大罐的，可以用比較久。

那張垃圾的真相，被「眼見為憑 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://blog.thecodingmachine.com/content/triggering-php-script-when-your-postfix-server-receives-mail

http://serverfault.com/questions/132576/run-script-on-incoming-email-message-to-postfix

http://serverfault.com/questions/258469/how-to-configure-postfix-to-pipe-all-incoming-email-to-a-script

然而在公所未作處理前，就被番仔火文聰給攔胡了，文聰留言說：『阿土伯呀！你要帶老花眼睛了，這張相片明明就在公園路旁的阿土公園入口，那個地方要算市政府公園管理處管的啦～』，所以他就手動地把承辦單位換成了「市政府公園管理處」 [4] 。

[4]那份在「市公所清潔隊的公文桌」上的請求票怎麼辦？因為蟲洞不是時光機，所以也不能怎麼辦！就只能讓市公所清潔隊的承辦人點擊上面的超連結，回到請求票網站上看看，當他看到這份任務不關他的事時，就當是中樂透囉～

看到蟲洞送來的任務，精實強心下一樂，想起過去沒有請求票系統的時光，接到民眾陳情，他也只能眉頭一皺，雖說案情很單純，不過就是張垃圾，但精實強就是很精實呀，所以轄區 200 處公園，全由他一人承辦，這那有那麼多美國時間可以親自去到現場探勘、調研。現在光是靠這張有真相相片，他就能淡定地撥個電話給歡喜婆婆，請她扮好清潔包商的角色。精實強也只在滑鼠上一滑，這任務就滑進蟲洞，來到歡喜婆婆的信箱（或手機 [5] )。

[5]眼見為憑 APP 的進階功能之一，就是擁有 push mail 。

歡喜婆婆看到有事作，當然歡喜囉～從相片上，她清楚地知道，這個任務只要她本人到即可，不用掃具、不用垃圾車，空手拾起，放進口袋，就能打到回府。不過，在回府前，要作一件事: 「用眼見為憑 APP 搞自拍」。把自己跟乾淨的地板拍下來，傳回請求票系統，這樣精實強，才能打分數，發工程款呀！

精實強在辦公室內透過請求票系統比對了「嗶否」及「Ａ福特」的相片後，確認了歡喜婆婆的確完成掃地的任務，給她記了 1 點，等月底時就依開口合約規定給予歡喜婆婆請款。當然，這個請款工作不會包含在請求票系統上，這是機關的內部作業。

原則上，請求票系統的目標就是無縫、快速地讓外部（公共設施）使用者、泛公部門承辦人及外包施工廠商三者進行資訊傳遞。任何太陽光照得到的東西，都適合放進請求票系統內。若不是太陽光看得到，但承辦人認為可填入此類資訊方有助其他人的了解，則由承辦人權衡。在任務的處理上，以承辦人為最大權限者。

當承辦人完成此項任務後，即可開放給公眾瀏覽，請求票系統同時也會通知協調人（里長、代表或議員，乃有參與該任務分配的成員）、發票人（也就是路人），此任務已解決歡迎回系統為任務處理的相關人員喝個采、拍個手、留留感性的、呼天搶地的讚頌之言。

票的轉換流程

票的狀態 [6] :

狀態 操作者 任務負責人
上傳附件中 APP 無
創建 路人 里長、里幹事、代表、議員或請求票系統管理員
搗蛋任務 里長、里幹事、代表、議員 無(需填寫理由，在隱藏不適當內容後公開，路人會被計大點)
無法執行任務 里長、里幹事、代表、議員 無(需填寫理由，路人會被計點)
重覆任務 里長、里幹事、代表、議員 無(需指定與那一個任務重覆）
已分配 里長、里幹事、代表、議員 泛公部門
已受理 泛公部門的信箱管理者 泛公部門的信箱管理者
承辦中 泛公部門的信箱管理者 泛公部門承辦人
發包中 泛公部門承辦人 外包廠商
施工中 外包廠商 外包廠商
已施工 外包廠商 泛公部門承辦人
已驗收 泛公部門承辦人 泛公部門承辦人
重新處理 除泛公部門承辦人外 泛公部門承辦人

狀態值依序定義如下:

[6]要好好地跟隊友討論 ( #3 ) 。

註解

<技術說明> 搗蛋任務、無法執行任務、重覆任務、已驗收等狀態時， in_working 要等於 False

畫面

案件明細頁

案件基本欄位

參考 bitbucket 的 issue 頁面，案件基本欄位有:

  1. 創建者
  2. 創建時間
  3. 最後更新時間
  4. 任務負責人
  5. 操作者
  6. 狀態
  7. 類型
  8. GPS
  9. 所屬村里
  10. 所屬單位
  11. 標題(由網站管理員下)
  12. 主要相片附檔(限.jpg， 1 張)
  13. 相片附檔(限.jpg，數量至少 1 張)
  14. 內容(無內容則必須有錄音檔)
  15. 錄音檔(限.ogg，限 1 分鐘， 1 個檔) [7]
  16. 錄音逐字稿(若路人使用錄音檔，則可由網站管理人員手動鍵入)
  17. 是否公開
  18. 是否允許評論
[7]強迫用戶長話短說。

意見基本欄位

每一個案件可擁有多個回覆意見，意見乃由參與者自由回覆，參與者依不同案件狀態可有不同人選，如案件剛創立時，參與者為路人、該寄件所在村里之里長、里幹事、代表、議員。在確定承辦單位後，參與者即多了承辦單位的承辦人，案件發包給施工廠商後，參與者即包含施工廠商。

意見呈現的方式則 不採用 bitbucket 模式，而改用 FB 模式，即新意見是在上方，並在使用者將網頁向下捲動時，才會依序秀出舊意見。

意見的基本欄位有:

  1. 發表者
  2. 內容(純文字)
  3. 是否公開
  4. 附檔(任何格式，數量不限，也獨立設定是否公開)
  5. 任務負責人變動資料
  6. 狀態變動資料
  7. 類型變動資料
  8. 所屬單位變動資料

評論基本欄位

當案件被公開後(由承辦人決定是否公開)，則所有路人都可以對案件評論話燒。評論的基本欄位:

  1. 內容
  2. 被評價分數(其他人可對該評論作評分)

案件列表頁

案件可依下列欄位查詢:

  1. 狀態
  2. 類型(路面、堤防、水溝、路燈、電線桿、人孔蓋...)
  3. 所屬村里(依縣市、鄉鎮市區階段搜尋)
  4. 所屬單位(依機關層級搜尋)
  5. 創建時間
  6. 結案時間
  7. 案件是否公開(未公開者，僅秀 GPS 座標、村里)
  8. 內文關鍵詞

個人資料頁

登入頁