[{"data":1,"prerenderedAt":647},["ShallowReactive",2],{"site-schema":3,"article-en-government-information-system-development-guide":93,"article-related-en-government-information-system-development-guide":629},{"@context":4,"@graph":5},"https://schema.org",[6,72,84],{"@type":7,"@id":8,"name":9,"alternateName":10,"legalName":15,"foundingDate":16,"numberOfEmployees":17,"taxID":18,"url":19,"logo":20,"founder":21,"contactPoint":23,"address":37,"location":43,"sameAs":63},"Organization","https://joinx.co/#organization","JoinX哲煜科技",[11,12,13,14],"JoinX","TWJOIN","哲煜科技","哲煜科技股份有限公司","JoinX Co., Ltd.","2016-04-28",80,"43774383","https://joinx.co","https://joinx.co/images/logo-with-name.png",{"@id":22},"https://joinx.co/#person-jack-lee",[24],{"@type":25,"contactType":26,"url":27,"telephone":28,"email":29,"areaServed":30,"availableLanguage":33},"ContactPoint","customer service","https://joinx.co/contact-us","+886-2-8771-9095","service@joinx.co",[31,32],"TW","JP",[34,35,36],"zh-Hant","en","ja",{"@type":38,"streetAddress":39,"postalCode":40,"addressLocality":41,"addressRegion":42,"addressCountry":31},"PostalAddress","民生東路二段170號8樓","104","台北市中山區","台灣",[44,51,57],{"@type":45,"name":46,"address":47},"Place","JoinX 台中辦公室",{"@type":38,"streetAddress":48,"postalCode":49,"addressLocality":50,"addressRegion":42,"addressCountry":31},"台灣大道二段360號21樓C室","40453","台中市北區",{"@type":45,"name":52,"address":53},"JoinX 高雄辦公室",{"@type":38,"streetAddress":54,"postalCode":55,"addressLocality":56,"addressRegion":42,"addressCountry":31},"民族一路80號2樓之一(B4)","807","高雄市三民區",{"@type":45,"name":58,"address":59},"JoinX 東京辦公室",{"@type":38,"streetAddress":60,"postalCode":61,"addressLocality":62,"addressCountry":32},"東五反田5-22-37 Office Circle N 五反田 9樓","141-0022","東京都品川區",[64,65,66,67,68,69,70,71],"https://www.crunchbase.com/organization/twjoin","https://www.facebook.com/JoinX.TW","https://tw.linkedin.com/company/%E5%93%B2%E7%85%9C%E7%A7%91%E6%8A%80","https://www.youtube.com/c/joinstuido%E5%93%B2%E7%85%9C%E7%A7%91%E6%8A%80","https://medium.com/twjoin","https://www.104.com.tw/company/1a2x6bjomb","https://clutch.co/profile/twjoin","https://www.goodfirms.co/company/twjoin",{"@type":73,"@id":22,"name":74,"alternateName":75,"jobTitle":76,"worksFor":77,"url":78,"sameAs":79},"Person","李秉哲","Jack Lee","創辦人暨執行長",{"@id":8},"https://jack.joinx.co",[80,81,82,83],"https://www.instagram.com/jack88.podcast/","https://www.threads.net/@jack88.podcast","https://joinx.co/jack88/","https://www.linkedin.com/in/jacklee-taiwan/",{"@type":85,"@id":86,"url":19,"name":9,"alternateName":87,"publisher":88,"inLanguage":89},"WebSite","https://joinx.co/#website",[11,13,9],{"@id":8},[90,91,92],"zh-Hant-TW","en-US","ja-JP",{"id":94,"title":95,"body":96,"category":593,"cover":594,"dateModified":595,"description":105,"extension":596,"faq":597,"hasCoverTitle":603,"locale":35,"meta":604,"navigation":603,"need":605,"path":606,"seo":607,"sources":608,"stem":625,"takeaways":626,"time":595,"type":627,"__hash__":628},"content/en/article/government-information-system-development-guide.md","Government Information System Planning: Needs to Acceptance",{"type":97,"value":98,"toc":569},"minimal",[99,106,109,112,115,137,140,145,148,151,154,157,160,163,166,169,172,175,179,182,185,188,191,194,197,200,203,206,209,212,216,219,222,225,228,231,234,237,240,243,246,250,253,256,259,291,294,298,301,304,307,310,313,316,319,323,326,329,332,335,339,342,345,348,351,354,357,360,363,366,369,372,376,379,382,385,388,391,394,397,400,404,407,410,413,416,419,422,425,428,431,434,437,440,443,447,450,453,456,459,462,465,468,471,474,477,480,484,487,490,493,496,499,501,504,507,510,513,517,522,525,529,532,536,539,543,546,550,553,557,560,563,566],[100,101,102],"p",{},[103,104,105],"strong",{},"The first step in developing a government information system is usually not choosing a technology or listing how many features to build, but confirming what business or public service the system must support, who will use it, what data it must handle, and how you will ultimately judge whether the system meets the requirements.",[100,107,108],{},"For government agencies preparing to build or outsource an information system, requirements planning affects everything that follows: the procurement scope, vendor estimates, system design, information security, testing, and acceptance. If the early stage produces only feature names, without clearly describing the user workflows, data, permissions, and acceptance method, gaps in how the requirements are understood can keep appearing during development, even after the tender has gone smoothly.",[100,110,111],{},"The Public Construction Commission, Executive Yuan's regulations on selecting and paying information service providers commissioned by agencies include overall planning, system integration, software development, software verification, software maintenance, database construction, and consulting within the scope of \"information services\"; the actual procurement method must still follow the amount, nature, and applicable rules of each case.",[100,113,114],{},"So if you are planning a new government information system, you can start by answering six questions:",[116,117,118,122,125,128,131,134],"ul",{},[119,120,121],"li",{},"Which business process or public service should the system improve?",[119,123,124],{},"Who are the users, and what work does each role need to get done?",[119,126,127],{},"What data does the system need to handle, and does it involve migrating existing data?",[119,129,130],{},"Does it need to integrate with other government systems, databases, or third-party services?",[119,132,133],{},"What requirements apply for cybersecurity, personal data, web accessibility, and so on?",[119,135,136],{},"Which features, tests, or deliverables should ultimately serve as the basis for acceptance?",[100,138,139],{},"The clearer these six things are, the easier it becomes to turn \"we want a system\" into a development project that can actually be procured and executed.",[141,142,144],"h2",{"id":143},"why-cant-government-information-system-development-start-with-just-a-feature-list","Why can't government information system development start with just a feature list?",[100,146,147],{},"The development scope of an information system is hard to judge from feature names alone.",[100,149,150],{},"For example, a requirements specification says:",[100,152,153],{},"\"Build a case management function.\"",[100,155,156],{},"In practice, this might only let case officers create, edit, and look up cases; or it might include online applications from the public, identity verification, cross-unit case assignment, supervisor sign-off, requests for additional documents, notifications, progress tracking, statistical reports, and history records.",[100,158,159],{},"Both are called \"case management,\" yet the development scale is completely different.",[100,161,162],{},"So when planning a government information system, what is worth confirming before \"which features\" is this:",[100,164,165],{},"From start to finish, which people, which data, and which processing steps does a piece of business go through?",[100,167,168],{},"This does not mean every government agency must follow the same fixed development process; it is an important principle of information system planning.",[100,170,171],{},"Take the current rules of the Water Resources Agency, Ministry of Economic Affairs, and its subordinate agencies as an example. Its guidelines for information system development and maintenance divide the information system life cycle into eight stages: system assessment, requirements and system analysis, system design, programming, system testing, training, go-live, and system maintenance, and they provide reference templates for requirements specifications, requirements interview records, design specifications, test plans, and test reports. These are internal rules of the Water Resources Agency and its subordinate agencies and cannot be generalized directly into a uniform rule for all government agencies, but they show that requirements, design, testing, and go-live are connected in sequence.",[100,173,174],{},"What an agency really needs to avoid is requirements that stop at \"feature names,\" leaving the later design and acceptance without a shared basis.",[141,176,178],{"id":177},"what-should-a-government-information-system-requirements-specification-confirm-first","What should a government information system requirements specification confirm first?",[100,180,181],{},"The purpose of a requirements specification is not to make the responsible unit decide every button, screen, and technology before development.",[100,183,184],{},"What matters more is first establishing the system boundary.",[100,186,187],{},"For example, when planning an online application system, you should at least clarify:",[100,189,190],{},"Who can submit an application, what information must be provided, whether attachments are needed, who handles a case after it is submitted, whether cases can be returned or require additional documents, which review roles exist, how applicants are notified, and which case records must ultimately be retained.",[100,192,193],{},"Once these business requirements are confirmed, the development team can break them down further into:",[100,195,196],{},"User workflows, features, permissions, data structures, interfaces, APIs, and the technical architecture.",[100,198,199],{},"If, instead, very detailed screens or technical approaches are specified before the business processes are confirmed, this not only may increase later changes but also requires attention to government procurement's requirements for fair competition.",[100,201,202],{},"The Public Construction Commission's implementation notes for Article 26 of the Government Procurement Act state that technical specifications open to bidding by unspecified vendors should be limited to achieving the functions, benefits, or characteristics the agency needs, and must not unduly restrict competition in purpose or effect.",[100,204,205],{},"So writing a requirements specification in \"detail\" is not the same as writing it \"well.\"",[100,207,208],{},"What matters more is this:",[100,210,211],{},"The business requirements that need to be stated are stated clearly enough, without prematurely restricting solutions through unnecessary technical specifications.",[141,213,215],{"id":214},"if-the-requirements-are-not-yet-settled-how-can-a-government-agency-conduct-early-stage-research","If the requirements are not yet settled, how can a government agency conduct early-stage research?",[100,217,218],{},"What makes government information systems distinctive is that the responsible unit sometimes knows what problem it needs to solve, but not necessarily which technical approaches the market currently offers or how a reasonable development scope should be set.",[100,220,221],{},"That does not mean the only option is to guess the specifications on your own.",[100,223,224],{},"The Public Construction Commission's implementation notes for Article 26 of the Government Procurement Act explicitly state that when setting the technical specifications in tender documents, an agency may, under Article 34, Paragraph 1 of the Government Procurement Act, publicly invite vendors to provide reference material for the agency to consider before setting the specifications.",[100,226,227],{},"In other words, if a project is still at a stage where the market, technology, or solution is unclear, you can evaluate using public market information gathering under the applicable procurement procedures, rather than writing technical answers you are unsure of directly into the specifications.",[100,229,230],{},"This is especially important for information systems.",[100,232,233],{},"Because what the responsible unit usually knows best is:",[100,235,236],{},"\"What isn't working well right now.\"",[100,238,239],{},"And what development vendors are more familiar with is:",[100,241,242],{},"\"What technical solutions exist for this problem.\"",[100,244,245],{},"The real work of early-stage planning for a government information system is to gradually connect these two things while maintaining fairness in procurement.",[141,247,249],{"id":248},"when-outsourcing-a-government-information-system-which-conditions-should-be-stated-clearly-before-tendering","When outsourcing a government information system, which conditions should be stated clearly before tendering?",[100,251,252],{},"Procuring government information services is not only about functional specifications.",[100,254,255],{},"Under the Public Construction Commission's regulations on selecting and paying information service providers commissioned by agencies, tender documents may, depending on the characteristics and actual needs of the case, state the service items and scope of work, the resources the vendor should have, the agency's existing IT environment, and other matters; service fees should also be calculated using a method suited to the category, nature, scale, scope of work, and duration of the information service.",[100,257,258],{},"For information system development, this means that in the early stage, beyond features, you should at least take stock of:",[116,260,261,264,267,270,273,276,279,282,285,288],{},[119,262,263],{},"The existing IT environment and deployment conditions",[119,265,266],{},"Existing systems and data sources",[119,268,269],{},"External systems to be integrated",[119,271,272],{},"User roles and permissions",[119,274,275],{},"Data migration requirements",[119,277,278],{},"Cybersecurity requirements",[119,280,281],{},"Test and acceptance items",[119,283,284],{},"The go-live approach",[119,286,287],{},"Training or documentation deliverables",[119,289,290],{},"Ongoing operations, maintenance, and warranty requirements",[100,292,293],{},"Not every project needs all of these, but if any of them would affect the staffing, technology, or schedule the vendor must commit, it should not be confirmed for the first time after development begins.",[141,295,297],{"id":296},"cybersecurity-cannot-wait-until-the-system-is-finished","Cybersecurity cannot wait until the system is finished",[100,299,300],{},"For government information systems, security is not work that ends with \"one scan\" after development is complete.",[100,302,303],{},"Article 10 of the current Cyber Security Management Act provides that when government agencies or specific non-government agencies, within its scope, outsource the building or operation of information and communication systems or information and communication services, they must select suitable contractors, require them to establish an effective cybersecurity management mechanism and supervise its implementation, and set out both parties' rights, obligations, and liability for breach in a written contract.",[100,305,306],{},"Article 11 of the current Regulations Governing the Classification of Cyber Security Responsibility Levels also requires that information and communication systems developed by each agency in-house or through outsourcing complete protection requirement classification under the rules and implement control measures according to the corresponding protection baseline.",[100,308,309],{},"So for projects involving login, permission management, personal data, sensitive information, or data exchange across systems, security requirements should be built in at the system architecture and requirements stage.",[100,311,312],{},"For example:",[100,314,315],{},"Which roles can view which data, how sensitive data is handled, how systems exchange information, and which security tests must be completed can all affect system design.",[100,317,318],{},"If these are handled for the first time just before acceptance, what may need to be reworked is likely not just the code but the entire permission or data architecture.",[141,320,322],{"id":321},"for-government-websites-or-public-service-portals-web-accessibility-also-needs-to-be-considered","For government websites or public service portals, web accessibility also needs to be considered",[100,324,325],{},"If the deliverable is a government website, an online application service, or another public-facing web service, you also need to review the rules for government websites, in addition to the information system itself.",[100,327,328],{},"The government website service management guidelines, published on the Government Website Operations Exchange Platform, currently organize the website life cycle into six execution areas: website positioning, design planning, development and build-out, data migration, launch preparation, and operations management; in the development and build-out stage, they require confirming compliance with information security and website service rules, including the web accessibility guidelines.",[100,330,331],{},"The Ministry of Digital Affairs' current web accessibility guidelines cover perceivability, operability, understandability, and compatibility, for example keyboard operation, content structure, focus order, error identification, and compatibility with assistive technologies.",[100,333,334],{},"So if the project itself has accessibility requirements, the more reasonable approach is to build them in during UI/UX and frontend development, rather than making all the changes at once after the website is finished.",[141,336,338],{"id":337},"why-cant-the-budget-for-a-government-information-system-be-estimated-from-the-number-of-features-alone","Why can't the budget for a government information system be estimated from the number of features alone?",[100,340,341],{},"The development cost of a government information system is usually not just about \"how many features there are.\"",[100,343,344],{},"For example, two projects might both have:",[100,346,347],{},"Membership, case management, search, reports, and an admin back office.",[100,349,350],{},"One might be used only by ten internal staff; the other might require public login, cross-agency data exchange, multi-level permissions, historical data migration, security testing, and accessibility for a public website.",[100,352,353],{},"The feature names of the two look similar, but the actual development scope may differ greatly.",[100,355,356],{},"So when estimating the development scope of an information system, it is better to examine it piece by piece:",[100,358,359],{},"Business processes → user roles → features → data → system integration → security → design → testing → go-live and delivery",[100,361,362],{},"The Public Construction Commission's fee rules for information services also do not determine fees simply by the number of features; they require choosing a suitable fee calculation method based on factors such as the service category, nature, scale, scope of work, and duration.",[100,364,365],{},"So if the project budget is limited, rather than first making a very long feature list and then cutting items one by one, it is more worthwhile to confirm first:",[100,367,368],{},"Which part of the service workflow must the first phase complete, at minimum, so that it can actually be put into use?",[100,370,371],{},"This is a system planning recommendation, not a government regulatory requirement, but it is usually more helpful for controlling the development scope.",[141,373,375],{"id":374},"can-requirements-be-changed-during-government-information-system-development","Can requirements be changed during government information system development?",[100,377,378],{},"Once an information system enters requirements interviews, prototyping, or real-world testing, it is not unusual to discover that some workflows need adjusting.",[100,380,381],{},"So what really needs to be managed is not \"requirements can never change once the project starts,\" but rather:",[100,383,384],{},"When requirements change, how the scope, schedule, cost, and basis for acceptance are adjusted together.",[100,386,387],{},"For example, if the original requirement was to let case officers look up cases, and later cross-agency case assignment and automatic notifications are added, this is no longer just a screen adjustment; it may involve new permissions, workflows, and data exchange.",[100,389,390],{},"Without a clear change management approach, this easily leads to:",[100,392,393],{},"The agency believing it is just part of the original feature, while the vendor believes it is added scope.",[100,395,396],{},"So defining in advance, in the contract, the statement of work, and the project management mechanism, how requirements are confirmed, how changes are recorded, and how impact is assessed fits the reality of information system development better than demanding that \"all requirements be settled on day one.\"",[100,398,399],{},"The Public Construction Commission also continues to provide an information service procurement contract template for agencies to reference when procuring information services; the actual contract content should still be adjusted to the needs of each case and the latest rules.",[141,401,403],{"id":402},"when-should-preparation-for-government-information-system-acceptance-begin","When should preparation for government information system acceptance begin?",[100,405,406],{},"You should start thinking about it from the requirements planning stage.",[100,408,409],{},"Because:",[100,411,412],{},"The requirements specification determines what to build, and acceptance determines how to confirm that it has really been completed.",[100,414,415],{},"For example, if you only write:",[100,417,418],{},"\"Provide an online application function.\"",[100,420,421],{},"In the end, it is hard to judge what counts as complete.",[100,423,424],{},"If the scenario is spelled out from the start, for example:",[100,426,427],{},"Applicant logs in → fills in the information → uploads attachments → submits → case officer reviews → additional documents requested → re-review → completed → result notified,",[100,429,430],{},"then it becomes easier to turn each step into test scenarios and acceptance items later.",[100,432,433],{},"Taking the Water Resources Agency's current internal rules as an example again, the system testing stage requires testing based on requirements and design documents and provides reference templates for test plans and test reports. To emphasize once more, these are rules of the Water Resources Agency and its subordinate agencies and do not mean that every government information system is legally required to use the same documents or process, but they illustrate well the link that should exist between requirements and testing.",[100,435,436],{},"So when planning a government information system early on, a very practical check is this:",[100,438,439],{},"Can each important requirement answer the question \"How will we ultimately prove it is done?\"",[100,441,442],{},"If not, the requirement may still need further clarification.",[141,444,446],{"id":445},"how-should-government-information-system-development-vendors-be-evaluated","How should government information system development vendors be evaluated?",[100,448,449],{},"Developing an information system is not like procuring a finished product with fully fixed specifications, so you cannot look only at the number of features or the lowest quote.",[100,451,452],{},"The Public Construction Commission's regulations on selecting and paying information service providers commissioned by agencies themselves include project planning and management capability, human resource planning, relevant capabilities, and other items set as needed for the case in the information service selection system; the actual evaluation items should still be set by the agency according to the case and the tender documents.",[100,454,455],{},"From an information system development perspective, there are a few things worth watching closely in the early stage:",[100,457,458],{},"First, whether the vendor can understand the business processes, rather than just quoting from the feature list.",[100,460,461],{},"When it sees \"case management,\" does it ask follow-up questions about case statuses, roles, exception workflows, and history requirements?",[100,463,464],{},"Second, whether it can proactively point out the system boundary.",[100,466,467],{},"For example, which features belong to this system, which require external APIs, and which data is provided by other agencies.",[100,469,470],{},"Third, whether it can clearly explain how things will be verified.",[100,472,473],{},"Beyond \"we can do it,\" can it explain how it will be tested and how completion will be confirmed?",[100,475,476],{},"Fourth, whether security, deployment, and ongoing operations and maintenance are factored into the architecture.",[100,478,479],{},"These usually reflect a vendor's actual ability to perform an information service contract better than simply comparing \"who is cheapest for the same ten features.\"",[141,481,483],{"id":482},"the-core-of-government-information-system-development-is-not-writing-as-much-specification-as-possible","The core of government information system development is not writing as much specification as possible",[100,485,486],{},"From requirements planning to go-live, a government information system passes through different stages such as procurement, development, security, testing, and acceptance.",[100,488,489],{},"What really determines whether these stages connect smoothly is not how many pages the specification has, but whether three things are aligned:",[100,491,492],{},"The problem the agency really needs to solve",[100,494,495],{},"↓",[100,497,498],{},"The system the vendor will actually develop",[100,500,495],{},[100,502,503],{},"The criteria ultimately used for acceptance",[100,505,506],{},"If the starting point is \"we want to shorten the time it takes the public to apply,\" but the requirements only say \"build a case management system,\" and acceptance in the end only checks whether the pages open, then even if every document is completed, the system may still not truly solve the original problem.",[100,508,509],{},"So rather than deciding on the technology first or chasing the most complete feature list, it is more worthwhile for a government information system to sort out the business processes, users, system boundary, data, security, and acceptance method before development.",[100,511,512],{},"Once these conditions are confirmed, the technology and development have a clear direction.",[141,514,516],{"id":515},"government-information-system-development-frequently-asked-questions","Government Information System Development: Frequently Asked Questions",[518,519,521],"h3",{"id":520},"does-a-government-information-system-have-to-be-outsourced","Does a government information system have to be outsourced?",[100,523,524],{},"Not necessarily. Whether to develop in-house or outsource should still be assessed based on the agency's IT capacity, the nature of the project, the budget, and the relevant rules. The Public Construction Commission's current information service rules include software development, system integration, and database construction within the scope of information services, but that does not mean every information system must use the same procurement or outsourcing approach.",[518,526,528],{"id":527},"if-the-requirements-for-a-government-information-system-are-still-unclear-can-we-first-learn-what-the-market-offers","If the requirements for a government information system are still unclear, can we first learn what the market offers?",[100,530,531],{},"An appropriate approach can be taken under the relevant government procurement rules. The Public Construction Commission states that when setting technical specifications, an agency may, under Article 34, Paragraph 1 of the Government Procurement Act, publicly invite vendors to provide reference material for the agency to consider in developing the specifications. The actual procedure should still be confirmed case by case by the agency's procurement unit or other responsible units.",[518,533,535],{"id":534},"does-a-government-information-system-have-to-undergo-security-testing","Does a government information system have to undergo security testing?",[100,537,538],{},"The security requirements for government information and communication systems should be determined under the Cyber Security Management Act, its Enforcement Rules, the Regulations Governing the Classification of Cyber Security Responsibility Levels, and the rules that apply to the agency and the case; no single test item can cover every project. Current rules already explicitly require information and communication systems developed in-house or through outsourcing to undergo protection requirement classification and implement the corresponding control measures.",[518,540,542],{"id":541},"do-government-websites-have-to-meet-web-accessibility-requirements","Do government websites have to meet web accessibility requirements?",[100,544,545],{},"The government website service management guidelines explicitly list the web accessibility guidelines as one of the relevant rules to confirm during development and build-out; the actual conformance level, testing, and mark application requirements should follow the project and the Ministry of Digital Affairs' current web accessibility rules.",[518,547,549],{"id":548},"do-all-the-screens-have-to-be-drawn-in-the-requirements-specification-before-a-government-information-system-can-go-to-tender","Do all the screens have to be drawn in the requirements specification before a government information system can go to tender?",[100,551,552],{},"No universal rule requires every government information system to complete all UI screens before tendering. What really needs to be confirmed case by case is the scope of services, functional or performance requirements, the IT environment, security, and the necessary deliverables and acceptance content. Technical specifications must also take care not to unduly restrict competition.",[141,554,556],{"id":555},"start-by-clarifying-requirements-so-an-information-system-can-truly-be-developed-and-used","Start by clarifying requirements, so an information system can truly be developed and used",[100,558,559],{},"When a government or public-sector body needs a new information system, online service, website platform, or process digitalization, the starting point for development does not have to be a fully finalized feature list.",[100,561,562],{},"What matters more is first organizing the current business processes, users, data, system environment, and expected outcomes, and then gradually turning them into actionable information system requirements.",[100,564,565],{},"JoinX provides custom development and design, AI adoption, and technology and AI consulting services, and can take part in planning and developing websites, systems, apps, SaaS, and AI applications according to project needs.",[100,567,568],{},"For government and public-sector information system cases, any collaboration must still follow the relevant government procurement procedures and the tender rules of each case; for market information gathering, public invitations for reference material, or formal procurement cases, we can provide the corresponding technical and development information under the lawful procedure the agency adopts.",{"title":570,"searchDepth":571,"depth":571,"links":572},"",2,[573,574,575,576,577,578,579,580,581,582,583,584,592],{"id":143,"depth":571,"text":144},{"id":177,"depth":571,"text":178},{"id":214,"depth":571,"text":215},{"id":248,"depth":571,"text":249},{"id":296,"depth":571,"text":297},{"id":321,"depth":571,"text":322},{"id":337,"depth":571,"text":338},{"id":374,"depth":571,"text":375},{"id":402,"depth":571,"text":403},{"id":445,"depth":571,"text":446},{"id":482,"depth":571,"text":483},{"id":515,"depth":571,"text":516,"children":585},[586,588,589,590,591],{"id":520,"depth":587,"text":521},3,{"id":527,"depth":587,"text":528},{"id":534,"depth":587,"text":535},{"id":541,"depth":587,"text":542},{"id":548,"depth":587,"text":549},{"id":555,"depth":571,"text":556},"Technology Insights","/images/blog/government-information-system-development-guide.webp","2026/08/31","md",[598,599,600,601,602],{"question":521,"answer":524},{"question":528,"answer":531},{"question":535,"answer":538},{"question":542,"answer":545},{"question":549,"answer":552},true,{},"government information system","/en/article/government-information-system-development-guide",{"title":95,"description":105},[609,612,615,617,620,622],{"name":610,"issuer":611},"Guidelines for Information System Development and Maintenance (資訊相關系統開發與維護注意事項; unofficial translation)","Water Resources Agency, Ministry of Economic Affairs (internal rules)",{"name":613,"issuer":614},"Government Procurement Act, Article 26 (政府採購法第二十六條)","Public Construction Commission, Executive Yuan",{"name":616,"issuer":614},"Regulations for Selection and Fee Calculation of Information Service Providers Commissioned by Agencies (機關委託資訊服務廠商評選及計費辦法; unofficial translation)",{"name":618,"issuer":619},"Cyber Security Management Act, Article 10 (資通安全管理法第十條)","Current statute",{"name":621,"issuer":619},"Regulations Governing the Classification of Cyber Security Responsibility Levels, Article 11 (資通安全責任等級分級辦法第十一條)",{"name":623,"issuer":624},"Government Website Service Management Guidelines (政府網站服務管理規範; unofficial translation)","Ministry of Digital Affairs","en/article/government-information-system-development-guide",null,"blog","Gtpy31eRYS8pOeI2ctVU8SXohYeY_uq-wBmtcEs8ngc",[630,635,641],{"slug":631,"title":632,"time":633,"cover":634,"need":605},"government-information-system-requirements-specification-guide","How to Write a Requirements Specification for a Government Information System: From Needs and Features to Acceptance","2026/09/01","/images/blog/government-information-system-requirements-specification-guide.webp",{"slug":636,"title":637,"time":638,"cover":639,"need":640},"logistics-management-system-guide","How to Choose a Logistics Management System: Dispatch, Proof of Delivery, and Integration with Existing Systems","2026/10/08","/images/blog/logistics-management-system-guide.webp","logistics system",{"slug":642,"title":643,"time":644,"cover":645,"need":646},"order-management-system-guide","How to Choose an Order Management System: Off-the-Shelf Software, ERP, and Custom Development Compared","2026/10/07","/images/blog/order-management-system-guide.webp","order management system",1792411071526]