miksi liiketoiminnan ja toiminnallisten vaatimusten merkitys projektin onnistumiselle on

tuotekehitysprosessissa yksi olennainen osa minkä tahansa projektin onnistumista on vaatimusten saaminen kohdalleen. Ja monet hankkeet epäonnistuvat, koska sidosryhmät eivät ymmärrä eroa liiketoiminnan vaatimusten ja toiminnallisten vaatimusten välillä.

hankkeen lopullinen menestys ja epäonnistuminen riippuu vaatimusten laadusta. Vaikka se on harvoin todettu niin yksinkertaisesti, useimmat ohjelmistoprojektit epäonnistuvat, koska vähemmän korostetaan vaatimusten hallintaa.

takia syyskuussa 1999 NASA menetti 125 miljoonan dollarin arvoisen Mars Climate Orbiter-planeettansa, kun se yritti päästä kiertoradalle, vain 100 kilometriä liian lähelle Marsia. Tehtävä epäonnistui huonon vaatimuksenhallinnan vuoksi: aiemmin vaiheessa ei keskusteltu siitä, tarvitaanko ”navigointiohjelmistoon” metrisiä yksiköitä vai keisarillisia yksiköitä.

tulos: Yhteensopimattomat TEKNISET TIEDOT; asennonohjausjärjestelmä määriteltiin käyttäen keisarillisia yksiköitä, mutta sen navigointiohjelmistossa käytettiin metrisiä yksiköitä.

näin ollen vaatimusten saaminen oikein ja niiden hyödyntäminen mahdollisimman laajasti on ratkaisevan tärkeää projektin onnistumiselle.

ohjelmistotuotekehityksessä sanan ”vaatimukset” merkitys ja merkitys kasvaa ketterien ohjelmistokehitysmenetelmien suosion kasvaessa. Jo yksi ketterässä manifestissa mainituista kohdista selittää metodologian sellaiseksi, joka arvostaa:

”Working software yli kattava dokumentaatio”

vaatimusten saaminen oikein on tärkeää, työskenteletpä sitten ketterässä tai Vesiputousmetodologiassa.

liiketoiminta vs toiminnalliset vaatimukset-määritelmä ja sen tyypit

ennen kuin syvennymme liiketoiminnan vaatimuksiin vs toiminnalliset vaatimukset tarkastellaan määritelmää ja tyyppejä.

International Institute of Business Analysis-instituutin mukaan vaatimus on:

• edellytys tai kyky, jota sidosryhmä tarvitsee ratkaistakseen ongelman tai saavuttaakseen tavoitteen.
• ehto tai valmius, joka järjestelmän tai järjestelmän osan on täytettävä tai joka sillä on oltava sopimuksen, standardin, spesifikaation tai muiden muodollisesti määrättyjen asiakirjojen täyttämiseksi.
• dokumentoitu esitys 1 kohdassa tarkoitetusta tilasta tai kyvystä tai (2)

Based on the problem domain and the methodology that A Business Analyst (Ba) works, the different requirements, joista tärkeimmät ovat: business requirements and functional requirements.

tässä blogissa tarkastelemme eroa liiketoiminnan vaatimusten ja toiminnallisten vaatimusten välillä. On välttämätöntä ymmärtää ero niin, että tarjoamme liiketoiminnan ihanteellinen ratkaisu, joka todella hoitaa ongelman.

mitkä ovat liiketoiminnan vaatimukset

miksi asiakas tarvitsee sovelluksen?

tämä tieto saattaa kuulostaa monesta turhalta, koska asiakas on valmis maksamaan sovelluksen rakentamisesta. Miksi sinun pitäisi tietää syyt?

No, jos olet intohimoisesti rakentamassa laadukkaita tuotteita ja tarjoamassa saumattomia kokemuksia asiakkaillesi, sinun pitäisi välittää ”whyistä” yhtä paljon kuin ”whatsista” ja ” howeista.”

ja kun alat keskittyä projektin ”miksi” – osaan, se tarkoittaa, että huolehdit liiketoiminnan vaatimuksista.

Liiketoimintavaatimukset ohjelmistokehityksen elinkaari käsittelee korkean tason vaatimuksia tai haluaa organisaation, joka mahdollistaa liiketoiminnan saavuttaa tavoitteensa, visio, ja tavoitteet.

niissä kuvataan yleensä, mitä järjestelmän tai ratkaisun pitäisi tehdä. Ne antavat laajuuden liiketoiminnan tarve tai ongelma, joka olisi käsiteltävä tietyn hankkeen tai tehtävän.

Business Requirements Example

Parcelkosk on yksi asiakkaistamme, joka otti meihin yhteyttä saadakseen verkkosovelluksen, joka on suunniteltu ja kehitetty tarjoamaan asiakkaille parempia pakettipalveluja. Kun he lähestyivät meitä, aloitimme keskustelun tärkeällä parametrilla: analysoimalla liiketoiminnan tarpeita.

