Ugrás a fő tartalomra

Alkalmazási útmutató

Hogyan kell egy egyedi alkalmazás rövid írása nélkül a műszaki leírás.

Készítsen egy hasznos alkalmazási rövid a felhasználók, munkafolyamatok, mintafeljegyzések, függések és elfogadási példák, anélkül, hogy a műszaki leírás.

A fejlesztési jelentés nem kell kezdeni egy adatbázis diagram. Meg kell magyarázni a munkát, hogy valaki képes legyen befejezni, és az eredmény az üzleti igényeit belőle.

Az első jelentés célja, hogy a projekt megvitatható legyen. Nyitva hagyhatja a technikai döntéseket, miközben pontos az alkalmazás által támogatott munkáról.

Kezdés egy felhasználóval és egy feladattal

"Építs egy portált" nevez egy típusú szoftver. "Hagyja, hogy a jóváhagyott ügyfél nyújtson be egy szolgáltatás kérelmet, és látni a haladást" leírja a hasznos első munkafolyamat.

Nevezze meg a felhasználó, a cselekvés és az eredmény. Ezután azonosítsa, hogy ki kezeli a másik oldalon a folyamat. Ebben a példában, az alkalmazott kell, hogy vizsgálja felül a kérelmet, és frissítse a státuszt. Ez azt jelenti, hogy a rövid már két különböző szerepet és egy közös rekord.

Kerülje az "egy alkalmazás mindenkinek". Különböző felhasználók szüksége lehet különböző engedélyek, képernyők és információk. Döntse el, hogy melyik szerep a legfontosabb az első kiadás.

Magyarázd el, mi történik ma!

Írja le a jelenlegi lépéseket a szokásos nyelven. Talán egy ügyfél e-mail információk, az alkalmazott lemásolja a táblázatba, és egy másik személy küld előrehaladást frissíteni. Adja meg, ahol zavar vagy ismételt erőfeszítés történik, feltételezve, hogy a szoftver megoldja minden környező problémát.

A szerkesztett példa a jelenlegi forma vagy rekord lehet hasznosabb, mint egy csiszolt prezentáció. Távolítsa el a személyes információkat és bizalmas részleteket, mielőtt megosztja.

Egy teljes út leírása

Kövesse a reprezentatív rekordot az elejétől a végéig. Mi kezdődik? Milyen információ szükséges? Ki hozza meg a következő döntést? Mi jelöli azt, hogy teljes?

Egy vagy két fontos kivétel. A kérés lehet hiányos, a bíráló lehet, hogy elutasítja azt, vagy a felhasználó lehet, hogy ki kell javítani a hibát. Ezek az esetek segítenek megkülönböztetni a munkakérelmet egy demonstráció az ideális út.

Nem kell feltalálni minden ritka esemény ebben a szakaszban. Koncentráljon azokra a kivételekre, amelyek megállítanák a fő munkafolyamat hasznos.

Az adatok és függések megnevezése

Sorolja fel a fontos feljegyzéseket: felhasználók, kérések, termékek, foglalások, fájlok vagy más információk. Magyarázza meg, honnan származnak, és ki felelős azok fenntartásáért.

Egy integráció, nevezze meg a másik szolgáltatás, és adja meg a dokumentációt, ha rendelkezésre áll. "Csatlakozás a CRM" hagyja fontos kérdéseket nyitva. A hasznos részlet az, hogy melyik rekord kell mozgatni, melyik irányba és melyik esemény után.

Azonosítsa, hogy már rendelkezésre állnak-e formatervezési minták, terméktartalom, számlahozzáférés vagy üzleti szabályok. A hiányzó anyagok nem automatikusan blokkolók, de szükségük van egy tulajdonosra és egy helyre a tervben.

Az első hasznos verzió meghatározása

Elkülöníteni a magszállítás a későbbi ötletek. Az első portál segíthet létrehozni egy kérést, felülvizsgálni, és mutatja a státusz. Üzenetküldés, fejlett jelentés és egy mobil alkalmazás lehet később megbeszéléseket, ahelyett, hogy kimondatlan követelmények az első épület.

Ez nem egy utasítás, hogy építsünk valami hiányosságot. A választott munkafolyamatnak kezdettől a végéig működnie kell. A határ a teljes munkafolyamatok között van, nem egy vonzó képernyő és a még mindig szükséges logika között.

Példa az elfogadásra

Próbáljon ki egy mondatot, amit valaki kipróbálhat:

A jóváhagyott vásárló benyújthatja a kérelmet, megtekintheti a státusát, miután aláírta, és csak a saját kéréseit nézheti meg. A felhatalmazott alkalmazott frissítheti a státuszt, és az ügyfél látja ezt a változást.

Ez egy illusztratív követelmény, nem pedig egy meglévő ügyfél projekt leírása. Sokkal világosabbá teszi a várt viselkedést, mint a "modern, biztonságos portál". Az esetleges hatály finomíthatja a jogosultságokat és az élvonalbeli eseteket.

Gyakorlati megszorítások hozzáadása

Adja meg a kívánt időzítést, legyen az preferencia vagy egy rögzített külső időpont, és a költségvetési tartomány, ha ismert. Nevezze meg azt a személyt, aki jóváhagyhatja a döntéseket, és magyarázza el, hogyan kell a terveket vagy visszajelzéseket átadni.

Írja le a kiadás és átadási elvárásokat is. Ki fogja birtokolni a hosting és a számlák? Egy másik fejlesztő kell, hogy megkapja a kódot? Ezek a kérdések hatással vannak a szállítás még akkor is, ha nem jelenik meg a képernyőn.

Egy rövidítés, amit használhatsz.

Meg akarjuk építeni: az alkalmazás vagy a munkafolyamat. A fő felhasználók a következők: Az emberek és a szerepek. A következőknek kell lenniük: a fő feladat és a befejezett eredmény. Ma ez történik: a jelenlegi folyamat. Az első verziónak a következőket kell tartalmaznia: az alapvető teljes munkafolyamat. A következőkhöz kell kapcsolódnia: az ismert rendszerek és dokumentáció. Már van: tervezés, tartalom, számlák vagy példás adatok. Még nem döntöttük el: A megoldandó kérdések. Időzítés, költségvetés és döntéshozó: a gyakorlati korlátokat.

Használj néhány tiszta mondatot minden részhez. A jelentés a projekt meghatározásának kiindulópontja, nem pedig egy olyan teszt, amelyen át kell menned, mielőtt egy fejlesztővel beszélnél.

Egyéni webes alkalmazás megvitatása vagy Küldje el az összefoglalóját..