**Funksjonelle krav** eller **funksjonelle primitiver** er definisjonen av en funksjon eller tjeneste i et system eller komponent i programvareutvikling og systemutvikling. En funksjon er beskrevet som et sett av inndata, oppførselen, utdata.

Funksjonelle krav kan være beregninger, teknisk informasjon, datamanipulasjon og behandling, og andre spesifikke funksjoner som definerer *hva* et system er ment å oppnå. Atferdskrav som beskriver alle tilfeller hvor systemet bruker de funksjonelle krav som er fremsatt gjennom brukstilfeller. Funksjonelle krav blir også støttet av ikke-funksjonelle krav (også kjent som *krav til kvalitet*), som setter føringer på design og implementering (for eksempel krav til ytelse, sikkerhet, pålitelighet). Generelt er funksjonelle krav på formen «systemet *må gjøre* <krav>», mens ikke-funksjonelle krav er «systemet *skal være* <krav>». Plan for implementering av *funksjonelle* krav er beskrevet i systemets *design*. Plan for implementering av *ikke-funksjonelle* krav er beskrevet i systemets *arkitektur*, fordi de er betydelige arkitekturkrav.

I kravspesifikasjonen blir det definert funksjonelle krav som angir bestemte resultater som skal komme fra et system. Dette er motsatt av ikke-funksjonelle krav som spesifiserer generelle egenskaper, slik som kostnader og pålitelighet. Funksjonelle krav driver *programarkitekturen* til systemet, mens de ikke-funksjonelle kravene driver den *tekniske arkitekturen* til systemet.

I noen tilfeller vil en analytiker generere brukstilfeller (engelsk: *use cases*) etter å ha samlet inn og validert et sett av funksjonelle krav. Hierarkiet av funksjonelle krav er: krav fra bruker (*user*) og interessenter (*stakeholders*) → funksjonen (*feature*) → brukstilfelle → forretningsregel. Hvert brukstilfelle illustrerer atferdsmessige scenarier gjennom ett eller flere funksjonelle krav. Ofte vil en analytiker begynne med å fremmane et sett av brukstilfeller, som analytikeren kan omforme til et sett av funksjonelle krav som må implementeres for at en bruker skal kunne utføre det fullstendige brukstilfellet.

Prosessen
---------

En typisk funksjonelt krav vil inneholde et unikt navn og nummer, en kort oppsummering, og en begrunnelse. Denne informasjonen brukes for å hjelpe leseren til å forstå hvorfor kravet er nødvendig, og for å spore kravet gjennom utviklingen av systemet.

Kjernen i kravspesifikasjonen er beskrivelsen av den ønskede atferden, som må være klar og tydelig. Den ønskede atferden kan komme fra regler som beskriver en organisasjon eller bedrift, eller reglene kan bli funnet gjennom diskusjoner med brukere, interessenter, og andre eksperter innen organisasjonen. Mange krav kan bli avdekket ved å sette opp brukstilfeller. Når aktuelle regler blir funnet så oppretter analytikeren en plassholder for kravet med et navn og et sammendrag, slik at han kan utforske detaljene senere når detaljene er bedre kjent.

Se også
-------

* Funksjon (matematikk)

Referanser
----------

1. ↑  «Supplement 4-A, A Procedure for Requirements Analysis». *Systems Engineering Fundamentals* (PDF). United States Government US Army. 2001. ISBN 978-1484120835. Arkivert fra originalen (PDF) 31. januar 2017. Besøkt 18. mars 2016.

Litteratur
----------

* Wiegers, Karl E. (2003). *Software Requirements* (2 utg.). Redmond: Microsoft Press. ISBN 978-0-7356-1879-4. Arkivert fra originalen 22. mars 2016. Besøkt 12. juni 2016.
* Stellman, Andrew; Greene, Jennifer (2005). *Applied Software Project Management* (1 utg.). Cambridge, MA: O'Reilly Media. ISBN 978-0-596-00948-9.
* Sommerville, Ian (2006). *Software Engineering* (8 utg.). ISBN 978-0-321-31379-9. Arkivert fra originalen 1. juni 2013. Besøkt 12. juni 2016.
* Roman, G.-C. (april 1985). «A taxonomy of current issues in requirements engineering». *Computer*. 15 (4): 14–23. ISSN 0018-9162.
* Yeh, R.T. (november 1982). «Requirements Analysis- A Management Perspective». *Proc. COMPSAC '82*: 410–416.
* Jansen, Arne. «Kravdefinisjon og kravspesifikasjon». *ndla.no*. Besøkt 21. juni 2016.