mikä mahtaa olla liiketoimintavaatimus tälle pakettitoimituksen verkkosovelluspalvelulle?

saatat keksiä tärkeän parametrin, kuten turvallisuuden. Vaikka turvallisuus on elintärkeä tekijä, se ei ole liiketoiminnan vaatimus. Parcelkioskin kaltaista palvelua ei rakenneta ilman turvallisuutta, vaan palvelun luominen vain turvallisuuden takaamiseksi—ei ole päämäärä.

miten on erilaisten kuriiripalvelujen ja asiakkaiden yhdistämisen laita?

tämä on liiketoiminnallisena vaatimuksena parempi kuin turvallisuus, koska se kuvaa, mitä palvelu tekee. Onko se kuitenkin syy siihen, että verkkopalvelu on saatu rakennettua, vai onko se todella palvelun funktio?

Tässä muutamia mahdollisia syitä (liiketoimintavaatimukset) rakentaa ParcelKiosk:

• tarjoa älykkäämpi ratkaisu pakettien mittaamiseen, valintaan ja lähettämiseen
• tarjoavat valmiudet seurata ja hallita niiden toimitus-ja noutopalveluja
• oikea-aikaiset toimitukset ja asiakaspalaute

huomaatko eron erilaisten kuriiripalvelujen ja asiakkaiden tai tietoturvan yhdistämisen ja todellisten liiketoimintavaatimusten välillä?

seuraavat seikat voidaan todeta tässä w. r. t liiketoiminnan vaatimukset:

• liiketoiminnan vaatimukset kirjoitetaan aina asiakkaan näkökulmasta.
• ne ovat laajoja korkean tason järjestelmävaatimuksia, mutta silti yksityiskohtalähtöisiä.
• ne eivät ole organisaation tavoitteita, vaan auttavat organisaatiota saavuttamaan tavoitteensa. Näiden liiketoimintavaatimusten täyttämisellä organisaatio saavuttaa laajat tavoitteensa.

nyt on aivan selvää, että liiketoiminnan vaatimukset selittävät projektin ”miksi” – osan: ”miksi” tietty projekti on rakennettava, ts. mitä hyötyä organisaatio pyrkii saavuttamaan toteuttamalla tietyn hankkeen.

Business Requirements Document (BRD)

a Business Requirements Document kuvaa korkean tason liiketoiminnan tarpeita. BRD: n ensisijainen kohdeyleisö on asiakas ja käyttäjät. Liiketoiminnan vaatimukset on dokumentoitu BRD: ssä. Hyvin kirjoitettu business requirements-asiakirja auttaa saavuttamaan halutun tavoitteen rakentaa onnistunut tuote säädetyssä määräajassa.

sillä on seuraavat alkuaineet:

• hankkeen visio
• hankkeen tavoitteet
• hankkeen tausta tai tausta
• hankkeen laajuus
• sidosryhmien tunnistaminen
• yksityiskohtaiset Liiketoimintavaatimukset
• ratkaisun Laajuus
• hankkeen rajoitukset: Aikataulu, projektin kustannukset ja käytettävissä olevat resurssit

Business Requirements Document Example – Why Chrysler PT Cruiser was Tagged ’Hero to Zero’

Chrysler Group was not focused on BRD and was ahead with the production of their PT Cruiser, which research to the organization. Katsotaanpa katsomaan, miten niiden liiketoiminnan vaatimukset asiakirja epäonnistui:

• sidosryhmien tunnistaminen: Chrysler Group tunnisti useimmat sidosryhmät melko hyvin. He olivat veneessä myyjien ja PT Cruiserin tuotantoryhmän kanssa. Kaksi tärkeää sidosryhmää, joita he eivät kuitenkaan huomanneet, olivat ajoneuvon ostava loppuasiakas ja risteilijän myyvät jälleenmyyjät.
• projektin rajoitteet: Chrysler teki hyvää työtä, kun se tuli huipputason sidosryhmien toimittaa ja valvoa rakentaa. Kuitenkin, mitä he kaipasivat oli kyseenalaistaa aikajana tuotannon, vastaamalla asiakkaiden kyselyihin tai jälleenmyyjien kuten hinta, malli saatavuus, ja kysyntä.

jos Chryslerin BRD sisälsi kaikki sidosryhmien vaatimukset, ennakoimattomat viiveet tuotteen toimituksessa (tavoite toimittaa autot jälleenmyyntiin vuoteen 2001 mennessä) olisi voitu korjata hyvissä ajoin ennen tuotantoa ja loppukäyttäjien tarpeet olisivat olleet perusteltuja.

Tips for Writing a Business Requirements Document Template (BRD)

