Täydellisin vaatimustenhallinnan ja jäljitettävyyden opas

Vaatimusten on oltava laadukkaita, jotta projekti onnistuisi. Asettamalla standardeja ja ehtoja tiimit voivat arvioida edistymistään näiden tavoitteiden saavuttamisessa. Käytettävät mittarit vaihtelevat tehdyn työn mukaan. joitain yleisiä seurantavaatimuksia koskevia indikaattoreita ovat kuitenkin:

Testauksen kattavuus – Kuinka monta kunkin järjestelmän toimintoja on testattu?
Arvioinnin tarkkuus - Onko eritelmissä korkea oikeellisuusaste?
Toiminnan täydellisyys – Onko kaikki toiminnallisuusalueet määritelty riittävän yksityiskohtaisesti?
Hyväksymiskriteerien selkeys – Voivatko käyttäjien hyväksymiskriteerit tunnistaa helposti dokumentaatiosta?
Muutospyynnöt - Kuinka monta muutospyyntöä on jätetty eritelmien kirjoittamisen jälkeen?

Mittaamalla näitä laadullisia tekijöitä säännöllisesti voit tunnistaa, mihin tiimisi on keskitettävä ponnistelunsa ja parannettava projektiesi laatua.

Vaatimusten laadun mittaaminen

Miksi on tärkeää arvioida vaatimusten laatua?

Meidän on ensin selvitettävä, onko meillä vaatimusongelma ja kuinka suuri ongelma se on, jotta voimme laskea tarkasti, kuinka paljon vaivaa tarvitaan muuttamaan riittämättömät resurssit tyydyttäviksi.
Esimiehinä pyrimme varmistamaan, että tiimimme työskentelee tuloksellisesti vaatimusmäärittelyn laatimisen tai vaatimusanalyysin tekemisen aikana. Täyttävätkö he tavoitteensa?
Ottaen huomioon erilaiset skenaariot, loimme vaatimusmäärittelyillemme vertailuarvon kriteerien laatumittarin arvosta. Asetamme neljä arvoa vastaamaan kutakin tilannetta:
- Alkuperäisen romaanin luominen vaikeassa ympäristössä ei ole helppoa.
- Luoda innovatiivinen kerronta ilman paineita tai rajoituksia.
- Arkipäiväinen kehitys
- Muiden kuin kehitystarpeiden hankinta
Varmistaaksemme projektidemme korkean laadun luomme vertailuarvon järjestelmävaatimusten ja ohjelmistovaatimusten tarkasteluille.

Mitä tulee teknisiin mittareihin, vaatimusten laatumittari on yksi tehokkaimmista käytettävissä olevista työkaluista. Loppujen lopuksi historiallisesti tarkasteltuna jonkin muun kuin alun perin tarkoitetun kehittäminen on ollut yleinen ongelma insinööreille. Vaikka objektiivisen standardin käyttö ei takaa täydellisiä tuloksia joka kerta, se voi vähentää merkittävästi mahdollisia riskejä ja virheitä lopputuotteessa.

tuote Koko

Projektin vaatimusten lukumäärän ymmärtäminen on välttämätöntä. Tämä voidaan saavuttaa käyttötapausten, toiminnallisten vaatimusten, käyttäjätarinoiden, ominaisuuskuvausten, tapahtuma-vastaustaulukoiden tai analyysimallien avulla. Ryhmäsi valinta edustaa näitä vaatimuksia ei kuitenkaan millään tavalla vaikuta niiden ensisijaiseen tehtävään – järjestelmän käyttäytymisen toteuttamiseen tiettyjen olosuhteiden ja toiminnallisten tarpeiden perusteella.

Aloita vaatimusten arviointiprosessi laskemalla yksittäiset toiminnalliset vaatimukset, jotka on kohdistettu tuotteen julkaisuun tai kehitysiteraatioon. Jos eri yksilöt eivät saa laskeessaan samanlaisia tuloksia, on välttämätöntä ottaa huomioon muunlaiset väärinkäsitykset ja epäselvyydet, joita saattaa syntyä tulevaisuudessa. Sinun on oltava tietoinen julkaisun vaatimuksista, jotta voit seurata tarkasti tiimisi edistymistä. Ilman tätä tietoa sinulla ei ole mitään tapaa mitata, milloin olet valmis projektin! Kun pidät silmällä, kuinka paljon työtäsi on vielä jäljellä, varmistat, että kaikki ymmärtävät, mitä on tapahduttava ennen valmistumista.

