Kuinka järjestää vaatimukset liiketoimintaanalyytikona

by: Charles Moore Charles Moore
Hours Päivitetty

⚡ Älykäs yhteenveto

Liiketoimintatarpeiden organisointi liiketoiminta-analyytikkona muuttaa sidosryhmien raakadatan jäsennellyksi, priorisoiduksi ja trackäyttökelpoinen asiakirja, jota kehittäjät, testaajat ja johtajat voivat kukin käyttää omassa haluamassaan muodossa menettämättä tarkoitukseaan.

  • 📚 Määritelmä: Liiketoimintavaatimus on muodollinen asiakirja, joka kuvaa sidosryhmien tarpeet projektille tai tuotteelle riittävän yksityiskohtaisesti, jotta niitä voidaan keskustella, analysoida ja validoida.
  • 📋 Kymmenen askeleen menetelmä: Luokittele, järjestä, listaa, tunnista, esitä, sisällysluettelo, työkalu, poista kohinaa, yhdistä prosessoitavaksi ja muotoile taulukoiden ja luettelomerkkien avulla.
  • 📈 Käytettävissä olevat muodot: Taulukot, laskentataulukot, työnkulkukaaviot, graafit, ER-mallit, prototyypit ja jäsennellyt lausepohjat lasketaan kaikki kelvollisiksi esityksiksi.
  • 🛠️ Työkalut, joihin BA:t yltävät: Jira Confluencen, Jama Connectin, DOORSin kanssa Modern Requirements varten Azure DevOps, Miro, Lucidchart, Balsamiq ja Figma.
  • 🎯 Yleisö ensin: Esitä sama vaatimus eri tavoin johtajille, kehittäjille ja loppukäyttäjille, jotta jokainen sidosryhmä voi toimia sen mukaisesti nopeasti.
  • ⚠️ Vältä ansoja: Mitä-sanan ja miten-sanan sekoittaminen, epämääräinen sanamuoto, puuttuva trachelppokäyttöisyys, ei priorisointia ja ohitusping kuittaus aiheuttaa suurimman osan BRD-uudelleentöistä.
Lue lisää

Organisointivaatimukset liiketoiminta-analyytikkona

Liiketoimintavaatimus on muodollinen asiakirja, joka kuvaa sidosryhmien tarpeita projektille tai tuotteelle. Liiketoimintavaatimusten esittämiselle ei ole yhtä ainoaa standardimuotoa, mutta jokaisen version tulisi kattaa tuote tai projekti riittävän yksityiskohtaisesti, jotta sitä voidaan keskustella, analysoida, dokumentoida ja validoida.

Liiketoiminnan vaatimus voidaan esittää jollakin seuraavista tavoista:

  • Taulukko tai laskentataulukko
  • Kaavio (työnkulku)
  • Kaavio
  • Malli (kokonaisuus-suhdekaavio)
  • Prototyyppi tai simulaatio
  • Jäsennelty lause tai tekstimalli

Liiketoiminnan vaatimuksen järjestäminen ja esittäminen

Alla on vaiheet vaatimusten kirjoittamiseen ja järjestämiseen Business Analyst.

Vaihe 1) Luokittele vaatimukset.

  • Sijoita jokainen vaatimus sille kuuluvaan kategoriaan.
  • Teknisten sidosryhmien tulisi nähdä tekninen vaatimusluokka ja muiden sidosryhmien tulisi nähdä liiketoiminta- tai yleinen vaatimusluokka.
  • Jokaisen organisaation tulisi päättää, mitkä kategoriat sopivat sen omiin standardeihin.
  • Luokittelu voi perustua myös vaatimustyyppiin – toiminnallinen vs. liiketoiminta – vaikka tämä jaottelu ei sovi kaikkiin projekteihin.

Vaihe 2) Järjestä vaatimukset.
Kerää ja järjestä vaatimukset loogiseen järjestykseen, jotta sidosryhmät voivat navigoida asiakirjassa helposti ja havaita puuttuvat kohdat.

Vaihe 3) Valmistele luettelo.
Laadi tarkistuslista vaatimuksista ryhmiteltynä niiden sidosryhmien mukaan, joiden on hyväksyttävä ne.

Esimerkiksi teknisen taustan omaava sidosryhmä välittää vain tuotteen teknisestä puolesta.

Vaihe 4) Käytä yksilöllisiä tunnisteita.
If tracvaatimusten yhdistäminen toisiinsa on vaikeaa, käytä yksilöllisiä tunnisteita trackäytettävyys helpompaa.

