Požadavky na software

Požadavky na software jsou popisem vlastností a funkcí cílového systému. Požadavky vyjadřují očekávání uživatelů od softwarového produktu. Požadavky mohou být zřejmé nebo skryté, známé nebo neznámé, očekávané nebo neočekávané z pohledu klienta.

Inženýrství požadavků

Proces shromažďování požadavků na software od klienta, jejich analýza a dokumentace se nazývá inženýrství požadavků.

Cílem inženýrství požadavků je vytvořit a udržovat propracovaný a popisný dokument „Specifikace požadavků na systém“.

Proces inženýrství požadavků

Jedná se o čtyřstupňový proces, který zahrnuje –

• Studii proveditelnosti
• Sběr požadavků
• Specifikaci softwarových požadavků
• Ověření softwarových požadavků

Podívejme se stručně na tento proces –

Studie proveditelnosti

Když klient osloví organizaci, aby nechala vyvinout požadovaný produkt, přijde s hrubou představou o tom, jaké všechny funkce musí software vykonávat a které všechny funkce se od softwaru očekávají.

Na základě těchto informací provedou analytici podrobnou studii o tom, zda je možné požadovaný systém a jeho funkce vyvinout.

Tato studie proveditelnosti je zaměřena na cíl organizace. Tato studie analyzuje, zda lze softwarový produkt prakticky zhmotnit z hlediska implementace, přínosu projektu pro organizaci, nákladových omezení a podle hodnot a cílů organizace. Zkoumá technické aspekty projektu a produktu, jako je použitelnost, udržovatelnost, produktivita a schopnost integrace.

Výstupem této fáze by měla být zpráva o studii proveditelnosti, která by měla obsahovat adekvátní komentáře a doporučení pro vedení, zda projekt realizovat, či nikoli.

Sběr požadavků

Pokud je zpráva o studii proveditelnosti pozitivní k realizaci projektu, začíná další fáze sběrem požadavků od uživatelů. Analytici a inženýři komunikují se zákazníkem a koncovými uživateli, aby se dozvěděli jejich představy o tom, co by měl software poskytovat a jaké funkce by měl software obsahovat.

Specifikace požadavků na software

SRS je dokument vytvořený systémovým analytikem po shromáždění požadavků od různých zúčastněných stran.

SRS definuje, jak bude zamýšlený software spolupracovat s hardwarem, externí rozhraní, rychlost provozu, dobu odezvy systému, přenositelnost softwaru na různé platformy, udržovatelnost, rychlost obnovy po pádu, bezpečnost, kvalitu, omezení atd.

Požadavky získané od klienta se zapisují v přirozeném jazyce. Povinností systémového analytika je zdokumentovat požadavky v technickém jazyce tak, aby byly srozumitelné a užitečné pro tým vyvíjející software.

SRS by měl přijít s následujícími funkcemi:

• Požadavky uživatele jsou vyjádřeny v přirozeném jazyce.
• Technické požadavky jsou vyjádřeny ve strukturovaném jazyce, který se používá uvnitř organizace.
• Popis návrhu by měl být napsán v pseudokódu.
• Format of Forms and GUI screen prints.
• Conditional and mathematical notations for DFDs etc.

Software Requirement Validation

After requirement specifications are developed, the requirements mentioned in this document are validated. User might ask for illegal, impractical solution or experts may interpret the requirements incorrectly. This results in huge increase in cost if not nipped in the bud. Requirements can be checked against following conditions –

• If they can be practically implemented
• If they are valid and as per functionality and domain of software
• If there are any ambiguities
• If they are complete
• If they can be demonstrated

Requirement Elicitation Process

Requirement elicitation process can be depicted using the folloiwng diagram:

• Sběr požadavků – Vývojáři diskutují se zákazníkem a koncovými uživateli a znají jejich očekávání od softwaru.
• Uspořádání požadavků – Vývojáři stanoví priority a seřadí požadavky podle důležitosti, naléhavosti a výhodnosti.

• Projednání & diskuse – Pokud jsou požadavky nejednoznačné nebo jsou v požadavcích různých zainteresovaných stran nějaké rozpory, pokud jsou, pak se o nich jedná a diskutuje se zainteresovanými stranami. Požadavky pak mohou být prioritizovány a přiměřeně kompromisní.

  Požadavky pocházejí od různých zúčastněných stran. Aby se nejednoznačnost a konflikty odstranily, diskutuje se o nich kvůli jasnosti a správnosti. Nereálné požadavky jsou rozumně kompromitovány.

