Kuinka lyhyt kuvaus mukautetun hakemuksen kirjoittamatta teknistä eritelmää.

Kehitys lyhyt ei tarvitse aloittaa tietokanta kaavio. Sen täytyy selittää työtä, joka jonkun pitäisi pystyä saattamaan päätökseen ja tulos yrityksesi tarvitsee siitä.

Ensimmäisen yhteenvedon tavoitteena on tehdä projektista keskusteleva. Voit jättää tekniset valinnat avoimeksi samalla kun olet tarkka työstä, jota sovellus tukee.

Aloita käyttäjän kanssa ja tehtävä

.Rakenna portaali.Rakenna portaali.Näytä ohjelmistotyyppi. ..Antaa hyväksytyn asiakkaan tehdä palvelupyyntö ja nähdä sen etenemistä... kuvaa hyödyllistä ensimmäistä työnkulkua.

Nimeä käyttäjä, toimi ja tulos. Sitten tunnistaa kuka käsittelee prosessin toista puolta. Tässä esimerkissä henkilöstön jäsenen tulee tarkistaa pyyntö ja päivittää sen tila. Se tarkoittaa, että kirjelmässä on jo kaksi eri roolia ja yhteinen ennätys.

Vältä aloittamasta sovellus kaikille. Eri käyttäjät voivat tarvita erilaisia oikeuksia, näytöt ja tietoa. Päätä, mikä rooli on tärkeintä ensimmäisessä julkaisussa.

Selitä, mitä tänään tapahtuu.

Kuvaile nykyisiä vaiheita tavallisella kielellä. Ehkä asiakas sähköpostia tietoja, henkilöstön jäsen kopioi sen laskentataulukkoon ja toinen henkilö lähettää edistymispäivityksen. Tila, jossa sekaannusta tai toistuvaa vaivaa tapahtuu, olettamatta ohjelmisto ratkaisee kaikki ympäröivät ongelmat.

Tämänhetkinen muoto tai tietue voi olla hyödyllisempi esimerkki kuin kiillotettu esitys. Poista henkilökohtaiset tiedot ja luottamukselliset tiedot ennen niiden jakamista.

Kuvaile yksi täydellinen matka

Seuraa edustusta alusta loppuun. Mikä alkaa? Mitä tietoja tarvitaan? Kuka tekee seuraavan päätöksen? Mikä merkitsee sen täydellinen?

Yksi tai kaksi tärkeää poikkeusta. Pyyntö voi olla puutteellinen, arvioija voi hylätä sen tai käyttäjä voi joutua korjaamaan virheen. Nämä tapaukset auttavat erottamaan työsovelluksen ihanteellisesta polusta.

Sinun ei tarvitse keksiä jokaista harvinaista tapahtumaa tässä vaiheessa. Keskity poikkeuksiin, jotka estäisivät päätyönkulun hyödyllisyydestä.

Nimeä tiedot ja riippuvuudet

Listaa tärkeät tietueet: käyttäjät, pyynnöt, tuotteet, varaukset, tiedostot tai muut tiedot. Selitä mistä ne tulevat ja kuka on vastuussa niiden ylläpidosta.

Kotouttamista varten nimeä toinen palvelu ja toimita sen dokumentaatio silloin, kun se on käytettävissä. Yhteydenotto CRMiimme jättää suuret kysymykset avoimeksi. Hyödyllinen yksityiskohta on, mikä tietueen pitäisi liikkua, mihin suuntaan ja minkä jälkeen.

Tunnista, ovatko mallit, tuotesisältö, tilin käyttö tai liiketoiminnan säännöt jo saatavilla. Puuttuvat materiaalit eivät ole automaattisesti blokkereita, mutta ne tarvitsevat omistajan ja paikan suunnitelmassa.

Määrittele ensimmäinen hyödyllinen versio

Ensimmäinen portaali voisi tukea pyynnön luomista, sen tarkistamista ja statuksen näyttämistä. Viestit, edistynyt raportointi ja mobiilisovellus voisivat olla myöhempiä keskusteluja sen sijaan, että ne olisivat puhumattomia ensimmäisen rakennuksen vaatimuksista.

Tämä ei ole ohje rakentaa jotain keskeneräistä. Valitun työnkulun pitäisi toimia alusta loppuun. Rajana on täydellinen työnkulku, ei houkuttelevan näytön ja sen tarvitseman logiikan välillä.

Kirjoita hyväksymisesimerkki

Kokeile lausetta, jota joku voisi testata:

Hyväksytty asiakas voi esittää pyynnön, nähdä sen tilan allekirjoittamisen jälkeen ja tarkastella vain omia pyyntöjään. Valtuutettu toimihenkilö voi päivittää tilan, ja asiakas näkee muutoksen.

Tämä on havainnollistava vaatimus, ei kuvaus olemassa olevasta asiakashankkeesta. Se tekee odotetusta käyttäytymisestä paljon selkeämpää kuin moderni, turvallinen portaali.

Lisää käytännön rajoitteita

Ilmoita haluamasi ajoitus, olipa se sitten ensisijainen tai kiinteä ulkoinen päivämäärä, ja budjettialue, jos tiedossa. Nimeä henkilö, joka voi hyväksyä päätöksiä ja selittää, miten malleja tai palautetta toimitetaan.

Kuvaile julkaisu ja luovutus odotuksia liian. Kuka omistaa hosting ja tilit? Onko toisen kehittäjä tarvitsee saada koodi? Nämä kysymykset vaikuttavat toimitukseen, vaikka ne eivät näy näytöllä.

Lyhyesti voit käyttää

Haluamme rakentaa: sovellus tai työnkulku. Tärkeimmät käyttäjät ovat: Ihmisiä ja rooleja. Niiden on päätehtävä ja suoritettu tulos. Tänään tämä tapahtuu seuraavasti: Nykyinen prosessi. Ensimmäisessä versiossa on oltava: välttämätön täydellinen työnkulku. Sen on oltava yhteydessä: tunnetut järjestelmät ja asiakirjat. Meillä on jo malleja, sisältöä, tilejä tai esimerkkitietoja. Vieläkään ei ole päätetty: Kysymyksiä ratkaistavana. Ajoitus, budjetti ja päätöksentekijä: käytännön rajoitteet.

Käytä muutamia selkeitä lauseita kullekin osalle. Lyhyt on lähtökohta hankkeen määrittelyssä, ei testi sinun täytyy läpäistä ennen kuin puhut kehittäjän kanssa.

Keskustele mukautetun web-sovelluksen kanssa tai Lähetä muistiosi.