Vaihe 5) Esitä vaatimukset sidosryhmän haluamalla tavalla.
Saatat joutua esittämään saman vaatimuksen eri muodoissa eri sidosryhmille – yksi suosii graafista esitystapaa, kun taas toinen suosii jäsenneltyjä lauseita.

Vaihe 6) Valmistele sisällysluettelo.
Luo sisällysluettelo kaikille vaatimuksille. Se auttaa sidosryhmiä. track ja paikanna ne nopeasti.

Vaihe 7) Käytä Business Analysis -työkaluja.
Käyttää Liiketoiminnan analysointityökalut jotka auttavat esittämään ja luokittelemaan vaatimukset johdonmukaisesti eri julkaisuissa.

Vaihe 8) Järjestä vaatimusasiakirjat prosessikulun mukaan.
Poista dokumentista tarpeettomat vaatimukset ja järjestä jäljelle jääneet vaatimukset niiden tukeman prosessivirran mukaan.

Vaihe 9) Kartoita vaatimukset.
Yhdistä jokainen keräämäsi vaatimus tiettyyn prosessivaiheeseen, jotta tarkistajat voivat yhdistää vaatimuksen sen tukemaan työnkulkuun.

Vaihe 10) Käytä taulukko- ja luettelokohtia.
Käytä taulukoita esittääksesi monimutkaiset vaatimukset ja luettelomerkkejä korostaaksesi kunkin vaatimuksen keskeisiä näkökohtia.

Hyödyllisiä vinkkejä liiketoimintavaatimusasiakirjan kirjoittamiseen ja esittämiseen

Paremman esillepanon ja tracLiiketoimintavaatimusten kuningas, seuraavat vinkit ovat hyödyllisiä kaikille liiketoiminta-analyytikoille (BA).

  • Vaatimusten luokittelu on aikaa vievää, joten määrittele vakiojoukko luokkia, joita liiketoimintajohtajat, sidosryhmät, asiantuntijat ja tekniset tiimit voivat käyttää uudelleen eri projekteissa sen sijaan, että keksivät uusia joka kerta.
  • Valmistele jokainen vaatimus kohdeyleisönsä kontekstissa. Ymmärrä keskeiset toimijat, vaikuttajat ja päätöksentekijät (sidosryhmät, tekninen henkilöstö, kehittäjät jne.).
  • Määrittele yksi vaatimus kerrallaan. Jokaisen vaatimuksen tulee olla atomaarinen.
  • Vältä monitulkintaisuutta – älä käytä vaatimusmäärittelyssä epämääräisiä määritteitä, kuten ”jne.” tai ”noin”.
  • Älä viittaa vaatimukseen, jota ei ole vielä määritelty.
  • Poista dokumentista päällekkäiset ja ristiriitaiset lauseet.
  • Pilko monimutkaiset vaatimukset pienempiin, hallittaviin ja tarkistettaviin osiin.
  • Kuvata mitä järjestelmä tekee kyllä, ei miten se tekee sen – toteutus kuuluu suunnitteluvaiheeseen.

AIHEESEEN LIITTYVÄT ARTIKKELIT

Suosittuja tekniikoita liiketoimintavaatimusten visualisointiin

Tekstimuuri on nopein tapa menettää sidosryhmä. Liiketoiminta-analyytikot yhdistävät jokaisen tekstipohjaisen vaatimuksen visuaaliseen elementtiin, jotta tarkoitus on selvä yhdellä silmäyksellä. Seuraavat tekniikat esiintyvät BABOK-oppaassa ja useimmissa yritysten liiketoiminta-analyytikoiden käytännöissä.

  • Liiketoimintaprosessien malli ja merkintätapa (BPMN): Kaavioi kokonaisvaltaiset liiketoimintaprosessit, joissa on poolit, väylät, yhdyskäytävät ja tapahtumat. BPMN sopii erinomaisesti näyttämään kuka tekee mitä ja milloin.
  • Käyttötapauskaaviot ja Descriptionit: Tallennaa toimijoiden ja järjestelmien vuorovaikutukset ja kunkin toimijan odottamat tulokset. Hyvä ominaisuuspohjaisille ruuhkille.
  • Käyttäjätarinoita hyväksymiskriteereineen: Lyhyet ”Koska… haluan… jotta…” -lausekkeet yhdistettynä Given-When-Sitten-kriteereihin. Oletusarvoinen muoto ketterissä tiimeissä.
  • Lankamallit ja mallit: Matala- tai keskitason tarkkuusnäytöt, jotka on tuotettu Figma, Balsamiq tai Axure jotka tekevät käyttöliittymävaatimuksista konkreettisia ei-teknisille sidosryhmille.
  • Entiteettisuhdekaaviot (ERD): Näytä ratkaisun tallennettavat tietokokonaisuudet ja niiden väliset suhteet – tämä on kriittistä raportointi- ja integrointivaatimusten kannalta.
  • Tietovuokaaviot (DFD): Trace miten data liikkuu prosessien, varastojen ja ulkoisten toimijoiden läpi, erityisesti analytiikka- tai integraatioprojekteissa.