nyt kun sinulla on perustiedot siitä, mitä BRD: n pitäisi saavuttaa, voit seurata alla mainittuja vinkkejä varmistaaksesi, että kirjoitat erinomaisen business requirements-dokumentin.

• practice strong requirements elicitation
• Use plain language without passive voice and jargon
• Research past projects
• Validate the documentation
• Integrate visuals

What are Functional Requirements

Functional Requirements, as the name vihjaa, describe the functionalities of software tai tuote. Nämä ovat toimintoja, jotka järjestelmän on suoritettava täyttääkseen liiketoiminnan vaatimukset.

niihin sisältyy teknisiä yksityiskohtia, laskelmia, tietojen manipulointia ja käsittelyä sekä muita erityisiä toimintoja, jotka luonnehtivat sitä, mitä puitteilla pitäisi saavuttaa.

jos sinulla ei ole selkeitä toiminnallisia vaatimuksia projektin teknisyyden ymmärtämiseksi, et voi projektin aikana vastata, ovatko kehitys/suunnittelu/testausryhmien päätökset oikeita.

”ei kirjoittaa spec on suurin yksittäinen tarpeeton riski otat ohjelmistoprojektin.”~ Joel Spolsky

jos toiminnallinen yksityiskohta on suunnattu väärin liiketoiminnan tavoitteisiin, se voi johtaa projektin epäonnistumiseen.

toiminnalliset vaatimukset esimerkki

yksi FMCG: n suurista toimijoista lähestyi Net Solutions-ratkaisuja mobiilisovellusten kehittämisprojektissa, joka voisi parantaa heidän toimitusketjunsa tehokkuutta.

tämä FMCG-jättiläinen aloitti vuonna 2001 hankkeen, jonka tavoitteena oli voimaannuttaa maaseudun naisia tarjoamalla heille mahdollisuuksia myydä tuotteita ja ansaita toimeentulo.

asiakas halusi projektitiimimme uudistavan olemassa olevan mobiilisovelluksensa siten, että se automatisoisi heidän toimitusketjunsa ja tilausprosessinsa tuomalla maaseudun naiset ja jakelijat samalle digitaaliselle alustalle.

niillä pyrittiin parantamaan adoptioastetta, mahdollistamaan yrittäjät digitaalisesti ja ratkaisemaan nykyisen asiakasmatkan kitka (kaikki nämä ovat liiketoiminnan vaatimuksia).

kun on kyse toiminnallisista vaatimuksista, aloimme keskustella asiakkaan kanssa tarvittavista sovelluksen ominaisuuksista, jotka olivat:

• integrointi kolmannen osapuolen toimittajiin
• reaaliaikaiset varastopäivitykset
• tilaussijoitus

asiakas oletti, että nämä ominaisuudet riittäisivät ratkaisemaan nykyisen asiakasketjun kitkan ja siten parantamaan käyttöönottoastetta.

keskustellessamme asiakkaan kanssa toiminnallisista vaatimuksista totesimme kuitenkin, että jos emme tunnista nykyisen asiakkaan matkan kitkaa ja mittaa uuden sovelluksen käyttäjien digitaalista lukutaitoa, sovelluksen kehittäminen olisi turhaa.

Net Solutionsin toimittama ratkaisu

sovelsimme Design Thinking-lähestymistapaa ja teimme etnografista tutkimusta arvioidaksemme yrittäjien digitaalista valmiutta ja ymmärtääksemme nykyisen sovelluksen käyttäjien matkan aukkoja.

vietimme päivän kaikkien sidosryhmien kanssa selvittääksemme tarkemmin heidän ongelmiaan.

Design Thinking-lähestymistavan avulla selvitimme, mitä ominaisuuksia uudessa sovelluksessa pitäisi olla. Lisäksi tämä lähestymistapa sai asiakkaamme ymmärtämään, että paras tapa edetä projektinhallinnassa on toteuttaa se vaiheittain.

tulos:

suunnitteluajattelumenetelmämme etnografinen tutkimus ja matkakartoitus auttoivat meitä rakentamaan uuden sovelluksen, jonka ominaisuudet ovat suunnitelleet ja validoineet sidosryhmät, jotka tulevat lopulta käyttämään sitä – tehden siitä yhden merkittävistä toiminnallisista vaatimuksista.

tässä voidaan todeta seuraavat seikat W.r.t toiminnalliset vaatimukset:

• toiminnalliset vaatimukset kirjoitetaan aina järjestelmän ja sidosryhmien näkökulmasta.
• toiminnallisten vaatimusten määrittely on paljon yksityiskohtaisempaa.
• toiminnallisten vaatimusten täyttämisen kautta kehitetään tehokas ratkaisu, joka vastaa asiakkaan liiketoiminnan tarpeita ja tavoitteita.

