#etiketě Výrobku
software specifikace požadavků (SRS dokument) popisuje, jak software systém by měl být vyvinut. Jednoduše řečeno, SRS poskytuje všem zúčastněným plán pro tento projekt.
nabízí vysoce kvalitní definice funkčních a nefunkčních specifikací softwaru a může také zahrnovat případy použití, které ilustrují, jak by uživatel interagoval se systémem po dokončení.,
Poznámka: pomůžeme vám napsat specifikaci požadavků na Software. Vyžádejte si hovor s naším CTO vyplněním tohoto formuláře.
obsah
proč je dokument SRS důležitý?
Předpokládejme, že chcete vytvořit chatovou aplikaci se specifickým vzhledem a funkčností a chtěli byste, aby byla zaměřena konkrétně na podniky. Máte pocit, že můžete vystřihnout další funkce, které Komerční chatovací aplikace používají k oslovení veřejnosti a zaměřují se na funkce, které podniky potřebují. Ale vy nejste vývojář.,
takže je třeba zadávat vývoj aplikace. Ale také se musíte ujistit, že ten, koho najmete, aby změnil váš nápad na realitu, přesně ví, čeho se snažíte dosáhnout. Bez všech podrobností k dokončení aplikace se čas a náklady mohou rychle vymknout z rukou. Vývojáři mohou mít špatný obrat a musí přeformátovat kód, pokud konečný produkt neodpovídá obrázku, který jste měli v hlavě.
dokument SRS vás nutí položit myšlenku na papír, abyste pokryli všechny tyto podrobnosti. Tuto myšlenku musíte přeložit do jazyka, kterému vývojáři rozumí., Dokument SRS popisuje, co klient chce a co vývojáři poskytnou. Je to písemná dohoda o každém detailu aplikace.
mít jasný soubor požadavků zajišťuje, že vývojový tým vytvoří software, který splňuje potřeby klientů. SRS pomůže s odhadem nákladů na práci a pokrytí rozsahu projektu. To také dává kodéry představu o tech stack potřebují a pomáhá jim plánovat jejich práci, ale to není vše:
- Návrháři se projektu nahlédnout prostřednictvím SRS dokumenty tak mohou odpovídat návrhu use case.,
- testeři získají pokyny pro vytváření testovacích případů, které odpovídají potřebám podniku.
- koncoví uživatelé používají SRS k pochopení softwaru.
- poskytuje investorům přehled funkcí systému, aby mohli činit investiční rozhodnutí.
an SRS je důležité, protože se jedná o jediný zdroj informací a očekávání, který zabraňuje nedorozuměním mezi projektovými manažery, vývojáři, designéry a testery.
co obsahuje SRS?,
SRS by měl mít dostatek informací pro vývojáře k dokončení popsaného softwaru. Je to nejen vyloží popis software ve vývoji, ale také účelu bude sloužit: to, co software má dělat a jak to provést.,software nebo co to má dělat
Rozdíl Mezi Funkční a Non-funkční Požadavky
Funkční požadavky jsou cíle nového systému, který navrhujete., Popisují systém a jak bude fungovat, aby pomohl s úkoly uživatele. Definují, jak bude systém reagovat na vstup uživatele, a mají podrobnosti o výpočtech, zadávání dat a obchodních procesech. Funkční požadavky můžete považovat za podrobný popis funkcí aplikace a potřeb uživatele. Bez splnění funkčních požadavků nebude systém fungovat.
zatímco funkční požadavky specifikují, co systém dělá, nefunkční požadavky popisují, jak to systém udělá. Nefunkční požadavky nemají vliv na funkčnost aplikace., I bez splnění nefunkčních požadavků bude systém provádět požadované úkoly.
nefunkční požadavky jsou také důležité, protože definují obecné charakteristiky, které ovlivňují uživatelskou zkušenost. Místo toho, aby se zaměřili na požadavky uživatelů, zaměřují se na očekávání uživatelů a pokrývají témata jako výkon, bezpečnost, spolehlivost, dostupnost a použitelnost.,
Jak Napsat Software Požadavek Specifikace Dokumentu
To je nejlepší, aby uspořádat tento proces můžete použít k psát SRS dokumentu tím, že začíná s kostry a obecné informace o softwaru, který vyvíjíte, a dokončovací přidáním detailů zhmotnit vaše návrhy. Zde je šest kroků zapojených do vytváření dokumentu SRS:
získejte dokument specifikace požadavků na Software
pomohli jsme společnostem 200 + budovat své softwarové produkty. Najměte si našeho obchodního analytika s 6 lety odborných znalostí, abyste pro vás napsali SRS.,
Request SRS
vytvořte obrys
prvním krokem v procesu je vytvoření obrysu pro vaše SRS. Můžete si to vytvořit sami nebo použít existující šablonu SRS jako výchozí bod. Zde je základní příklad SRS osnovy:
Stáhněte si ebook
- Úvod
- Účel
- cílová skupina
- Zamýšlené Použití
- Rozsah
- Definice
- Celkový Popis
- Uživatel Potřebuje
- Předpoklady a Závislosti
- Funkce systému a Požadavky
- Funkční Požadavky
- Externí Rozhraní Požadavky
- Funkce Systému
- Non-funkční Požadavky
Definovat Účel
Jakmile budete mít přehled, musíte zapracovat., Začněte definováním účelu produktu při zavádění vašich SRS. Zde popíšete zamýšlené publikum a jak bude produkt používat. Zde je návod, jak by měla struktura účel:
- Definovat produkt působnosti
- Popsat hodnotu, kterou přinese
- Ukázat, kdo bude používat software
- Podrobně, jak to pomůže s zamýšlených uživatelů, práci
Přehled
Po definování výrobku účel, shrnout, jak to bude fungovat., Zde uvedete obecný popis funkcí softwaru a toho, jak vyhovují potřebám uživatele.
budete také popisovat předpoklady, které děláte o funkčnosti produktu a cokoli, na čem závisí v současném technologickém ekosystému.
popište funkční a nefunkční požadavky
Nyní, když jste napsali obecné informace, je čas získat konkrétnější. Dokončení přehledu před prací na funkčních a nefunkčních požadavcích vám poskytne odkaz, abyste se ujistili, že splňujete základní potřeby uživatele při vyplňování podrobností.,
Tento podrobný popis požadavků systému je nejdůležitější součástí dokumentu SRS. Popište funkční požadavky dostatečně podrobně, aby se vývojáři mohli dostat do práce a nefunkčních požadavků, jako jsou bezpečnostní specifikace a výkon.
zde je místo, kde přidáte případy použití, abyste živě popsali, jak bude uživatel komunikovat s vaším systémem. Je to místo, kde jsou cíle vašeho projektu podrobně popsány a budou měřit, jak projekt postupuje během vývoje.,
Přidat Doplňující Údaje
posledním krokem při vytváření návrhu svých SRS dokumentu je přidání nějaké podrobnosti, které by mohly pomoci vývojářům dokončit práci ve formě přílohy, slovníčky pojmů a odkazy.
získejte schválení
jakmile do SRS přidáte dostatek podrobností k popisu toho, co má systém dělat, je čas nechat zúčastněné strany dokument schválit.
budete s největší pravděpodobností muset předložit prezentaci lidem zapojeným do vývojového procesu., Mohou požádat o změny a před konečným schválením budete muset aktualizovat dokument SRS na základě zpětné vazby od zúčastněných stran.
to je dobré znamení. To znamená, že vývojáři i zainteresované strany dělají dokument přesnější, takže projekt je méně rád jít mimo trať.
jak psát případy použití softwaru v SRS
případ použití popisuje, jak bude uživatel interagovat se systémem. Bude popisovat produkt z pohledu koncového uživatele v jednoduchém formátu příběhu. Psaní případů použití vás nutí přemýšlet o tom, co uživatelé budou dělat se softwarem a jak bude reagovat., Jedná se o reálnou vizualizaci funkčních požadavků.
zde jsou kroky, které můžete provést, abyste napsali případ použití:
- popište koncové uživatele vašeho produktu.
- zaměřte se na jednoho z těchto uživatelů.
- rozdělte interakce tohoto uživatele na případy použití. Každá interakce je případ použití.
- popište posloupnost událostí pro každý případ použití.
- napište podrobný popis akcí uživatele a jak by měl systém reagovat.
- rozbalte každý případ použití pomocí alternativních uživatelských akcí a systémových odpovědí.
- opakujte 1-6 pro každý typ koncového uživatele.,
Jaké jsou charakteristiky skvělý SRS?
existují specifické vlastnosti, které by měl mít každý SRS. Přezkoumáním tohoto seznamu a jeho porovnáním s vaším SRS můžete zajistit, že to bude užitečný dokument pro všechny zúčastněné strany.
explicitní
dokument SRS by měl být snadno pochopitelný. Nic by nemělo být vágní, takže mezi zúčastněnými stranami nedochází k nedorozuměním.,
měřitelné
Požadavky v dokumentu SRS musí být měřitelné, takže hotový výrobek lze validovat a ověřovat podle specifikací.
Kompletní
SRS dokument by měl mít dostatek informací pro váš vývojový tým na dokončení produktu a pro testery k ověření, že produkt splňuje potřeby uživatele bez chyby.
životaschopné
Požadavky by měly odpovídat realitě současného prostředí, včetně rozpočtu, časové osy a technologie. Neměly by záviset na nadcházejících technologických průlomech.,
Flexibilní
protože se věci mohou v pracovním prostředí změnit, měl by být váš dokument SRS dostatečně flexibilní, aby umožnil aktualizace. Nepřidávejte nadbytečné informace do více sekcí, které musí být aktualizovány s každou změnou.
ověřitelné
každý z vývojového týmu by měl mít přístup k dokumentu, aby jej mohl odkazovat tak často, jak je to nutné. Požadavky musí být přesné, aby členové týmu nemuseli žádat o další podrobnosti. Všechny by měly být k dispozici v dokumentu SRS.,
konzistentní
Požadavky by se měly vzájemně hodit. Jedna část dokumentu požadavků by neměla být v rozporu s jiným. Dokument by měl být formátován důsledně a používat stejnou terminologii po celou dobu.
žádné omezení implementace
dokument SRS by měl být dostatečně podrobný, aby dokončil práci, ale neměl by být příliš specifický, protože by to mohlo omezit vývoj. Hodně vývoje závisí na službách třetích stran, které vývojáři nemají žádnou kontrolu.,
přesné
cíle v dokumentu požadavků by měly být přesné, aby nedošlo k záměně. Vyhněte se následujícím:
- mezery: „aplikace by se měla načíst za 3 sekundy, pokud to lze provést.“
- nejednoznačnost: „produkt MVP by měl být uvolněn co nejrychleji.“
- subjektivita: „uživatelské rozhraní by mělo být uživatelsky přívětivé.“
- superlativy: „to by měla být nejlepší aplikace ve své třídě.“
- srovnávací: „Tato aplikace by měla být lepší než Slack.,“
Softwarové Požadavky Specifikace (SRS) Příklad
Zde je zdobené dolů příklad SRS dokumentu pro podnikovou chatu aplikace s názvem eChat:
Úvod
detaily dokumentu plán projektu pro rozvoj „eChat.“
je určen pro vývojáře, designéry a testery pracující na „eChat“ i pro investory do projektů., Tento plán bude obsahovat shrnutí:
- jak bude tento systém fungovat
- rozsah projektu z vývojového hlediska
- technologie používané k vývoji projektu, a
- metriky používá k určení pokroku projektu
- Celkový Popis
Firmy potřebují prostředků dálkové komunikace, zvlášť teď, že více lidí pracuje z domova. Problém je v tom, že většina společností nakonec používá více aplikací k dosažení tohoto cíle: jeden pro textový chat, jeden pro videochat a jeden pro konference a schůzky., „eChat“ vyřeší tento problém kombinací těchto funkcí v jedné aplikaci.
Stáhněte si whitepaper
Zákazníci
zákazníci budou firmě společnosti. Nebude cílit na širokou veřejnost.
funkce
- uživatelé by se měli moci zaregistrovat u podnikových účtů LDAP.,
- uživatelé by měli být schopni vytvářet ad hoc chat skupiny obsahující sady uživatelů a posílat soukromé zprávy jednotlivým uživatelům.
- uživatelé by měli mít možnost mít textové chaty, které mohou proniknout do vláken.
- aplikace by měla být schopna zvládnout Skupinový videochat až 100 uživatelů najednou.
Platforma
aplikace budou vyvíjeny v React Native umožnit vytvoření web-based aplikace, iOS mobilní aplikace, Android mobilní aplikace.
tyto aplikace se připojí k rozhraní REST API vytvořenému pomocí.,NET Core pro ukládání a načítání dat z databáze MySQL.
autentizace bude probíhat prostřednictvím stávajících instalací LDAP.
Rozvoj Odpovědnosti
vývojáři na „eChat“ tým bude zodpovědný za psaní kódu pro aplikace, vývoj databází a správu verzí.,
Uživatel Třídy a Vlastnosti
Tam bude třída uživatelé tzv admin, který bude mít oprávnění pro přístup ke všem funkčnost aplikace, včetně:
- Vytvoření kanálů, kde více uživatelů může komunikovat
- Takže tyto programy veřejné, aby celou společnost nebo soukromá pro skupinu lidí,
- Odstranění těchto kanálů
- Archivace těchto kanálů
Standardní uživatelé budou mít přístup k všechny funkce aplikace, s výjimkou těch, které jsou uvedeny výše.,
Vlastnosti
Funkční Požadavky
- Uživatelé by měli být schopni vytvářet ad hoc skupiny chatu zahrnuje skupiny uživatelů a posílat soukromé zprávy ostatním uživatelům.
- uživatelé by měli mít možnost mít textové chaty, které mohou proniknout do vláken.
- chaty by měly být archivovány neomezeně dlouho, aby uživatelé mohli odkazovat na minulé chaty.
- uživatelé by měli mít možnost nahrát soubory do chatů pro referenci.
- požadavky na externí rozhraní
uživatelská rozhraní
- Front-end software: React nativní
- Back-end software: .,s operačními systémy prostřednictvím jejich výchozí prohlížeč
- iPhone
- Android
- Non-Funkční Požadavky
Výkonnostní Požadavky
- aplikace by měla načíst a být použitelná do 3 sekund
- aplikace by měla aktualizace rozhraní na interakci během 2 sekund
- Databáze by měla být normalizovány, aby se zabránilo redundantní data a zlepšit výkon
- databáze by měla být rozdělena, aby se zabránilo výpadkům
Bezpečnostní Požadavky
- Databáze by měly používat sharding být nadbytečné, aby se zabránilo ztrátě dat.,
- zálohy databází by měly být prováděny každou hodinu a uchovávány po dobu jednoho týdne.
bezpečnostní požadavky
- všechny klíče používané pro REST API by měly být bezpečně uloženy.
- k databázím by se mělo připojit pouze rozhraní REST API.
- Databáze by měly být za firewallem.
Software Atributy Kvality
- Dostupnost: Protože tato aplikace je zásadní pro obchodní komunikaci, budeme mít cíl o čtyři devítky(99.99%) dostupnost.,
- správnost: aplikace by nikdy neměla dovolit nikomu číst zprávy nebo diskuse, které nejsou určeny pro tuto osobu.
- udržovatelnost: aplikace by měla používat nepřetržitou integraci, aby funkce a opravy chyb mohly být nasazeny rychle bez prostojů.
- použitelnost: rozhraní by se mělo snadno naučit bez tutoriálu a umožnit uživatelům dosáhnout svých cílů bez chyb.
shrnutí
dokument SRS je nezbytnou součástí dokončení projektu vývoje softwaru., Je to plán, který dává směr všem zúčastněným na projektu, takže konečný produkt splňuje potřeby uživatele.
Bez kompletní SRS dokumentu na místě před zahájením projektu, to bude těžké říct, kdy bude projekt dokončen a mohla odbočovat rozvoje do vytváření nezamýšlených funkcí. Dokument SRS vám dává možnost přesně odhadnout projekt a efektivně přiřadit úkoly.
vytvoření dokumentu SRS může být časově náročný, pečlivý proces., Naštěstí tým společnosti Relevant pomohl více než 200 společnostem vytvářet dokumenty SRS a spouštět nové produkty. Jsme připraveni pomoci s dalším softwarovým projektem, stačí nám napsat řádek.