Vaatimus (tietojenkäsittelytiede)

(Ohjelmisto) -tekniikassa vaaditaan (usein englanninkielinen vaatimus ) lausunto vakiintuneesta kiinteistöstä tai palvelusta, joka tarjotaan tuotteelle , järjestelmälle tai prosessille .

Vaatimukset kirjataan, analysoidaan, määritetään ja todennetaan vaatimusten esittelyssä. Prosessi on sisällytetty vaatimusten hallintaan . Vaatimukset voidaan esimerkiksi dokumentoida asiakirjaan (esim. Määrittelyarkki ) tai taulukkojärjestelmään . Vuonna ketterän ohjelmistokehityksen , vaatimukset hallinnan ohjelmistoja käytetään joka tukee vaatimusten hallinta ( ruuhkaa Scrum , Jira, jne).

Vaatimusten tyypit

Vaatimusten luokittelussa on erilaisia ​​lähestymistapoja.

Vaatimukset - jotka ymmärretään järjestelmien ja ohjelmistotuotteiden laatukriteereiksi - voidaan luokitella ISO / IEC 25000: n tai ISO / IEC 25010: n laatumallien mukaan.

Yleisin on jako toiminnallisiin ja ei-toiminnallisiin vaatimuksiin.

A toiminnallinen vaatimus määrittää, mitä tuotteen pitäisi tehdä. Esimerkki:

"Tuotteen tulisi laskea tilin saldo avainpäivänä."

A ei-toiminnallisia vaatimuksia (englanninkielinen ei-toiminnallinen vaatimus , NFR) ei ole määritelty kirjallisuudessa yhtenäisesti. Yhteinen nimittäjä on, että se ylittää toiminnallisen vaatimuksen. Ei-toiminnalliset vaatimukset kuvaavat kuinka hyvin järjestelmän tulisi toimia; ne ymmärretään usein rajaehtoina ja laatuominaisuuksina . Esimerkki:

"Tuotteen on vastattava käyttäjälle sekunnissa."

Näiden kahden tyypin lisäksi rajoitukset (englanti ovat usein rajoituksia ) kuvattujen vaatimusten mukaisesti. Toistuvat rajaehdot ovat kustannusten yläraja ja määräaika, joka on noudatettava projektin loppuun saattamiseksi.

Ei-toiminnallisten vaatimusten luokitus

Vaikka toiminnalliset vaatimukset on järjestetty eri tavoin projektista riippuen, ei-toiminnallisille vaatimuksille on tyypillisiä rakenteita, esimerkiksi Volere tai DIN 66272 .

Ei-toiminnalliset vaatimukset voidaan jakaa kahteen pääryhmään:

Suorituskyvyn laatu

Tämä voidaan havaita käytön aikana (ajon aikana).

Jatkokehityksen laatu / evoluution laatu

Tämä ilmentyy järjestelmän staattisessa rakenteessa.

  • Käyttö ja ympäristöolosuhteet
  • Ylläpidettävyys , muutettavuus (analysoitavuus, vakaus, testattavuus, laajennettavuus)
  • Siirrettävyys ja siirrettävyys (mukautettavuus, asennettavuus, vaatimustenmukaisuus, vaihdettavuus)
  • Joustavuus (standardien tuki)
  • Skaalautuvuus (selviytyminen ongelman laajuuden muutoksista)
  • reunaehdot

Vaatimuksen rakenne

Tyypillisesti yksi vaatimus koostuu seuraavista komponenteista.

  • Tunniste ( vaatimusnumero ): Tunnistaa vaatimuksen yksilöllisesti.
  • Kuvaus ( kuvaus ): Kuvaa pyynnön lyhyen ja ytimekkään. Schienmann erottaa lyhyen ja pitkän kuvauksen ("vaatimuksen kuvaus"), kun taas Robertson ja Robertson tarjoavat vain yhden kentän, joka vastaa lyhyttä kuvausta.
  • Ongelman kuvaus ( perustelut ): Kuvaa ongelman, joka aiheuttaa pyynnön.
  • Source ( Originator ): Tunnistaa pyytävä henkilö tai asiakirja, josta pyynnön tuloksia, esimerkiksi lain määräyksiä.
  • Hyväksymiskriteeri ( sopivuuskriteeri ): Kuvaa mitattavan ehdon, jota käytetään myöhemmin tarkistamaan, onko vaatimus täytetty.

Näiden vakiokomponenttien lisäksi useat kirjoittajat ehdottavat muita rakenteellisia elementtejä. Kilpailevien vaatimusten priorisoinnilla on tärkeä rooli toteutusjärjestyksen määrittämisessä tai valinnassa, jos käytettävissä olevat resurssit (aika, raha ja ihmiset) eivät riitä täyttämään kaikkia vaatimuksia. Tässä Robertson ja Robertson ehdottavat Voleren menettelytapamallissaan seuraavia ominaisuuksia.

  • Asiakastyytyväisyys ( asiakastyytyväisyys ): Numeerinen arvo, joka osoittaa, kuinka vaatimuksen täyttymisellä on positiivinen vaikutus asiakkaan tyytyväisyyteen.
  • Asiakkaan tyytymättömyys ( Asiakkaan tyytymättömyys ): Numeerinen arvo, joka osoittaa, kuinka pyynnön täyttämättä jättämisellä on kielteinen vaikutus asiakkaan tyytyväisyyteen.
  • Prioriteetti ( prioriteetti ): Numeerinen arvo, joka määrittää tämän sovelluksen prioriteetin ja tulee sitten tärkeäksi, kun kaikkia vaatimuksia ei voida täyttää.
  • Ristiriidat ( ristiriidat ): Tässä luetellaan vaatimukset, jotka ovat ristiriidassa tämän vaatimuksen kanssa, ja niiden välillä on punnittava.