toiminnalliset vaatimukset selittävät siis projektin ”miten” – osan eli ohjelmistovaatimukset ja miten ratkaisu pystyy vastaamaan organisaation tarpeisiin.

toiminnalliset vaatimukset asiakirja

toiminnalliset vaatimukset asiakirja hahmotellaan toiminnot, joita tarvitaan liiketoiminnan tarpeiden täyttämiseksi. Nämä toiminnot dokumentoidaan toiminnallisia vaatimuksia koskevassa asiakirjassa (Functional Requirements Document, FRD) tai toiminnallisia vaatimuksia koskevassa asiakirjassa (Functional Requirements Specifications, FRS).

hyvin kirjoitettu FRD kuvaa kunkin toiminnon jokaisen prosessivirran ja yhdistää riippuvuudet toisiinsa.

FRD sisältää seuraavat elementit:

• hankkeen tarkoitus
• hankkeen laajuus
• yksityiskohtaiset toiminnalliset vaatimukset
• oletukset/rajoitteet
• toiminnallisten vaatimusten esittäminen tietoarkkitehtuurin avulla

vinkkejä funktionaalisten vaatimusten asiakirjamallin (FRD) kirjoittamiseen

asiakirjan luominen, joka tekniset toiminnot, joita tarvitaan ohjelmiston/tuotteen onnistuneeseen toimitukseen, ovat aivan kuin kirjoittaisi viestin kaikille mukana oleville tiimin jäsenille teknisistä tehtävistä, jotka haluat heidän suorittavan.

seuraavat vinkit auttavat sinua kirjoittamaan tehokkaan toiminnallisia vaatimuksia koskevan asiakirjan:

• Tuplatarkista faktasi
• käytä yksinkertaista kieltä
• Lisää kuvia tai kaavioita
• huomioi aikajänteet

liiketoiminnan vaatimukset vs toiminnalliset vaatimukset: dokumentin kirjoittamisen keskeiset haasteet

on suuri haaste kirjoittaa ”hyvä” tai ”pätevä” liiketoiminta ja toiminnalliset vaatimukset. Yleisimmät haasteet, joita kohdataan rakennettaessa näitä vaatimuksia asiakirjoja ovat:

• vaatimuksesta puutteellinen ymmärrys, ei pyydetty selvitystä.
• vaatimuksen virheellinen tulkinta; henkilökohtaisten suodattimien käyttäminen tahallisuutta muuttavaan tietoon.
• kirjoittaminen toteutuksesta (the how) vaatimusten (the what) sijaan.
• Täytäntöönpanopäätöksiä olisi lykättävä niin myöhäiseen ajankohtaan kuin mahdollista.
• käyttäen virheellistä lauserakennetta.
• vaatimusten laadun arvioinnin merkitys ohjelmistotuotekehityksessä.

mitkä ovat ei-toiminnalliset vaatimukset?

ei-toiminnalliset vaatimukset määrittelevät ja määrittelevät järjestelmän toiminnan. Se ei kuitenkaan vaikuta järjestelmän toimivuuteen kuten nimestä voi päätellä. Näin ollen järjestelmä voi jatkaa toimintaansa, vaikka sen ei-toiminnalliset vaatimukset eivät täyty. Ei-toiminnalliset vaatimukset ovat olennaisia niiden käytettävyyden vuoksi ja koska ne auttavat määrittämään käyttökokemukseen vaikuttavia tekijöitä.

toiminnalliset ja ei-toiminnalliset vaatimukset erottaa toisistaan se, että siinä missä edellinen päättää tuotteen ominaisuuksista ja käyttäjien vaatimuksista, jälkimmäinen keskittyy tuotteen ominaisuuksiin ja käyttäjien odotuksiin.

Business Requirements vs Functional Requirements – Conclusion

edellä esitetyn vertailun perusteella on selvää, että vaatimukset ovat jokaisen yrityksen selkäranka. Sekä liiketoiminnalliset että toiminnalliset vaatimukset muodostavat tehokkaan liiketoiminta-analyysin perustan. Liiketoiminnan vaatimukset selittävät projektin” miksi ”ja” mitä ”ja toiminnalliset vaatimukset selittävät projektin” miten”.

(kehitettyjen) toiminnallisten vaatimusten määräaikaisarviointi ja vertailu liiketoiminnan vaatimusten kanssa takaavat hankkeen kokonaismenestyksen. Tässä loppulausunto, joka menee pitkälle auttaa Sinua selvästi erottaa liiketoiminnan vaatimukset toiminnalliset vaatimukset-lähtökohtana liiketoimintaa analyysi on ymmärtää liiketoiminnan vaatimukset (mitä ja miksi) asiakkaan ja muuttaa ne toiminnalliset vaatimukset (miten).