Mikä on ei-toiminnallinen vaatimus ohjelmistosuunnittelussa?

by: Charles Moore Charles Moore
Hours Päivitetty

⚡ Älykäs yhteenveto

Ei-toiminnalliset vaatimukset määrittelevät laatuominaisuuksia, kuten suorituskyvyn, turvallisuuden, käytettävyyden, luotettavuuden, skaalautuvuuden ja siirrettävyyden. Ne määrittelevät, kuinka hyvin ohjelmistojärjestelmän on toimittava, ja muuttavat epämääräiset odotukset mitattaviksi, testattaviksi ja täytäntöönpanokelpoisiksi suunnittelutavoitteiksi koko toimitussyklin ajan.

  • 📘 Määritelmä: Ei-toiminnallinen vaatimus eli NFR kuvaa järjestelmän suorituskykyä, turvallisuutta, käytettävyyttä, luotettavuutta ja siirrettävyyttä.
  • 🗂️ Yleiset tyypit: Käytettävyys, tietoturva, luotettavuus, skaalautuvuus, kapasiteetti, saatavuus, ylläpidettävyys ja määräystenmukaisuus ovat kategorioita, joita tiimit track useimmiten.
  • 📊 FURPS+-malli: FURPS+ ryhmittelee NFR:t toiminnallisuuteen, käytettävyyteen, luotettavuuteen, suorituskykyyn, tuettuun sisältöön sekä suunnittelu- tai käyttöliittymärajoituksiin.
  • 🎯 Testattavat lauseet: Korvaa ”nopea” tai ”turvallinen” numeerisilla kynnysarvoilla ja varmennusmenetelmillä, jotta NFR voidaan testata ja hyväksyä.
  • 🆚 Toiminnallinen kontrasti: Toiminnalliset vaatimukset kertovat, mitä järjestelmä tekee; ei-toiminnalliset vaatimukset kertovat, kuinka hyvin se tekee sen todellisissa olosuhteissa.
  • ✅ Vaikutus liiketoimintaan: Puuttuvat NFR:t ovat johtava syy tuotantohäiriöihin, sääntelyyn liittyviin havaintoihin ja kalliisiin myöhäisvaiheen arkkitehtuurin uudelleentyöstöihin.
Lue lisää

Ei-toiminnallinen vaatimus ohjelmistotekniikassa

Mikä on ei-toiminnallinen vaatimus?

A Ei-toiminnallinen vaatimus (NFR) määrittelee ohjelmistojärjestelmän laatuominaisuuden. NFR:t arvioivat järjestelmää reagointikyvyn, käytettävyyden, turvallisuuden, siirrettävyyden ja muiden menestyksen kannalta kriittisten laatuominaisuuksien perusteella. Yleinen esimerkki ei-toiminnallisesta vaatimuksesta on "Kuinka nopeasti verkkosivusto latautuu?" Ei-toiminnallisten vaatimusten täyttämättä jättäminen tuottaa järjestelmiä, jotka turhauttavat käyttäjiä.

Ohjelmistosuunnittelun ei-toiminnalliset vaatimukset asettavat rajoituksia järjestelmän suunnittelulle ketterän kehitystyön aikana. Esimerkiksi sivuston tulisi latautua kolmessa sekunnissa, kun samanaikaisten käyttäjien määrä ylittää 10 000. Ei-toiminnallisten vaatimusten kuvaaminen on aivan yhtä tärkeää kuin toiminnallisten vaatimusten tallentaminen.

Ei-toiminnallisten vaatimusten tyypit

Ei-toiminnallisten vaatimusten pääluokat ovat:

Ei-toiminnallisten vaatimusten tyypit

Ei-toiminnallisten vaatimusten tyypit

  • Käytettävyys
  • huollettavuus
  • hallittavuus
  • Palautettavuus
  • Turvallisuus
  • Päiväys Integrity
  • Koko
  • Saatavuus:
  • skaalautuvuus
  • Interoperability
  • Luotettavuus
  • ylläpidettävyys
  • Sääntelyn noudattaminen
  • Ympäristön rajoitukset

Esimerkkejä ei-toiminnallisista vaatimuksista

Tässä on käytännön esimerkkejä ei-toiminnallisista vaatimuksista:

  1. Käyttäjien on vaihdettava alkuperäinen salasana ensimmäisen onnistuneen kirjautumisen jälkeen, eikä alkuperäistä salasanaa saa koskaan käyttää uudelleen.
  2. Työntekijöiden ei saa päivittää omia palkkatietojaan, ja kaikista tällaisista yrityksistä on ilmoitettava turvallisuuspäällikölle.
  3. Jokainen käyttäjän epäonnistunut yritys käyttää tietoalkiota on kirjattava lokitietoon.
  4. Verkkosivuston tulee tukea 20 miljoonaa samanaikaista käyttäjää hidastamatta vasteaikoja.
  5. Ohjelmiston tulee olla kannettava, jotta siirtyminen käyttöjärjestelmästä toiseen ei aiheuta ongelmia.
  6. Tietosuojan, rajoitettujen teknologioiden viennin ja immateriaalioikeuksien on oltava auditoitavissa.