Sovita tekniikka kohdeyleisöön: johtajat reagoivat prosessikarttoihin ja matkakaavioihin, kehittäjät reagoivat ERD-raportteihin ja käyttäjätarinoihin ja loppukäyttäjät reagoivat rautalankamalleihin ja prototyyppeihin.

Yleisiä työkaluja liiketoimintavaatimusten asiakirjojen järjestämiseen

Kun vaatimusten määrä ylittää parin kymmenen, Word-dokumentin skaalautuminen lakkaa. Liiketoiminta-analyytikot siirtyvät tarkoitukseen rakennettuihin työkaluihin, jotka tukevat lähtötilanteiden määrittämistä, tarkastelua, tracsuorituskyky ja muutostenhallinta. Seuraavat ovat toimialalla yleisimmin käytettyjä.

  • Jira ja Confluence: Oletusarvoinen yhdistelmä ketterille tiimeille. Vaatimukset elävät eeppisinä tarinoina Jirassa, ja niitä tukevat Confluence-sivut, jotka sisältävät BRD-narratiivin ja kaaviot.
  • Jama Connect: Yritysalusta, joka keskittyy vaatimusten hallintaan, lähtötilanteisiin ja live-käyttöön tracsäännellyille toimialoille, kuten lääkinnällisille laitteille ja ilmailu- ja avaruusalalle.
  • IBM Engineering Requirements Johdon OVET: Pitkään käytössä ollut työkalu puolustus-, auto- ja turvallisuuskriittisissä järjestelmissä, joissa jokainen vaatimus on täytettävä trackyvykäs.
  • Modern Requirements varten Azure DevOps: ulottuu Azure DevOps, jossa on tarkistus, hyväksyntä, lähtötilanne ja Word-tyylinen BRD-vienti suoraan työkohteista.
  • Miro or Lucidchart: Valkotaulu- ja kaaviotyökaluja, joita käytetään BPMN:ien, ERD:iden, käyttäjäpolkujen ja työpajamuistiinpanojen laatimiseen, jotka myöhemmin syöttävät virallista BRD:tä.
  • Balsamiq ja Figma: Wireframe- ja prototyyppityökalut, jotka pitävät käyttöliittymävaatimukset visuaalisina tekstimuotoisten sijaan.

Valitse työkalupakki projektin koon ja auditointitarpeiden mukaan. Pienemmät projektit voivat alkaa Confluencella ja Jiralla, kun taas säännellyt ohjelmat tarvitsevat yleensä Jaman tai DOORSin täyttääkseen vaatimukset. tracsuorituskykytarkastukset.

Yleisiä virheitä liiketoimintavaatimusten esittämisessä

Jopa hyvin tutkittu vaatimus voidaan hylätä, jos se esitetään huonosti. Seuraavat virheet esiintyvät useimmissa BA:n jälkianalyysien yhteydessä, ja niitä on syytä varoa tarkistuksen aikana.

  • Mitä ja miten sekoitetaan: Luistaaping Toteutustietojen lisääminen vaatimusmäärittelyyn lukitsee suunnittelutiimin ratkaisuun ennen analyysin valmistumista.
  • Epäselvä sanamuoto: Sanat kuten ”nopea”, ”käyttäjäystävällinen” tai ”joustava” eivät ole testattavissa. Korvaa ne mitattavilla hyväksymiskriteereillä.
  • Yksi formaatti jokaiselle sidosryhmälle: Saman näkökulman esittäminen johtajille, kehittäjille ja loppukäyttäjille ei yleensä miellytä kumpaakaan. Räätälöi muoto yleisölle sopivaksi.
  • Puuttuva trackyky: Vaatimuksia, jotka eivät ole sidoksissa liiketoimintatavoitteisiin, suunnitteluelementteihin tai testitapauksiin, ei voida puolustaa muutospyynnön saapuessa.
  • Ei priorisointia: Satojen vaatimusten esittäminen ilman MoSCoW:ia, painotettua pisteytystä tai vastaavaa kehystä pakottaa sidosryhmät väittelemään laajuudesta arvon sijaan.
  • Ylikuormitetut asiakirjat: Kaikkien kaavioiden, lokien ja perustelujen ahtaminen yhteen 200-sivuiseen PDF-tiedostoon piilottaa tärkeät vaatimukset. Jaa BRD loogisiin osiin selkeän sisällysluettelon avulla.
  • hyppiäping uloskirjautuminen: BRD:n esittäminen ilman virallista hyväksyntävaihetta jättää oven avoimeksi laajemmalle laajentumiselle ja syyttelylle myöhemmässä vaiheessa toimitusta.