• Dokumentace – Všechny formální & neformální, funkční a nefunkční požadavky jsou zdokumentovány a zpřístupněny pro zpracování v další fázi.

Techniky zjišťování požadavků

Zjišťování požadavků je proces zjišťování požadavků na zamýšlený softwarový systém pomocí komunikace se zákazníkem, koncovými uživateli, uživateli systému a dalšími osobami, které mají na vývoji softwarového systému zájem.

Existují různé způsoby zjišťování požadavků

Rozhovory

Rozhovory jsou silným prostředkem pro sběr požadavků. Organizace může provádět několik typů rozhovorů, např:

• Strukturované (uzavřené) rozhovory, kde je každá jednotlivá informace, kterou je třeba shromáždit, předem rozhodnuta, pevně se drží vzoru a věci diskuse.
• Nestrukturované (otevřené) rozhovory, kde informace, které je třeba shromáždit, nejsou předem rozhodnuty, jsou pružnější a méně zaujaté.
• Ústní rozhovory
• Písemné rozhovory
• Rozhovory „jeden na jednoho“, které probíhají mezi dvěma osobami naproti sobě
• Skupinové rozhovory, které probíhají mezi skupinami účastníků. Pomáhají odhalit případné chybějící požadavky, protože se jich účastní mnoho lidí.

Průzkumy

Organizace může provádět průzkumy mezi různými zúčastněnými stranami dotazováním na jejich očekávání a požadavky od připravovaného systému.

Dotazníky

Všem zúčastněným stranám se předá dokument s předem definovanou sadou objektivních otázek a příslušnými možnostmi odpovědí, které se shromáždí a sestaví.

Nedostatkem této techniky je, že pokud v dotazníku není uvedena možnost pro nějaký problém, může být tento problém ponechán bez povšimnutí.

Analýza úkolů

Tým inženýrů a vývojářů může analyzovat operace, pro které je nový systém potřebný. Pokud klient již má nějaký software pro provádění určité operace, je prostudován a jsou shromážděny požadavky na navrhovaný systém.

Analýza domény

Každý software spadá do nějaké kategorie domén. Při analýze obecných a specifických požadavků mohou být velkým pomocníkem odborníci na danou doménu.

Brainstorming

Probíhá neformální debata mezi různými zúčastněnými stranami a všechny jejich vstupy jsou zaznamenány pro další analýzu požadavků.

Prototypování

Prototypování je vytvoření uživatelského rozhraní bez přidání detailních funkcí, aby uživatel mohl interpretovat vlastnosti zamýšleného softwarového produktu. Pomáhá získat lepší představu o požadavcích. Pokud u klienta není nainstalován žádný software, který by mohl vývojář použít, a klient si není vědom svých vlastních požadavků, vytvoří vývojář prototyp na základě původně uvedených požadavků. Prototyp je předveden klientovi a je zaznamenána zpětná vazba. Zpětná vazba od klienta slouží jako vstup pro shromažďování požadavků.

Pozorování

Tým odborníků navštíví organizaci nebo pracoviště klienta. Pozorují skutečné fungování stávajících instalovaných systémů. Pozorují pracovní postupy u klienta a způsob řešení problémů s prováděním. The team itself draws some conclusions which aid to form requirements expected from the software.

Software Requirements Characteristics

Gathering software requirements is the foundation of the entire software development project. Hence they must be clear, correct and well-defined.

A complete Software Requirement Specifications must be:

• Clear
• Correct
• Consistent
• Coherent
• Comprehensible
• Modifiable
• Verifiable
• Prioritized
• Unambiguous
• Traceable
• Credible source

Software Requirements

We should try to understand what sort of requirements may arise in the requirement elicitation phase and what kinds of requirements are expected from the software system.

Obecně bychom měli požadavky na software rozdělit do dvou kategorií:

Funkční požadavky

Do této kategorie spadají požadavky, které se týkají funkčního aspektu softwaru.

Definují funkce a funkčnost v rámci softwarového systému a z něj.

Příklady –

• Možnost vyhledávání daná uživateli pro vyhledávání z různých faktur.
• Uživatel by měl mít možnost odeslat vedení libovolnou zprávu.
• Uživatele lze rozdělit do skupin a skupinám lze přidělit samostatná práva.
• Měly by být v souladu s obchodními pravidly a administrativními funkcemi.
• Software je vyvíjen se zachováním kompatibility směrem dolů.