Toiminnalliset vs. ei-toiminnalliset vaatimukset

Toiminnallisten ja ei-toiminnallisten vaatimusten tärkeimmät erot ovat:

parametrit Toiminnallinen vaatimus Ei-toiminnallinen vaatimus
Mikä se on? Verbi Ominaisuudet
Vaatimus Se on pakollinen Se ei ole pakollista
Kaappaustyyppi Se on tallennettu käyttötapaukseen. Se on kuvattu laatumääritteeksi.
Lopputulos Tuotteen ominaisuus Tuotteen ominaisuudet
Kaappaaminen Helppo vangita Vaikea vangita
Tavoite Auttaa sinua varmistamaan ohjelmiston toimivuuden. Auttaa sinua tarkistamaan ohjelmiston suorituskyvyn.
Tarkennusalue Keskity käyttäjän tarpeisiin Keskittyy käyttäjän odotuksiin.
Dokumentaatio Kuvaile, mitä tuote tekee Kuvaa, miten tuote toimii
Testin tyyppi Toiminnallinen testaus kuten järjestelmä-, integraatio-, kokonaisvaltainen testaus, API-testaus jne. Ei-toiminnallinen testaus, kuten suorituskyky, stressi, käytettävyys, tietoturvatestaus jne.
Testin suorittaminen Testin suoritus suoritetaan ennen ei-toiminnallista testausta. Toimintatestin jälkeen
tuotetiedot Ominaisuudet Tuotteen ominaisuudet

AIHEESEEN LIITTYVÄT ARTIKKELIT

Ei-toiminnallisten vaatimusten edut

Tärkeimmät edut Ei-toiminnallinen testaus ovat:

  • Ei-toiminnalliset vaatimukset varmistavat, että järjestelmä noudattaa lakisääteisiä ja vaatimustenmukaisuussääntöjä.
  • Ne suojaavat järjestelmän luotettavuutta, saatavuutta ja suorituskykyä.
  • Ne tarjoavat hyvän käyttökokemuksen ja helppokäyttöisyyden.
  • Ne muokkaavat ohjelmiston tietoturvapolitiikkaa.

Ei-toiminnallisten vaatimusten haitat

Ei-toiminnallisten vaatimusten yleisiä haittoja ovat:

  • Ei-toiminnalliset vaatimukset voivat vaikuttaa useisiin korkean tason ohjelmistoalijärjestelmiin.
  • Ne vaativat erityistä huomiota arkkitehtuurin ja korkean tason suunnittelun aikana, mikä lisää kustannuksia.
  • Toteutus harvoin liittyy yhteen ohjelmistoalijärjestelmään.
  • Niitä on vaikea muokata, kun arkkitehtuurivaihe on valmis.

FURPS+-malli ei-toiminnallisten vaatimusten luokitteluun

FURPS+ on laajimmin käytetty ei-toiminnallisten vaatimusten taksonomia. Alun perin Hewlett-Packardin kehittämä se ryhmittelee laatuominaisuudet viiteen pääluokkaan sekä lisärajoituksiin, jotka on merkitty plussalla (+). Malli auttaa liiketoiminta-analyytikoita välttämään kokonaisen vaatimusluokan huomiotta jättämisen.

  • Toimivuus: Perusominaisuuksia laajempi ominaisuusvalikoima, turvallisuus ja uudelleenkäytettävyys.
  • Käytettävyys: Inhimilliset tekijät, estetiikka, johdonmukaisuus, dokumentointi ja käyttäjäkokemuksen reagointikyky.
  • Luotettavuus: Saatavuus, keskimääräinen vikaantumisväli, toipuvuus, ennustettavuus ja tarkkuus.
  • Suorituskyky: Nopeus, läpäisykyky, kapasiteetti, skaalautuvuus ja resurssien kulutus kuormituksen aikana.
  • Tuettavuus: Toimitetun järjestelmän testattavuus, joustavuus, asennettavuus, lokalisoitavuus ja ylläpidettävyys.
  • Plussa (+): Suunnittelu, toteutus, rajapinta ja fyysiset rajoitteet, kuten vaaditut alustat, standardit tai laitteistot.

Tiimit, jotka kartoittavat kaikki ei-toiminnalliset vaatimukset FURPS+-kategoriaan, toimittavat epätodennäköisemmin järjestelmän, joka täyttää ominaisuudet, mutta epäonnistuu suorituskyvyn, turvallisuuden tai ylläpidettävyyden osalta.

Testattavien ei-toiminnallisten vaatimusten kirjoittaminen