Schienmann ehdottaa seuraavia ominaisuuksia määrittääkseen vaatimukset tietyille (ohjelmisto) tuotteille.

  • Tuotteen julkaisu: Tunnistaa luotavan tuotteen version, jossa vaatimus on täytettävä.
  • Rakennusosa: Tunnistaa luodun tuotteen osan, jonka vaatimus on täytettävä.

Vaatimuksen varsinaista kuvausta voidaan tukea seuraavilla seikoilla, mikä edistää ymmärrystä ja välttää väärinkäsityksiä.

  • Lisämateriaalia ( tukimateriaalia ): asiakirjat, joita tarvitaan ymmärtää vaatimuksen.
  • Tavoite: Määrittää tavoitteen, johon pyritään.
  • Huomautus: Tarjoaa tilaa lisäkommenteille ja selvennyksille.
  • Nimikkeistö: Viittaa virallisesti määriteltyihin teknisiin termeihin, joita vaatimuksessa käytetään.

Koska vaatimukset eivät pysy vakioina, vaan pikemminkin kehittyvät projektin aikana, tarvitaan myös tietoa niiden elinkaaresta.

  • Vaatimuksen versiohistoria ( historia ) : milloin sen kukin muotoili, milloin kuka muutti jne.
  • Tila: Tunnistaa pyynnön nykyisen tilan, esimerkiksi onko urakoitsija jo hyväksynyt sen.
  • Avoin kohta: Tarjoaa tilaa ongelmille, joita ei ole vielä selvitetty.

Vaatimusanalyysin aikana mallinnetaan myös liiketoimintaprosesseja ja liike- esineitä, joita voidaan käyttää vaatimusten muotoilussa.

  • Business Object: Tunnistaa liikeobjektin, johon vaatimus liittyy.
  • Liiketoimintaprosessi: Tunnistaa liiketoimintaprosessin, johon vaatimus vaikuttaa .

Lisäksi toiset ja muut esineet ovat kehitysprosessin vaatimuksia suhteessa (engl. Requirements traceability).

  • Suhde (englanninkielinen jäljityslinkki): viittaa muihin vaatimuksiin. Esimerkiksi karkea vaatimus voidaan tarkentaa useiksi tarkemmiksi vaatimuksiksi tai vaatimukset ovat ristiriidassa keskenään.

Katso myös

Yksittäiset todisteet

  1. ↑ ISO / IEC 25010 Järjestelmät ja ohjelmistotuotanto - Järjestelmien ja ohjelmistojen laatuvaatimukset ja arviointi (SQuaRE) - Järjestelmien ja ohjelmistojen laatumallit LOPULLINEN LUONNOS. Käytetty 24. maaliskuuta 2014 (PDF; 4,0 Mt).
  2. ↑ Suzanne Robertson, James Robertson: Vaatimusprosessin hallinta . 2. painos. Addison-Wesley, Harlow 2006, ISBN 0-321-41949-9 , s. 9-10 .
  3. ↑ Chris Rupp: Vaatimusten suunnittelu ja hallinta: Harjoituksesta klassisesta ketterään , Carl Hanser Verlag GmbH Co KG, 2014, ISBN 9783446443136 , s. 268–269 [1]
  4. ↑ Järjestelmäkehitys yritystietotekniikassa : vdf Hochschulverlag AG, 2002, ISBN 9783728127624 , s. 139 [2]
  5. ↑ Martin Eigner, Florian Gerhardt, Torsten Gilz, Fabrice Mogo Nem: Tietotekniikka insinööreille , Springer-Verlag, 2012, ISBN 9783642248931 , s. 52 [3]
  6. ↑ Suzanne Robertson, James Robertson: Vaatimusprosessin hallinta . 2. painos. Addison-Wesley, Harlow 2006, ISBN 0-321-41949-9 , s. 171-201 .
  7. ↑ Chris Rupp, sofistiryhmä: Vaatimusten suunnittelu ja hallinta . Hanser, München 2001, ISBN 3-446-21664-2 , s. 264 .
  8. ↑ a b c d e f g h i j k l m n Bruno Schienmann: Jatkuva vaatimusten hallinta . Addison-Wesley, München 2002, ISBN 3-8273-1787-8 , s. 151 .
  9. B a b c d e f g h Suzanne Robertson, James Robertson: Vaatimusprosessin hallinta . S. 264 .
  10. ↑ Orlena Gothel, Jane Cleland-Huang, Jane Huffman Hayes, Andrea Zisman, Alexander Egyed: Jäljitettävyyden perusteet . Julkaisussa: Ohjelmistojen ja järjestelmien jäljitettävyys . Springer London, 2012, ISBN 978-1-4471-2238-8 , s. 3–22 , doi : 10.1007 / 978-1-4471-2239-5_1 ( springer.com [käytetty 19. joulukuuta 2016]).