Sen varmistamiseksi, että toiminnalliset vaatimukset ovat tarkka järjestelmän koon mitta, on tärkeää, että analyytikot luovat ne yhtenäisellä yksityiskohtaisuudella. Loistava tapa tehdä tämä on jakaa korkean tason vaatimukset pienempiin lapsikomponentteihin, joita voidaan testata erikseen. Toisin sanoen testaajien tulee suunnitella yksinkertaisia testejä, jotka osoittavat, onko jokainen vaatimus pantu täytäntöön oikein vai ei. Tämä varmistaa, että kaikki tehtävät vaativat yhtä paljon käyttöönottoa ja testausta niiden monimutkaisuudesta riippumatta. Sen varmistamiseksi, että kehittäjät ja testaajat voivat toteuttaa ja testata jokaisen vaatimuksen oikein, on tärkeää seurata, kuinka monta alatason vaatimuksia on. Muita vaihtoehtoisia mitoitusmenetelmiä ovat käyttötapauskohdat ja tarinakohdat, jotka kaikki mittaavat arvioitua vaivaa, joka tarvitaan erityisen määritellylle toiminnallisuudelle.

Vaikka toiminnalliset vaatimukset ovat välttämättömiä, ei-toiminnallisiakaan ei voida jättää huomiotta. Nämä erityisvaatimukset vaativat entistä enemmän ponnisteluja tehokkaaseen suunnitteluun ja toteuttamiseen. Tietyt toiminnot riippuvat luetelluista ei-toiminnallisista tarpeista, kuten turvallisuusnäkökohdista, jotka tulee esittää toiminnallisten ominaisuuksien arvioidussa koossa. Kaikki ei-toiminnalliset toiveet eivät kuitenkaan näy tässä – on tärkeää, että otat niiden vaikutuksen arvioosi huomioon! Harkitse seuraavia tilanteita:

Useiden reittien tarjoaminen tietyn ominaisuuden käyttämiseen parantaa käyttökokemusta; Tällainen sitoumus vaatii kuitenkin kehittäjiltä enemmän aikaa ja energiaa kuin jos vain yksi pääsytapa olisi käytettävissä.
Vaikka et ottaisikaan käyttöön uusia tuoteominaisuuksia, pakotetut suunnittelu- ja toteutusrajoitukset, kuten ulkoiset rajapinnat olemassa olevan käyttöympäristön mukauttamiseksi, voivat merkittävästi lisätä tarvittavan käyttöliittymätyön määrää.
Maksimaalisen suorituskyvyn varmistamiseksi voidaan tarvita huolellista algoritmi- ja tietokannan suunnittelutyötä nopeiden vastausten takaamiseksi.
Tiukkojen käytettävyys- ja luotettavuusvaatimusten täyttämiseksi on tarpeen rakentaa vikasieto- ja tietojen palautusmekanismeja, jotka voivat viedä aikaa. Lisäksi nämä vaatimukset voivat vaikuttaa valitsemaasi järjestelmäarkkitehtuuriin.

Seuraamalla vaatimusten lisääntymistä ajan myötä saat hyödyllisiä tietoja käytetystä kokomittarista riippumatta. Asiakkaani huomasi, että heidän projektinsa lisääntyivät yleensä noin kaksikymmentäviisi prosenttia ennen toimitusta. Lisäksi suurin osa heidän projekteistaan kesti vähintään kaksikymmentäviisi prosenttia odotettua pidempään! Tässä ei ole sattumaa – on selvää, että näiden kahden suuntauksen välillä on yhteys.

Vaatimukset Laatu

Käytä jonkin aikaa vaatimustesi laadun mittaamiseen tarkastamalla ne. Dokumentoi löytämäsi viat ja jaa ne eri luokkiin, kuten puuttuvat vaatimukset, virheelliset, tarpeettomat, epämääräisyys jne. Analysoi tämän jälkeen nämä vikatyypit ja niiden perimmäinen syy, jotta tulevat pyynnöt tehdään oikein alusta loppuun. Käytä näitä tietoja mahdollisuutena parantaa vaatimusprosessisi tehokkuutta! Jos esimerkiksi huomaat, että puuttuvat vaatimukset ovat yleensä toistuva ongelma, hakumenetelmiäsi on muutettava. On mahdollista, että yritysanalyytikot eivät kysy tarpeeksi tai oikeita kyselyitä, tai sinun on ehkä otettava mukaan entistä paremmin sopivia käyttäjien edustajia tarpeiden kehittämisprosessiin.

Jos tiimi tuntee olevansa kiireinen tutkiessaan kaikkia vaatimuksiaan koskevia asiakirjoja, tehokkaampi vaihtoehto on tarkastaa muutama sivu ja laskea sitten keskimääräinen virhetiheys – vikojen määrä spesifikaatiosivua kohden. Olettaen, että tämä näyte heijastaa tarkasti koko asiakirjaa (mikä voi olla melkoinen olettamus), sen kertominen tarkastamattomilla sivuilla voi antaa meille arvion siitä, kuinka monta piilotettua virhettä voi jäädä määrityksissämme. Kokemattomat tarkastajat eivät välttämättä pysty havaitsemaan kaikkia vikoja, joten käytä arvioitua huomaamattomien vikojen määrää minimiarviona. Tarkastusnäytteenoton avulla voit arvioida asiakirjan laatua ja päättää, onko taloudellisesti kannattavaa tarkastaa muun vaatimusmäärittely – mikä varmasti on kyllä!

Lisäksi tietuevaatimusvirheet, jotka havaitaan perustason määrittämisen jälkeen. Nämä ongelmat olisivat jääneet huomaamatta laadunvalvonnassa vaatimuksia kehitettäessä. Laske tiimisi onnistumisprosentti näiden virheiden löytämisessä tässä varhaisessa vaiheessa – se on paljon kustannustehokkaampaa kuin yrittää korjata ne, kun suunnittelu ja koodaus on jo saatu päätökseen!

Tarkastustiedoista voi saada kaksi erittäin arvokasta mittaria: tehokkuus ja vaikuttavuus. Tehokkuus ilmaisee havaittujen vikojen keskimääräisen määrän työtuntia kohden, kun taas tehokkuus ilmaisee, kuinka suuri osuus kaikista olemassa olevista puutteista havaittiin tarkastuksen avulla – mitta, joka antaa viitteitä siitä, kuinka onnistuneita tarkastukset (tai muut laadunvarmistuskäytännöt) ovat olleet. Tehokkuuden avulla voit arvioida vian havaitsemisen kustannukset tarkastuksen avulla. Voit punnita tätä kustannusta summaan, joka kuluu myöhemmin kehitysvaiheessa tai toimituksen jälkeen havaittujen vaatimusten puutteiden käsittelyyn, jolloin voit määrittää, onko vaatimusten laadun parantaminen taloudellisesti kannattavaa.

Vaatimusten tila

Pysyäksesi projektin kärjessä, seuraa jokaista vaatimusta sen elinkaaren ajan. Voit jopa määrittää attribuutin arvon näiden tietojen tallentamiseksi lisäturvaa ja tarkkuutta varten. Tämän tyyppinen tilanseuranta auttaa vähentämään ohjelmistoprojektien yleistä ongelmaa – väärää väitettä, että se on "yhdeksänkymmentä prosenttia valmis". Jokaisella vaatimuksella on oltava jokin seuraavista tiloista tietyn ajanjakson aikana:

Kannatti (joku tuki voimakkaasti)
Hyväksyntäprosessi onnistui ja jako on asetettu lähtötasolle.
Koodin huolellisen muotoilun, komentosarjan ja testauksen jälkeen otimme sen käyttöön.
Kun vaatimus oli läpäissyt ja läpäissyt testinsä, sen onnistunut integrointi tuotteeseen varmistettiin.
Tämä vaatimus täytetään myöhemmin.
Päätät poistaa sen etkä ota sitä käyttöön.
Hylätty (konseptille ei koskaan annettu vihreää valoa)

Edellä mainittujen tilavaihtoehtojen lisäksi muita tiloja voidaan harkita. Jotkut voivat valita "Tarkistettu" -tilan vahvistaakseen vaatimuksensa ennen niiden lisäämistä peruskokoonpanoihin. Vaihtoehtoisesti organisaatiot voivat käyttää "Toimitettu asiakkaalle" -toimintoa varmistaakseen, että ne ovat vapauttaneet vaatimuksen ehjänä ja oikein.

Jos tiedustelet kehittäjän edistymistä, hän saattaa vastata, että tälle projektille on 87 vaatimusta. 61 on jo vahvistettu ja 9 on paikoillaan, mutta niitä on vielä tarkistettava, ja 17 on vielä viimeistelemättä. On kuitenkin tärkeää huomata, että kaikki nämä pyynnöt eivät vastaa kokoa tai vaikutusta asiakastyytyväisyyteen. ne voivat vaatia myös eri määriä vaivaa. Projektipäällikkönä minulla ei olisi epäilystäkään siitä, että meillä oli tarkka käsitys osajärjestelmän koosta ja siitä, kuinka lähellä se oli valmistumista. Tämä on paljon tehokkaampaa kuin pelkkä sanominen "Olen noin yhdeksänkymmentä prosenttia valmis". Kokonaiskuvan edistymisestä voin vakuuttavasti sanoa, että "se näyttää hyvältä!"

Muuta pyyntöjä

Jotta vaatimusten hallinta onnistuu, organisaatiosi on huolehdittava jokaisesta vaatimuksen lisäyksestä, poistamisesta ja muuttamisesta. Näin voit seurata kaikkien muutospyyntöjen tilaa ja vaikutuksia. Voit myös käyttää näitä tietoja vastataksesi useisiin kyselyihin, kuten:

Kuinka monta muutospyyntöä on tehty määrätyn ajan kuluessa?
Kuinka moniin pyyntöihin on vastattu ja kuinka moni on edelleen ratkaisematta?
Mikä oli pyyntöjen hyväksymisaste, ja kuinka suuri prosenttiosuus niistä hylättiin?
Missä määrin tiimi käytti energiaa jokaisen valtuutetun muutoksen suorittamiseen?
Kuinka kauan pyynnöt ovat tyypillisesti avoinna?
Kuinka moneen kohteeseen (esim. vaatimuksiin tai esineisiin) kukin lähetetty muutospyyntö keskimäärin vaikuttaa?

Varmista, että seuraat kehitysprosessin aikana tehtyjä muutoksia sen jälkeen, kun olet asettanut kunkin julkaisun perustason. Muista, että yksi muutospyyntö voi vaikuttaa useisiin erilaisiin vaatimuksiin (käyttäjälähtöisiin, toiminnallisiin ja ei-toiminnallisiin). Arvioi, kuinka monta muutosta tietyn ajanjakson aikana on tehty jakamalla muutosten määrä tätä ajanjaksoa edeltäneiden vaatimusten kokonaismäärällä (kuten määrittäessäsi perustasoa).

Emme halua kokonaan poistaa vaatimusten epävakautta. Loppujen lopuksi niiden muuttamiselle on usein oikeutettu peruste. Samalla meidän on kuitenkin varmistettava, että projektimme kestää muutokset ja silti täyttää velvoitteensa. Lähemmäksi valmistumista aiheutuu lisäkustannuksia, kun muutoksia tehdään usein; Tämän vuoksi on vaikea määrittää, milloin julkaiset tuotteesi maailmalle! Kehityksen edetessä useimpien hankkeiden tulisi muuttua sietokykyisemmiksi muutoksille; Toisin sanoen muutoksen hyväksymisnopeuden tulisi asteittain laskea, kunnes se saavuttaa nollan, kun julkaisu on valmis. Iteratiivinen lähestymistapa antaa tiimeille useita mahdollisuuksia sisällyttää parannuksia myöhempiin iteraatioihin samalla kun pysyt raiteilla kunkin syklin aikajanalla.

Jos tiimisi on täynnä muutospyyntöjä, on todennäköistä, että hakuprosessi ei ollut kattava tai ideoita syntyy edelleen projektin edetessä. Sellaisenaan on tärkeää seurata, mistä nämä muutokset tulevat markkinoilta, käyttäjiltä, myyjiltä, johtoryhmiltä jne. Näiden tietojen seuraaminen auttaa sinua määrittämään, ketkä ja mitkä tarvitsevat huomiota minimoidaksesi huomiotta jäävät vaatimukset ja estääksesi väärinkäytökset.

Kun muutospyynnöt jäävät ratkaisematta pidemmän aikaa, se on selvä merkki siitä, että muutoksenhallintaprosessisi vaatii huomiota. Olen henkilökohtaisesti nähnyt yhden organisaation, jolla oli useita vuosia vanhoja ja edelleen vireillä olevia parannuspyyntöjä. Saadakseen projektipäällikön priorisoimaan energiansa tärkeimpiin ruuhkan asioihin, tämän tiimin tulee määrittää tietyt avoimet pyynnöt suunniteltuihin ylläpitojulkaisuihin ja muuntaa muut pitkäaikaiset lykätyt muutokset hylätyiksi. Näin he voivat helpommin käsitellä sitä, mikä on olennaista ja kiireellistä, ennen kuin ryhtyvät käsittelemään vähemmän kiireellisiä asioita.

Aika ja vaivaa

Optimaalisen suorituskyvyn varmistamiseksi suosittelemme, että kirjaat ajan, jonka tiimisi käyttää vaatimusten suunnittelutehtäviin. Tämä sisältää laatuvaatimusten laatimisen ja muutoksen hallinnan, edistymisen seuraamisen, jäljitettävyystietojen luomisen ja muut tähän prosessiin liittyvät toimet.

Ihmiset kysyvät minulta usein, kuinka paljon aikaa ja energiaa tulisi käyttää projektin tarpeisiin. Tämä vastaus riippuu suuresti koosta, tiimistä, sitä rakentavasta organisaatiosta ja tarkoituksesta. Tällaisten projektien kriittisiin tehtäviin sijoittamasi ponnistelujen seuraaminen voi auttaa sinua suunnittelemaan tulevia paremmin tarkkojen arvioiden avulla.

Jos tiimisi on aiemmin suorittanut projektin ja käyttänyt 10 % ajastaan vaatimuksiin, olet ehkä huomannut pohdittuasi, että näiden vaatimusten laatua voitaisiin parantaa huomattavasti. Jos edessä on toinen vastaava projekti, projektipäällikön olisi viisasta varmistaa, että perusteellisten eritelmien laatimiseen panostetaan enemmän – yli kymmenen prosenttia käytettävissä olevista kokonaisresursseista pitäisi riittää!

Kun keräät ja analysoit tietoja, vertaa projektin kehitystyötä tuotteen koon mittaan. Dokumentoidut vaatimukset antavat käsityksen sen kokonaiskoosta. Tarkemmin sanottuna voit vertailla ponnisteluja laskeaksesi testattavat yksittäiset spesifikaatiot, käyttötapaukset tai toimintapisteet – mikä tahansa on verrannollinen tuotteesi mittoihin. Viitaten tässä yhteydessä kuvaan 1 saat mittaussauvan kehitystiimisi kykyjen arvioimiseen, mikä auttaa edelleen ennustamaan julkaisun sisältöä ja määrittämään ne tarkasti! Keräämällä tuotteesi kokoon liittyviä tietoja ja huomioimalla siihen liittyvät toteutusponnistelut voit laatia tarkkoja arvioita valmistautuessasi vastaaviin tuleviin projekteihin.

Pelko saattaa viipyä monien mielissä; pelkäävät, että mittausohjelmiston kehittäminen vie arvokasta aikaa tärkeiltä tehtäviltä. Päinvastoin, tehokkaan ja kohdistetun metrijärjestelmän käyttöönotto ei vaadi liikaa vaivaa tai energiaa. Sinun tarvitsee vain rakentaa perusinfrastruktuuri tietojen keräämistä ja analysointia varten sekä kannustaa tiimisi jäseniä kirjaamaan joitain olennaisia tietoja työstään. Kun luot yritykseesi mittareihin perustuvan kulttuurin, on uskomatonta, mitä tällä menetelmällä voi oppia!

Yhteenveto

Vaatimusten tunnistaminen ja analysointi ovat olennaisia ohjelmistokehityksen osia. Ilman niitä projekti voi epäonnistua puuttuvien tai virheellisten spesifikaatioiden vuoksi, mikä johtaa kalliisiin uudelleenkäsittelyyn ja mahdollisesti epätyydyttäviin lopputuloksiin. Siksi on tärkeää varmistaa, että käytössäsi on tehokas prosessi vaatimusten keräämiseen ja tarkkuuden tarkistamiseen koko projektin aikajanalla. Kunnollisella hallinnoinnilla tiimit voivat saavuttaa menestystä luomalla yksityiskohtaisia vaatimuksia, jotka kuvaavat tarkasti kaikki halutut toiminnot ja varmistavat, ettei mitään jää huomiotta. Arvioimalla olemassa olevia prosesseja ja mittareita säännöllisesti kussakin hankkeessa, tiimit voivat paremmin ymmärtää, mikä heille toimii parhaiten, kun he hakevat käyttäjäpalautetta kehitysjaksojen aikana. Tämä auttaa pitämään hankkeet raiteilla ja edistämään laadukkaampia tuloksia.

Älä unohda jakaa tätä julkaisua!