Hyvin kirjoitettu ei-toiminnallinen vaatimus on mitattavissa, todennettavissa ja ajallisesti sidottu. Epämääräiset lausunnot, kuten "järjestelmän on oltava nopea" tai "sovelluksen tulee olla turvallinen", ovat pyrkimyksiä, eivät vaatimuksia. Noudata alla olevia ohjeita muuntaaksesi aikomuksen testattavaksi ei-toiminnalliseksi vaatimukseksi.

  1. Tunnista laatuominaisuus. Yhdistä huolenaihe FURPS+-kategoriaan, jotta tiimi tietää, onko kyseessä suorituskyky-, käytettävyys-, tietoturva- vai luotettavuusvaatimus.
  2. Valitse mittari. Jokainen NFR tarvitsee yksikön – millisekunteja, pyyntöjä sekunnissa, samanaikaisia ​​käyttäjiä, käyttöajan prosenttiosuutta tai vaatimustenmukaisuusstandardin, kuten ISO 27001.
  3. Aseta numeerinen kynnysarvo. Korvaa ”nopea” sanalla ”alle 400 millisekuntia 95. persentiilillä”. Korvaa ”erittäin käytettävissä” sanalla ”99.9 prosentin kuukausittainen käyttöaika”.
  4. Kuvaile ehtoa. Ilmoita kuormitus, ympäristö tai käyttäjäsegmentti, johon kynnysarvo koskee, kuten "huippumyynnin aikana, kun samanaikaisia ​​käyttäjiä on 10 000".
  5. Määrittele vahvistusmenetelmä. Huomioi testityyppi – kuormitustesti, tunkeutumistesti, kaaoskoe, saavutettavuustarkastus – ja työkalu, joka vahvistaa kynnysarvon.
  6. Käytä SMART-tarkistusta. Varmista, että vaatimus on spesifi, mitattava, saavutettava, relevantti ja aikasidonnainen, ennen kuin se siirtyy tilausjonoon.

Esimerkki uudelleenkirjoittamisesta: ”Järjestelmän on oltava nopea” muotoutuu muotoon ”Kassasivun on vastattava alle 500 millisekunnissa 95. persentiilillä 5 000 samanaikaisella käyttäjällä, mikä on varmistettu” JMeter kuormitustestaa jokaisen julkaisun." Tarkistettu lausunto antaa kehittäjille mahdollisuuden suunnitella sen, testaajille tarkistaa sen ja tuoteomistajille hyväksyä sen ilman vastaväitteitä.

UKK

Tekoälyllä toimivat kuormitus- ja suorituskykytyökalut luovat realistista liikennettä, havaitsevat poikkeavuuksia vasteaikajakaumissa ja ennustavat skaalausrajoituksia ennen tuotantoa. Tekoäly tarkastaa myös lokit ja käyttömallit merkitäkseen tietoturvatapahtumia, joita perinteiset sääntöpohjaiset työkalut eivät huomaa.

Copilot ja GPT muuntavat epämääräiset laatuvaatimukset mitattavissa oleviksi NFR-vaatimuksiksi, joissa on mittarit, kynnysarvot, ehdot ja varmennusmenetelmät. Liiketoiminta-analyytikot tarkistavat jokaisen luonnoksen FURPS+-luokkien ja SMART-kehyksen avulla ennen sen hyväksymistä tilausjonoon.

Toiminnallinen testaus tarkistaa, toimivatko ominaisuudet, kuten kirjautuminen tai haku, oikein. Ei-toiminnallinen testaus mittaa järjestelmän suorituskykyä kuormituksen, stressin ja käytön aikana, ja se kattaa suorituskyky-, tietoturva-, käytettävyys-, yhteensopivuus- ja luotettavuustavoitteet.

Skaalautuvuus, saatavuus, viive, joustavuus ja kustannustehokkuus hallitsevat pilvipohjaisia ​​NFR-ratkaisuja. Myös tiimit track havaittavuus, katastrofien palautumistavoitteet, kuten RPO ja RTO, sekä usean alueen yhteensopivuus, koska ne ohjaavat useimpia pilviarkkitehtuuripäätöksiä.

Valitse mittari, jolla on yksikkö, aseta numeerinen kynnysarvo, kuvaile ehto, jossa sitä sovelletaan, ja nimeä vahvistusmenetelmä. Esimerkiksi vasteaika alle 400 millisekuntia 95. persentiilissä 5 000 käyttäjällä, vahvistettuna JMeter.

Tietojen salaus sekä tallennetussa että siirrettävässä tilassa, todennuksen vahvuus, roolipohjainen valtuutus, auditointiloki, istunnon aikakatkaisu ja standardien, kuten ISO 27001, PCI DSS ja GDPR, noudattaminen ovat useimpien tiimien dokumentoimia tietoturvan NFR-sääntöjä.

Epämääräisten adjektiivien käyttö, mittarin tai ehdon poisjättäminen, NFR-vaatimusten listaaminen vasta projektin lopussa ja sellaisten vakiomuotoisten tekstien kopioiminen ja liittäminen, joita mikään testi ei pysty todentamaan, ovat yleisimpiä virheitä, jotka johtavat arkkitehtuurin uudelleentyöstämiseen myöhäisessä vaiheessa.

NFR:t sisältyvät ohjelmistovaatimusten määrittelyyn, arkkitehtuuripäätösten tietueisiin, palvelutasosopimuksiin ja valmiiksi määriteltyjen tarkistuslistoihin. Ketterät tiimit liittävät usein mitattavissa olevia NFR:iä eeppisiin suunnitelmiin ja kunkin käyttäjätarinan valmiusmääritelmään.

Tiivistä tämä viesti seuraavasti: