Grunnleggende om ikke-funksjonelle krav til IOS Apps - dummies

Ikke-funksjonelle krav (NFR) gir retningslinjer for hvordan du bygger en iOS-app riktig (slike krav kalles også kvalitetskrav eller design krav~~POS=HEADCOMP ). La oss starte med en kategorisering og eksempler på NFR. Si at du bygger en veiviserende app som vil plotte en rute fra ett sted til et annet. Her er de generelle kategoriene av NFR og eksempler for hver, spesielt i sammenheng med veiviseringsapp:

• Ytelse: Dette er i hovedsak hvor fort appen din fungerer. Et ytelseskrav for veiviseringsappen kan være at det plotter en rute på mindre enn 20 sekunder.

• Responsiveness: Dette kravet sikrer at appen din er klar til å svare på brukerens innspill eller en ekstern hendelse, uansett hva den gjør i øyeblikket. For eksempel lar appen brukeren å bytte til en annen funksjon, selv om det er opptatt å beregne en rute.

• Skalerbarhet: Skalbarhet er hvor bra appen din behandler økt bruk, eller størrelsen på dataene. For eksempel kan du kreve at tiden din app tar for å plotte en rute er lineær med avstanden mellom de to punktene.

• Brukervennlighet: Dette gjelder hvor enkelt folk kan bruke appen din. Et mål for brukervennlighet kan være tiden det tar for sluttbrukere å bli kjent med appens funksjoner uten trening eller hjelp.

• Pålitelighet: Dette er prosentandelen av tiden din app fungerer riktig for å levere de ønskede resultatene, til tross for potensielle feil i omgivelsene. For veiviserende app er det prosentandelen av tiden som den plotter ruten riktig, gitt at nettverket kanskje ikke er tilgjengelig, eller at båndbredden kan være begrenset.

  Du kan kreve at appen din har en pålitelighet på 99 prosent, noe som betyr at det i en gitt 24-timers dag ikke kan plotte en rute for ikke mer enn en prosent av dagen, eller ca. 15 minutter.

  Begrepet tilgjengelighet kan brukes sammen med pålitelighet, fordi de fleste er mer sannsynlig å forstå det ordet.

• Sikkerhet: Si at appen din lagrer alle tidligere ruter den har beregnet, og lar deg gjenbruke en lagret rute heller enn å beregne den.

  Hvis sikkerhet ikke er et krav, kan du lagre alle appdata i ukrypterte filer og på SD-kortet. Hvis sikkerhet er et problem, kan du imidlertid kryptere filene og lagre dem i appens private filområde, slik at innholdet deres ikke er lett tilgjengelig, slik at de slettes når appen avinstalleres.

• Modifiability: Dette kravet regulerer hvor enkelt appen din kan endres. For veiviserende app, kan dette kravet angi at appen kan bruke mer enn ett kart uten å måtte gjenoppbygges.

• Vedlikehold: Dette handler om hvor lett appen din finner feil og reparerer dem. Hvis for eksempel et kart er feil, kan du løse problemet ved å laste ned et riktig kart, eller må du kjøpe den neste versjonen av appen.

Kostnad er også ofte viktig. Når du bygger en app, må du bestemme hvilke ikke-funksjonelle krav som gjelder for appen din. Du må også forfine dine NFRer slik at du kan teste dem. For eksempel, for en NFR-ytelse må du kunne måle hastigheten på søknaden din på de riktige stedene (for eksempel mens skjermen vises).

Visse ikke-funksjonelle krav er spesielt viktige for mobile enheter, for eksempel ytelse og respons.

Ikke forsøk å oppfylle alle mulige ikke-funksjonelle krav i en app. Hvorfor bruke ressurser som implementerer funksjoner som brukere ikke vil verdsette? I stedet definere og, hvor det er aktuelt, kvantifisere i hvilken grad du vil møte NFR. Også NFR involverer alltid avvik. Å møte et enkelt ikke-funksjonelt krav kan noen ganger føre til at appen din ikke møter en annen.

For eksempel er ytelse og sikkerhet ofte i kryssformål. Økt sikkerhet implementeres ofte ved kryptering og dekryptering av lagrede data. Men å måtte dekryptere data for å kunne bruke det, og kryptere det etter at appen er ferdig med å bruke det, tar det tid, og reduserer dermed appens ytelse. Trikset med å møte NFR er å finne den rette balansen.