{"id":70798,"date":"2024-05-16T19:51:53","date_gmt":"2024-05-16T10:51:53","guid":{"rendered":"https:\/\/monolith.law\/no\/?p=70798"},"modified":"2024-08-09T00:35:24","modified_gmt":"2024-08-08T15:35:24","slug":"system-development-specs-function","status":"publish","type":"post","link":"https:\/\/monolith.law\/no\/it\/system-development-specs-function","title":{"rendered":"Hvor langt b\u00f8r funksjoner som ikke er spesifisert i systemutviklingsdokumentasjonen implementeres i henhold til loven?"},"content":{"rendered":"\n<p>Prosjekter for utvikling av IT-systemer som brukes i bedrifter, blir i prinsippet laget i henhold til forh\u00e5ndsdefinerte spesifikasjoner. Men p\u00e5 den annen side, hvis vi vurderer betydningen av at leverand\u00f8ren er betrodd utviklingsarbeidet som en ekspert p\u00e5 systemutvikling, kan det hende at brukernes forventninger ikke er s\u00e5 lave at det er tilstrekkelig \u00e5 bare implementere det som er skrevet i spesifikasjonene mekanisk. I denne artikkelen vil vi forklare hvor langt man b\u00f8r g\u00e5 i \u00e5 p\u00e5ta seg plikten til \u00e5 implementere programmer som ikke er nevnt i spesifikasjonene, men som er n\u00f8dvendige for \u00e5 oppfylle utviklingsform\u00e5let.<br><\/p>\n\n\n\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_53 counter-hierarchy ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<span class=\"ez-toc-title-toggle\"><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/monolith.law\/no\/it\/system-development-specs-function\/#Juridiske_problemer_knyttet_til_implementering_av_ikke-spesifiserte_funksjoner\" title=\"Juridiske problemer knyttet til implementering av ikke-spesifiserte funksjoner\">Juridiske problemer knyttet til implementering av ikke-spesifiserte funksjoner<\/a><ul class='ez-toc-list-level-3'><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/monolith.law\/no\/it\/system-development-specs-function\/#Leverandorens_arbeid_krever_skjonn\" title=\"Leverand\u00f8rens arbeid krever skj\u00f8nn\">Leverand\u00f8rens arbeid krever skj\u00f8nn<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/monolith.law\/no\/it\/system-development-specs-function\/#Skjonn_bor_utoves_innenfor_strenge_utviklingsprosesser\" title=\"Skj\u00f8nn b\u00f8r ut\u00f8ves innenfor strenge utviklingsprosesser\">Skj\u00f8nn b\u00f8r ut\u00f8ves innenfor strenge utviklingsprosesser<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/monolith.law\/no\/it\/system-development-specs-function\/#Hva_bor_gjores_som_en_ekspert_uten_a_vaere_bundet_av_spesifikasjoner\" title=\"Hva b\u00f8r gj\u00f8res som en ekspert, uten \u00e5 v\u00e6re bundet av spesifikasjoner?\">Hva b\u00f8r gj\u00f8res som en ekspert, uten \u00e5 v\u00e6re bundet av spesifikasjoner?<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/monolith.law\/no\/it\/system-development-specs-function\/#Juridiske_forpliktelser_bestemmes_i_henhold_til_intensjonen_i_spesifikasjoner_og_kontrakter\" title=\"Juridiske forpliktelser bestemmes i henhold til intensjonen i spesifikasjoner og kontrakter\">Juridiske forpliktelser bestemmes i henhold til intensjonen i spesifikasjoner og kontrakter<\/a><ul class='ez-toc-list-level-3'><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/monolith.law\/no\/it\/system-development-specs-function\/#Rettstilfelle_der_implementeringsplikt_ble_avvist_pa_grunn_av_manglende_spesifikasjon\" title=\"Rettstilfelle der implementeringsplikt ble avvist p\u00e5 grunn av manglende spesifikasjon\">Rettstilfelle der implementeringsplikt ble avvist p\u00e5 grunn av manglende spesifikasjon<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/monolith.law\/no\/it\/system-development-specs-function\/#Rettseksempler_der_implementeringsplikt_ble_bekreftet_selv_uten_spesifikasjon\" title=\"Rettseksempler der implementeringsplikt ble bekreftet selv uten spesifikasjon\">Rettseksempler der implementeringsplikt ble bekreftet selv uten spesifikasjon<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/monolith.law\/no\/it\/system-development-specs-function\/#Hva_vi_kan_laere_av_begge_dommene\" title=\"Hva vi kan l\u00e6re av begge dommene\">Hva vi kan l\u00e6re av begge dommene<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/monolith.law\/no\/it\/system-development-specs-function\/#Hvordan_bor_man_vurdere_godtgjorelse_for_utvikling_som_ikke_er_spesifisert_i_spesifikasjonen\" title=\"Hvordan b\u00f8r man vurdere godtgj\u00f8relse for utvikling som ikke er spesifisert i spesifikasjonen?\">Hvordan b\u00f8r man vurdere godtgj\u00f8relse for utvikling som ikke er spesifisert i spesifikasjonen?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-10\" href=\"https:\/\/monolith.law\/no\/it\/system-development-specs-function\/#Oppsummering\" title=\"Oppsummering\">Oppsummering<\/a><\/li><\/ul><\/nav><\/div>\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Juridiske_problemer_knyttet_til_implementering_av_ikke-spesifiserte_funksjoner\"><\/span>Juridiske problemer knyttet til implementering av ikke-spesifiserte funksjoner<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/monolith-law.jp\/wp-content\/uploads\/2019\/10\/shutterstock_164703428-1024x614.jpg\" alt=\"\" class=\"wp-image-5431\" \/><figcaption class=\"wp-element-caption\">Vi forklarer viktige punkter om betydningen av \u00e5 ha &#8220;skj\u00f8nn&#8221; i systemutvikling.<\/figcaption><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Leverandorens_arbeid_krever_skjonn\"><\/span>Leverand\u00f8rens arbeid krever skj\u00f8nn<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>En stor egenskap ved kontrakter knyttet til systemutviklingsprosjekter og de tilh\u00f8rende juridiske problemene er at leverand\u00f8ren som p\u00e5tar seg arbeidet, har betydelig skj\u00f8nn.<\/p>\n\n\n\n<p>Relatert artikkel: <a href=\"https:\/\/monolith-law.jp\/corporate\/project-management-duties\" target=\"_blank\" rel=\"noreferrer noopener\">Hva er prosjektledelsesplikter i systemutvikling?[ja]<\/a><\/p>\n\n\n\n<p>Det er imidlertid viktig \u00e5 merke seg at &#8220;skj\u00f8nn&#8221; i denne sammenhengen ikke n\u00f8dvendigvis gjelder for alle faser av systemutviklingsprosessen. Etter \u00e5 ha identifisert hver fase og brutt dem ned i detaljerte oppgaver, kan det v\u00e6re mange oppgaver som ligner enkle arbeidsoppgaver. Generelt sett, jo tidligere i prosessen, desto mer skj\u00f8nn kreves for \u00e5 utf\u00f8re arbeidet. Dette er ogs\u00e5 grunnen til at de tidlige fasene ofte passer godt med kontraktstyper som oppdragsavtaler.<\/p>\n\n\n\n<p>Relatert artikkel: <a href=\"https:\/\/monolith-law.jp\/corporate\/contract-and-timeandmaterialcontract\" target=\"_blank\" rel=\"noreferrer noopener\">Forskjellen mellom oppdragsavtaler og oppdragsbaserte kontrakter i systemutvikling[ja]<\/a><\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Skjonn_bor_utoves_innenfor_strenge_utviklingsprosesser\"><\/span>Skj\u00f8nn b\u00f8r ut\u00f8ves innenfor strenge utviklingsprosesser<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Selv om leverand\u00f8ren har betydelig skj\u00f8nn i systemutvikling, kan det \u00e5 ukritisk akseptere klientens \u00f8nsker f\u00f8re til store problemer i senere faser. Et IT-system best\u00e5r av mange sm\u00e5 komponenter, og selv sm\u00e5 endringer kan kreve betydelige endringer i arbeidsmengden fra utviklerens perspektiv. For mer informasjon om hvordan man h\u00e5ndterer endringer i systemutviklingsspesifikasjoner fra et juridisk perspektiv, se f\u00f8lgende artikkel. Denne artikkelen forklarer hvordan man h\u00e5ndterer endringer, og diskuterer ogs\u00e5 hvor stor innvirkning spesifikasjonsendringer kan ha p\u00e5 arbeidet fra en teknikers perspektiv.<\/p>\n\n\n\n<p>Relatert artikkel: <a href=\"https:\/\/monolith-law.jp\/corporate\/howto-manage-change-in-system-development\" target=\"_blank\" rel=\"noreferrer noopener\">Hvordan h\u00e5ndtere endringer i systemutvikling fra et juridisk perspektiv[ja]<\/a><br><\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Hva_bor_gjores_som_en_ekspert_uten_a_vaere_bundet_av_spesifikasjoner\"><\/span>Hva b\u00f8r gj\u00f8res som en ekspert, uten \u00e5 v\u00e6re bundet av spesifikasjoner?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>For \u00e5 sikre en smidig fremdrift i systemutviklingsprosjekter er det viktig \u00e5 definere utviklingskravene p\u00e5 forh\u00e5nd og planlegge i henhold til dem. Samtidig er det situasjoner der det ikke er tilstrekkelig \u00e5 bare f\u00f8lge de forh\u00e5ndsdefinerte kravene for \u00e5 oppfylle rollen som systemutviklingsekspert. I denne dilemmaet oppst\u00e5r sp\u00f8rsm\u00e5let om hva som b\u00f8r implementeres, selv om det ikke er spesifisert i kravene.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Juridiske_forpliktelser_bestemmes_i_henhold_til_intensjonen_i_spesifikasjoner_og_kontrakter\"><\/span>Juridiske forpliktelser bestemmes i henhold til intensjonen i spesifikasjoner og kontrakter<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>Innholdet av det som skal implementeres, bestemmes ut fra intensjonen i kontrakter og spesifikasjoner, selv om det ikke er eksplisitt nevnt i disse dokumentene. Med andre ord, det avgj\u00f8res ut fra hva slags mening eller hensikt som ligger bak de avtalte bestemmelsene. La oss se p\u00e5 noen rettspraksis-eksempler nedenfor.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Rettstilfelle_der_implementeringsplikt_ble_avvist_pa_grunn_av_manglende_spesifikasjon\"><\/span>Rettstilfelle der implementeringsplikt ble avvist p\u00e5 grunn av manglende spesifikasjon<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>I det siterte rettstilfellet nedenfor, utviklet en leverand\u00f8r et system som n\u00e5dde en midlertidig driftsfase, men det oppsto en tvist da kunden krevde \u00e5 kansellere kontrakten p\u00e5 grunn av manglende n\u00f8dvendige funksjoner. Kunden hevdet at den manglende funksjonen var &#8220;automatisk dataoppdatering&#8221;, som ble p\u00e5st\u00e5tt \u00e5 v\u00e6re et hovedsalgsargument for systemet. Retten anerkjente imidlertid ikke denne implementeringsplikten.<br><\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">\n<p>Som fastsl\u00e5tt ovenfor, er det ingen indikasjon i den aktuelle kontrakten, grunnleggende designspesifikasjonen eller detaljdesignspesifikasjonen p\u00e5 at funksjon \u2462 var en del av systemutviklingen.<\/p>\n\n\n\n<p>Saks\u00f8keren hevder at funksjon \u2462 var et hovedsalgsargument for systemet som ble levert av saks\u00f8kte, og understreker n\u00f8dvendigheten av denne funksjonen. <u>Hvis denne p\u00e5standen var korrekt, ville dette ha v\u00e6rt tydelig spesifisert i kontrakten<\/u>, <u>og uten en slik spesifikasjon er det vanskelig \u00e5 tro at utviklingen av denne funksjonen var avtalt<\/u>.<\/p>\n<cite>Tokyo District Court, 18. februar Heisei 21 (2009)<\/cite><\/blockquote>\n\n\n\n<p>Domfellelsen kan enkelt oppsummeres som &#8220;hvis det ikke er spesifisert i designspesifikasjonen, trenger det ikke \u00e5 utvikles&#8221;. Men mer presist, b\u00f8r det sies at avgj\u00f8relsen ble tatt basert p\u00e5 &#8220;hensikten&#8221; med spesifikasjonene i design- og kontraktsdokumentene, snarere enn bare det formelle faktum om hvorvidt det var spesifisert. Med andre ord, det er rimelig \u00e5 anta at det ikke var noen avtale om utviklingen av funksjonen, gitt at det ikke var spesifisert i design- eller kontraktsdokumentene.<br><\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Rettseksempler_der_implementeringsplikt_ble_bekreftet_selv_uten_spesifikasjon\"><\/span>Rettseksempler der implementeringsplikt ble bekreftet selv uten spesifikasjon<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>P\u00e5 den annen side finnes det rettseksempler som bekrefter plikten til \u00e5 implementere, selv om det ikke var spesifisert i kontrakten eller spesifikasjonene. Det f\u00f8lgende rettseksempelet omhandler utviklingen av et system for \u00e5 administrere medisinbrukshistorikk, hvor dataoverf\u00f8ring fra det eksisterende systemet til det nye systemet ikke ble gjennomf\u00f8rt. Dette f\u00f8rte til at brukeren ikke kunne benytte det nye systemet og derfor hevet kontrakten. Leverand\u00f8ren hevdet imidlertid at dataoverf\u00f8ring l\u00e5 utenfor deres ansvarsomr\u00e5de, noe som f\u00f8rte til en tvist.<\/p>\n\n\n\n<p>Utvikling av nye systemer inneb\u00e6rer ofte avvikling av eksisterende systemer og dataoverf\u00f8ring. Viktigheten av slike oppgaver og de tilh\u00f8rende juridiske problemene er detaljert forklart i f\u00f8lgende artikkel.<\/p>\n\n\n\n<p>Relaterte artikler: <a href=\"https:\/\/monolith-law.jp\/corporate\/the-transition-from-the-oldsystem\" target=\"_blank\" rel=\"noreferrer noopener\">Juridiske problemer ved overgang fra gamle systemer i systemutvikling[ja]<\/a><\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">\n<p>Det eksisterende systemet hadde allerede lagret data for over 50 000 pasienter, og <u>saks\u00f8ker brukte disse dataene for \u00e5 effektivisere administrasjonen<\/u>. Hvis det ikke var mulig \u00e5 overf\u00f8re pasientdataene fra det eksisterende systemet til det nye systemet, ville <u>det \u00e5penbart forstyrre apotekets dispensasjonsarbeid<\/u>, og det er rimelig \u00e5 anta at <u>saks\u00f8kers representant var klar over dette<\/u>. Videre, f\u00f8r kontrakten ble inng\u00e5tt, spurte saks\u00f8kers representant saks\u00f8ktes representant om muligheten for dataoverf\u00f8ring, noe saks\u00f8ktes representant ogs\u00e5 innr\u00f8mmet (utdrag). Det er vanskelig \u00e5 tro at <u>saks\u00f8kers representant ville ha bestemt seg for \u00e5 implementere det nye systemet, vel vitende om at det var en h\u00f8y sannsynlighet for at de m\u00e5tte taste inn data for over 50 000 pasienter manuelt<\/u>. I tillegg, som nevnt i punkt (1) i, kunne saks\u00f8kte ikke overf\u00f8re medisinbrukshistorikkdataene fra det eksisterende systemet til det nye systemet, og behandlet derfor dataene ved \u00e5 skrive dem ut p\u00e5 papir og deretter skanne dem til PDF-filer. Selv om dataoverf\u00f8ring ikke var en forutsetning i kontrakten, er det vanskelig \u00e5 tro at <u>saks\u00f8kte ville ha utf\u00f8rt en s\u00e5 tidkrevende oppgave som en tjeneste<\/u>.<\/p>\n<cite>Tokyo District Court, 18. november Heisei 22 (2010)<\/cite><\/blockquote>\n\n\n\n<p>Det som er viktig her, er form\u00e5let med kontrakten og &#8220;hensikten&#8221; med kontraktens bestemmelser. Hvis begge parter inngikk kontrakten med forst\u00e5elsen av at dataoverf\u00f8ring l\u00e5 utenfor arbeidsomr\u00e5det, ville det bety at b\u00e5de brukeren og leverand\u00f8ren inngikk kontrakten med en unaturlig intensjon, noe retten p\u00e5pekte. Det vil si at brukeren ville ha p\u00e5tatt seg en enorm mengde manuelt arbeid, og leverand\u00f8ren ville ha g\u00e5tt inn i prosjektet vel vitende om at det ville forstyrre brukerens arbeid, noe som er sv\u00e6rt urimelig.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Hva_vi_kan_laere_av_begge_dommene\"><\/span>Hva vi kan l\u00e6re av begge dommene<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Selv om kontrakten eller spesifikasjonene ikke nevnte dataoverf\u00f8ring, ble plikten til \u00e5 implementere dette bekreftet. En av grunnene til dette er at det handlet om &#8220;data&#8221;, som ikke vises p\u00e5 skjermen. Mangelen p\u00e5 &#8220;n\u00f8dvendige funksjoner&#8221; er derimot noe som vises direkte p\u00e5 systemets skjerm og utseende. Derfor er det ikke s\u00e5 vanskelig \u00e5 oppdage mangler i spesifikasjonene, selv for en som ikke er ekspert p\u00e5 systemutvikling. P\u00e5 den annen side er det vanskeligere for en ikke-ekspert \u00e5 forst\u00e5 viktigheten av dataoverf\u00f8ring, samt vanskelighetsgraden og arbeidsmengden som kreves. Derfor ble det ansett som noe leverand\u00f8ren, med sin ekspertise, burde h\u00e5ndtere smidig.<\/p>\n\n\n\n<p>Med dette i tankene kan vi si at mangler i spesifikasjonene eller kontrakten er n\u00e6rt knyttet til brukerens &#8220;samarbeidsplikt&#8221;. Sp\u00f8rsm\u00e5let er om brukeren virkelig har oppfylt sin &#8220;samarbeidsplikt&#8221; i forbindelse med inng\u00e5elsen av kontrakten og utarbeidelsen av spesifikasjonene. En generell forklaring p\u00e5 de juridiske forpliktelsene brukeren har i et systemutviklingsprosjekt, finner du i artikkelen nedenfor.<\/p>\n\n\n\n<p>Relatert artikkel: <a href=\"https:\/\/monolith-law.jp\/corporate\/user-obligatory-cooporation\" target=\"_blank\" rel=\"noreferrer noopener\">Hva er samarbeidsplikten til brukeren som bestiller systemutvikling?[ja]<\/a><\/p>\n\n\n\n<p>Ved \u00e5 lese den ovennevnte artikkelen, vil du ogs\u00e5 forst\u00e5 at det er en stor forskjell mellom brukerens samarbeid i forbindelse med identifisering av skjermbilder og n\u00f8dvendige funksjoner, og mangler i vurderingen av dataoverf\u00f8ring.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Hvordan_bor_man_vurdere_godtgjorelse_for_utvikling_som_ikke_er_spesifisert_i_spesifikasjonen\"><\/span>Hvordan b\u00f8r man vurdere godtgj\u00f8relse for utvikling som ikke er spesifisert i spesifikasjonen?<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/monolith-law.jp\/wp-content\/uploads\/2019\/10\/shutterstock_320070512-1024x683.jpg\" alt=\"\" class=\"wp-image-5433\" \/><figcaption class=\"wp-element-caption\">Hvis leverand\u00f8ren g\u00e5r med p\u00e5 \u00e5 utf\u00f8re arbeid som overstiger arbeidsomfanget, kan det v\u00e6re tilfeller hvor man kan kreve ekstra godtgj\u00f8relse.<\/figcaption><\/figure>\n\n\n\n<p>Et annet relevant sp\u00f8rsm\u00e5l i forbindelse med dette temaet er om det er lovlig \u00e5 kreve ekstra godtgj\u00f8relse for arbeid som ikke er spesifisert i spesifikasjonen. Vi forklarer detaljert om muligheten for \u00e5 \u00f8ke godtgj\u00f8relsen og hvordan man beregner estimert bel\u00f8p i f\u00f8lgende artikkel.<\/p>\n\n\n\n<p>Relatert artikkel: <a href=\"https:\/\/monolith-law.jp\/corporate\/increase-of-estimate\" target=\"_blank\" rel=\"noreferrer noopener\">Er det mulig \u00e5 \u00f8ke estimert bel\u00f8p for systemutvikling etterp\u00e5?[ja]<\/a><\/p>\n\n\n\n<p>I artikkelen ovenfor forklarer vi at det er viktig \u00e5 vurdere om det har v\u00e6rt arbeid som overstiger det opprinnelige arbeidsomfanget i forhold til godtgj\u00f8relsen. Med andre ord, i forhold til denne artikkelen, hvis leverand\u00f8ren g\u00e5r med p\u00e5 \u00e5 utvikle noe som ikke er inkludert i den opprinnelige spesifikasjonen (i denne artikkelen referert til som et negativt eksempel), kan man kreve ekstra godtgj\u00f8relse for dette.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Oppsummering\"><\/span>Oppsummering<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>Ved systemutvikling bestemmes leverand\u00f8rens rolle delvis av innholdet i kontrakter og spesifikasjoner. Men, n\u00e5r man tar i betraktning at leverand\u00f8ren er betrodd oppgaver basert p\u00e5 h\u00f8y tillit som eksperter, forst\u00e5r man at realiteten ikke kun bestemmes av formelle dokumenter. Det er viktig \u00e5 forst\u00e5 at lovene spiller en betydelig rolle i \u00e5 forst\u00e5 denne realiteten.<br><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Prosjekter for utvikling av IT-systemer som brukes i bedrifter, blir i prinsippet laget i henhold til forh\u00e5ndsdefinerte spesifikasjoner. Men p\u00e5 den annen side, hvis vi vurderer betydningen av at lever [&hellip;]<\/p>\n","protected":false},"author":32,"featured_media":72001,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[16],"tags":[19,31],"acf":[],"_links":{"self":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts\/70798"}],"collection":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/users\/32"}],"replies":[{"embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/comments?post=70798"}],"version-history":[{"count":3,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts\/70798\/revisions"}],"predecessor-version":[{"id":72794,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts\/70798\/revisions\/72794"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/media\/72001"}],"wp:attachment":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/media?parent=70798"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/categories?post=70798"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/tags?post=70798"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}