RevBRD-asiakirjan tarkastelu tätä listaa vasten ennen jokaista sidosryhmäkokousta paljastaa suurimman osan ongelmista, jotka vaativat uudelleentyöstöä myöhemmissä vaiheissa.

UKK

Tekoälytyökalut ryhmittelevät toisiinsa liittyviä vaatimuksia, merkitsevät päällekkäisyyksiä ja ristiriitoja, luovat hyväksymiskriteerien luonnoksia ja kääntävät sidosryhmähaastattelut jäsennellyiksi käyttäjätarinoiksi. Liiketoiminta-analyytikot validoivat edelleen jokaisen luodun lausunnon liiketoimintatavoitetta vasten ennen sen hyväksymistä.

Copilot ja GPT voivat laatia BRD-rungon, laajentaa käyttäjätarinoita ja luoda ensimmäiset hyväksymiskriteerit kokousmuistiinpanojen perusteella. RevTarkastajat varmistavat edelleen, että jokainen vaatimus on testattavissa, yksiselitteinen ja vastaa sidosryhmän tarvetta ennen dokumentin perustason määrittämistä.

BRD kuvaa liiketoiminnan tarpeita ja tavoitteita, FRD kuvaa ratkaisun toiminnallisen toiminnan ja SRS on kehittäjälle suunnattu spesifikaatio, joka kattaa toiminnalliset ja ei-toiminnalliset vaatimukset. Jokainen dokumentti on suunnattu eri yleisölle ja yksityiskohtaisuuden tasolle.

Yleisiä viitekehyksiä ovat MoSCoW (Must, Should, Could, Won't), painotettu pisteytys, Kano-analyysi, viivästyksen kustannukset ja arvo vs. työmäärä -matriisit. Sidosryhmät ja tuoteomistajat asettavat vaatimukset järjestykseen, jotta toimitustiimi työskentelee aina seuraavaksi arvokkaimman kohteen parissa.

RTM on dokumentti, joka linkittää jokaisen vaatimuksen sen alkuperään, suunnitteluelementtiin, koodikomponenttiin ja testitapaukseen. Se tukee sekä eteenpäin että taaksepäin suuntautuvaa trackäytettävyys, laajuuden suojaaminen muutospyyntöjen aikana ja näytön tarjoaminen auditointien aikana.

Ei ole olemassa yhtä ainoaa parasta työkalua. Ketterät tiimit käyttävät Jiraa ja Confluencea, säännellyt ohjelmat Jama Connectia tai IBM OVET ja Microsoft kaupat käyttävät Modern Requirements varten Azure DevOps. Valitse työkalu, joka vastaa tiimin kokoa, auditointitarpeita ja integrointivaatimuksia.

Ketterät tiimit esittävät vaatimukset eeppisinä suunnitelmina, käyttäjätarinoina ja hyväksymiskriteereinä tuotteen kehitysjonossa. BA tukee tuoteomistajaa viimeistelyssä, tarkentamisessa ja Definition of Ready -tarkasteluissa, jotta jokainen tarina on pieni, testattava ja itsenäinen ennen sprintin alkua.

Hyvin kirjoitettu vaatimus on atomaarinen, testattava trackäyttökelpoinen, yksiselitteinen ja priorisoitu. Se määrittelee, mitä järjestelmän on tehtävä, ei sitä, miten, ja sisältää mitattavat hyväksymiskriteerit, jotta kehittäjät ja testaajat voivat vahvistaa toimituksen ilman epäselvyyksiä.

Tiivistä tämä viesti seuraavasti: