30.5.2009 02:11 | nic | poslední úprava: 3.1.2019 00:40

Cupiditate sit voluptatibus architecto minus voluptatem quia et in. Facere repellendus natus ullam sunt eius non. Tempore inventore et nihil alias. Possimus sequi voluptates repellat odio quia suscipit dolores. Et nihil nihil dolore nemo harum qui quidem excepturi. Sit ut ipsa eum.

       

Komentáře

[dandyg]

Zjednodušeně: Dokument specifikace požadavků slouží pro sepsání požadavků od uživatelů, klienta, legislativních předpisů, norem atd. Je to takový soupis všeho, co se od systému požaduje a na čem má být systém schopný běžet. Je to důležité třeba pro zadavatele jako první směrodatný dokument, podle kterého bude vývojář pracovat.

HW rozhraní u CMS nejspíš nebude žádné. Klávesnice, monitor, myš se pro nastavení předpokládá imho vždy, takže bych to neřešil.

[Fluttershy, yay!]

Díky za reakci.

Zjednodušeně: Dokument specifikace požadavků slouží pro...

To jsem tak nějak ještě pochopil.

HW rozhraní u CMS nejspíš nebude žádné. Klávesnice, monitor, myš se pro nastavení předpokládá imho vždy, takže bych to neřešil.

Takže vynechat? Nebo napsat, že požadavky v tomto ohledu nejsou žádné?

[skajrajdr]

Do specifikace pozadavku napriklad patri i odhadovany pocet uzivatelu toho systemu, jeho licencovani, na jakem hardware budes provozovat serverovou cast, jaka ma byt prumerna reakcni doba GUI atd. V tvem pripade urcite nejake hardwarove pozadavky mas, potrebujes napr. PC s pristupem na net, zrejme nejaky server atd.

Problematiku sberu a vyhodnoceni pozadavku se snazi resit ruzne metodiky vyvoje software. Doporucuji juknout na OpenUP, na webu je jeji kompletni popis. Bacha, je pomerne detailni a resi veci co ty potrebovat nejspise nebudes. Ale najdes tam priklad jak maji jednotlive dokumenty vypadat Work Products -> Requirements -> System Wide Requirements. Ke stazeni je i sablona pro OpenOffice.

[Fluttershy, yay!]

Díky. Začínám mít konkrétní představu o tom, co tam všechno má být.

Nyní už by se jen hodil nějaký příklad toho dokumentu v češtině... nevím, jaký styl vyjadřování mám používat.

[skajrajdr]

V anglictine se typicky pouziva veticka: The system shall ... Myslim ze cestina je na tyhle veci mnohem bohatsi, a vyjadreni ze by neco "melo" se da popsat mnohem vice moznostmi. Ale abych byl uprimny, v cestine jsem nikdy tenhle dokument nepsal, takze je to jen muj dojem.

[Tomáš Honzák]

V životě jsem requirementy v češtině nepsal ani nečetl, ale byl bych setsakra opatrný na "mělo" (a vůbec cokoliv, co smrdí podmiňovacím způsobem). Jednoznačnost je jednou z klíčovou vlastností dobrého requirementu. Srovnej například "Při zadání prázdného vstupu by systém neměl spadnout" a "Při zadání prázdného vstupu systém nesmí spadnout".

[skajrajdr]

S tim nesouhlasim, jednoznacnost popisu toho, co by se melo stat, nema nic spolecneho s podminovacim zpusobem. K presne specifikaci dale preci neslouzi pozadavky ale jiny typ dokumentace.

[default]

HW rozhraní u CMS nejspíš nebude žádné. Klávesnice, monitor, myš se pro nastavení předpokládá imho vždy, takže bych to neřešil.

Možná by tam mohla spadat integrace. Rozhraní pro hromadný import, rozhraní pro reporty…

[dandyg]

Tady sem kdyžtak našel nějaký info:

www.kiv.zcu.cz/studies/publikace/RationalUnifiedProcess/process/artifact/ar_srs.htm

www.processimpact.com/goodies.shtml#reqs

[Fluttershy, yay!]

Díky. Jenže já momentálně vím, co to má být, ale nikterak zvláště netuším, jak to má vypadat konkrétně. Píšu tam takové příšerné okecavací kecy, že to pomalu není možné...

[tomm]

U DSP je nutne dodrzet 1 hlavni zasadu. Musi mu rozumet zakaznik, ktery o PC nema paru. Nesmi se tam vykytovat nic odborneho, z UML je povolen pouze Use Case diagram, kteremu je jeste zakaznik schopen porozumet. Zadne informace o prostredcich realizace, tedy jazyk, platforma, atd. Vsechny tyto informace jsou obsazene az v nasledujicich krocich, tedy funkcionalini analyza, ktera uz obsahuje technicke detaily, ale jeste nejde upne do hloubky, na to je az nasledujici analyza architektury, ktera uz vyuziva vybranych konkretnich technologii. U malych projektu je samozrejme mozne tyto 2 analyzy slozit do jedne, staci pouzit jen zdravy selsky rozum

Nejsou soucasti zadani i treba analyza rizik, definice kvality, atd.?

[Fluttershy, yay!]

V těch několika šablonách, které jsem viděl, bylo zdůrazněno, že se má jít do podrobností, co se implementace (HW, platforma, programovací jazyk,...) týče. Tak nevím.

[tomm]

Zrovna ta sablona od Lukiho, na kterou odkazujes, nic takoveho neobsahuje Zadne technicke detaily, zakaznik jim stejne nerozumi a tudiz nevi, co odsouhlasuje a v budoucnu ti to otriska o hlavu.