Nefunkční požadavky

Do této kategorie patří požadavky, které nesouvisejí s funkční stránkou softwaru. Jsou to implicitní nebo očekávané vlastnosti softwaru, které uživatelé předpokládají.

Mezi nefunkční požadavky patří.

• Security
• Logging
• Storage
• Configuration
• Performance
• Cost
• Interoperability
• Flexibility
• Disaster recovery
• Accessibility

Requirements are categorized logically as

• Must Have : Software cannot be said operational without them.
• Should have : Enhancing the functionality of software.
• Could have : Software can still properly function with these requirements.
• Wish list : These requirements do not map to any objectives of software.

While developing software, ‚Must have‘ must be implemented, ‚Should have‘ is a matter of debate with stakeholders and negation, whereas ‚could have‘ and ‚wish list‘ can be kept for software updates.

User Interface requirements

UI is an important part of any software or hardware or hybrid system. A software is widely accepted if it is –

• easy to operate
• quick in response
• effectively handling operational errors
• providing simple yet consistent user interface

User acceptance majorly depends upon how user can use the software. UI is the only way for users to perceive the system. A well performing software system must also be equipped with attractive, clear, consistent and responsive user interface. Otherwise the functionalities of software system can not be used in convenient way. A system is said be good if it provides means to use it efficiently. User interface requirements are briefly mentioned below –

• Content presentation
• Easy Navigation
• Simple interface
• Responsive
• Consistent UI elements
• Feedback mechanism
• Default settings
• Purposeful layout
• Strategical use of color and texture.
• Poskytnutí informací nápovědy
• Přístup zaměřený na uživatele
• Nastavení zobrazení na základě skupin.

Systémový analytik softwaru

Systémový analytik v IT organizaci je osoba, která analyzuje požadavky navrhovaného systému a zajišťuje, aby byly požadavky správně koncipovány a zdokumentovány &. Role analytika začíná ve fázi softwarové analýzy SDLC. Úkolem analytika je zajistit, aby vyvíjený software splňoval požadavky klienta.

Systémoví analytici mají následující povinnosti:

• Analýza a pochopení požadavků na zamýšlený software
• Pochopení, jak projekt přispěje v rámci cílů organizace
• Identifikace zdrojů požadavků
• Ověření požadavků
• Vypracování a implementace plánu řízení požadavků
• Dokumentace obchodních, technických, procesních a produktových požadavků
• Koordinace s klienty za účelem stanovení priorit požadavků a odstranění a nejednoznačnosti
• Finalizace kritérií přijatelnosti s klientem a dalšími zainteresovanými stranami

Metriky a míry softwaru

Měry softwaru lze chápat jako proces kvantifikace a symbolizace různých atributů a aspektů softwaru.

Softwarové metriky poskytují míry pro různé aspekty softwarového procesu a softwarového produktu.

Softwarové míry jsou základním požadavkem softwarového inženýrství. Pomáhají nejen řídit proces vývoje softwaru, ale také pomáhají udržet vynikající kvalitu konečného produktu.

Podle Toma DeMarca, (softwarového inženýra): „Nemůžete řídit to, co nemůžete měřit.“ Podle jeho výroku je zcela zřejmé, jak důležité jsou softwarové metriky.

Podívejme se na některé softwarové metriky:

• Metriky velikosti – LOC (Lines of Code), většinou se počítá v tisících dodaných řádků zdrojového kódu, označuje se jako KLOC.

  Počet funkčních bodů je mírou funkčnosti poskytované softwarem. Function Point Count definuje velikost funkčního aspektu softwaru.

• Metriky složitosti – McCabeova cyklomatická složitost kvantifikuje horní hranici počtu nezávislých cest v programu, která je vnímána jako složitost programu nebo jeho modulů. Reprezentuje se v pojmech teorie grafů pomocí grafu řídicích toků.

• Metriky kvality – Vady, jejich typy a příčiny, důsledky, intenzita závažnosti a jejich důsledky definují kvalitu produktu.

  The number of defects found in development process and number of defects reported by the client after the product is installed or delivered at client-end, define quality of product.

• Process Metrics – In various phases of SDLC, the methods and tools used, the company standards and the performance of development are software process metrics.
• Resource Metrics – Effort, time and various resources used, represents metrics for resource measurement.