Rechizite software

Rechizitele software sunt descrierea caracteristicilor și funcționalităților sistemului țintă. Cerințele transmit așteptările utilizatorilor de la produsul software. Cerințele pot fi evidente sau ascunse, cunoscute sau necunoscute, așteptate sau neașteptate din punctul de vedere al clientului.

Inginerie a cerințelor

Procesul de colectare a cerințelor software de la client, de analiză și documentare a acestora este cunoscut sub numele de inginerie a cerințelor.

Scopul ingineriei cerințelor este de a dezvolta și de a menține un document sofisticat și descriptiv „Specificația cerințelor sistemului”.

Procesul de inginerie a cerințelor

Este un proces în patru etape, care include –

• Studiu de fezabilitate
• Requirement Gathering
• Specificație a cerințelor software
• Validare a cerințelor software

Să vedem pe scurt procesul –

Studiu de fezabilitate

Când clientul abordează organizația pentru a obține dezvoltarea produsului dorit, acesta vine cu o idee aproximativă cu privire la toate funcțiile pe care software-ul trebuie să le îndeplinească și care sunt toate caracteristicile așteptate de la acesta.

Referindu-se la aceste informații, analiștii fac un studiu detaliat cu privire la faptul dacă sistemul dorit și funcționalitatea acestuia sunt fezabile pentru a fi dezvoltate.

Acest studiu de fezabilitate este axat pe obiectivul organizației. Acest studiu analizează dacă produsul software poate fi materializat în mod practic din punct de vedere al implementării, al contribuției proiectului la organizație, al constrângerilor de cost și în conformitate cu valorile și obiectivele organizației. Acesta explorează aspectele tehnice ale proiectului și ale produsului, cum ar fi utilizabilitatea, mentenabilitatea, productivitatea și capacitatea de integrare.

Rezultatul acestei faze ar trebui să fie un raport al studiului de fezabilitate care ar trebui să conțină comentarii și recomandări adecvate pentru conducere cu privire la oportunitatea de a întreprinde sau nu proiectul.

Colectarea cerințelor

În cazul în care raportul de fezabilitate este pozitiv față de realizarea proiectului, următoarea fază începe cu colectarea cerințelor de la utilizator. Analiștii și inginerii comunică cu clientul și cu utilizatorii finali pentru a cunoaște ideile acestora cu privire la ceea ce ar trebui să ofere software-ul și ce caracteristici doresc să includă software-ul.

Specificația cerințelor software

SRS este un document creat de analistul de sistem după ce cerințele sunt colectate de la diverse părți interesate.

SRS definește modul în care software-ul preconizat va interacționa cu hardware-ul, interfețele externe, viteza de operare, timpul de răspuns al sistemului, portabilitatea software-ului pe diferite platforme, mentenabilitatea, viteza de recuperare după prăbușire, securitatea, calitatea, limitările etc.

Exigențele primite de la client sunt scrise în limbaj natural. Este responsabilitatea analistului de sistem să documenteze cerințele în limbaj tehnic, astfel încât acestea să poată fi înțelese și utile echipei de dezvoltare software.

SRS ar trebui să vină cu următoarele caracteristici:

• Exigențele utilizatorului sunt exprimate în limbaj natural.
• Exigențele tehnice sunt exprimate într-un limbaj structurat, care este utilizat în interiorul organizației.
• Descrierea proiectului ar trebui să fie scrisă în Pseudocod.
• 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:

• Colectarea cerințelor – Dezvoltatorii discută cu clientul și cu utilizatorii finali și cunosc așteptările acestora de la software.
• Organizarea cerințelor – Dezvoltatorii prioritizează și aranjează cerințele în ordinea importanței, urgenței și convenienței.

• Negociere & discuție – Dacă cerințele sunt ambigue sau există unele conflicte în cerințele diferitelor părți interesate, dacă sunt, atunci se negociază și se discută cu părțile interesate. Cerințele pot fi apoi prioritizate și compromise în mod rezonabil.

  Cerințele provin de la diverse părți interesate. Pentru a elimina ambiguitatea și conflictele, acestea sunt discutate pentru claritate și corectitudine. Cerințele nerealiste sunt compromise în mod rezonabil.

• Documentație – Toate cerințele formale & informale, funcționale și nefuncționale sunt documentate și puse la dispoziție pentru procesarea în faza următoare.

Tehnici de solicitare a cerințelor

Solicitarea cerințelor este procesul de descoperire a cerințelor pentru un sistem software preconizat prin comunicarea cu clientul, utilizatorii finali, utilizatorii de sistem și alte persoane care au un interes în dezvoltarea sistemului software.

Există diverse modalități de a descoperi cerințele

Interviuri

Interviurile sunt un mijloc puternic de colectare a cerințelor. Organizația poate realiza mai multe tipuri de interviuri, cum ar fi:

• Interviuri structurate (închise), în care fiecare informație de colectat este decisă în avans, acestea urmează cu fermitate modelul și subiectul discuției.
• Interviuri nestructurate (deschise), în care informațiile de colectat nu sunt decise în avans, mai flexibile și mai puțin tendențioase.
• Interviuri orale
• Interviuri scrise
• Interviuri individuale, care se desfășoară între două persoane aflate de cealaltă parte a mesei.
• Interviuri de grup, care se desfășoară între grupuri de participanți. Acestea ajută la descoperirea oricărei cerințe care lipsește, deoarece sunt implicate numeroase persoane.

Sondaje

Organizația poate efectua sondaje în rândul diferitelor părți interesate prin interogarea cu privire la așteptările și cerințele lor față de viitorul sistem.

Chestionare

Un document cu un set predefinit de întrebări obiective și opțiunile respective este înmânat tuturor părților interesate pentru a răspunde, care sunt colectate și compilate.

Un neajuns al acestei tehnici este că, dacă o opțiune pentru o anumită problemă nu este menționată în chestionar, problema ar putea fi lăsată nesupravegheată.

Analiza sarcinilor

Echipa de ingineri și dezvoltatori poate analiza operațiunea pentru care este necesar noul sistem. Dacă clientul are deja un software pentru a efectua o anumită operațiune, acesta este studiat și se colectează cerințele sistemului propus.

Analiza domeniului

Care software se încadrează în anumite categorii de domenii. Persoanele experte în domeniu pot fi de mare ajutor pentru a analiza cerințele generale și specifice.

Brainstorming

Se organizează o dezbatere informală între diferitele părți interesate și toate contribuțiile acestora sunt înregistrate pentru analiza ulterioară a cerințelor.

Prototiparea

Prototiparea constă în construirea interfeței cu utilizatorul fără a adăuga funcționalități detaliate pentru ca utilizatorul să interpreteze caracteristicile produsului software preconizat. Ajută la oferirea unei idei mai bune a cerințelor. În cazul în care nu există un software instalat la client pentru referință pentru dezvoltator și clientul nu este conștient de propriile cerințe, dezvoltatorul creează un prototip pe baza cerințelor menționate inițial. Prototipul este prezentat clientului și se notează feedback-ul acestuia. Feedback-ul clientului servește drept intrare pentru colectarea cerințelor.

Observație

Echipa de experți vizitează organizația sau locul de muncă al clientului. Aceștia observă funcționarea reală a sistemelor instalate existente. Aceștia observă fluxul de lucru la nivelul clientului și modul în care sunt abordate problemele de execuție. 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.

În general, cerințele software ar trebui să fie clasificate în două categorii:

Exigențe funcționale

În această categorie intră cerințele care sunt legate de aspectul funcțional al software-ului.

Ele definesc funcțiile și funcționalitatea în cadrul sistemului software și dinspre acesta.

Exemple –

• Opțiune de căutare oferită utilizatorului pentru a căuta din diverse facturi.
• Utilizatorul ar trebui să poată trimite prin poștă orice raport către conducere.
• Utilizatorii pot fi împărțiți în grupuri și grupurilor li se pot acorda drepturi separate.
• Ar trebui să respecte regulile de afaceri și funcțiile administrative.
• Software-ul este dezvoltat păstrând intactă compatibilitatea descendentă.

Exigențe nefuncționale

Exigențele, care nu sunt legate de aspectul funcțional al software-ului, se încadrează în această categorie. Ele sunt caracteristici implicite sau așteptate ale software-ului, pe care utilizatorii și le asumă.

Cerințele nefuncționale includ.

• 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.
• Furnizează informații de ajutor
• Abordare centrată pe utilizator
• Setări de vizualizare bazate pe grup.

Software System Analyst

Analistul de sistem într-o organizație IT este o persoană, care analizează cerința sistemului propus și se asigură că cerințele sunt concepute și documentate corect & corect. Rolul unui analist începe în timpul fazei de analiză software a SDLC. Este responsabilitatea analistului să se asigure că software-ul dezvoltat îndeplinește cerințele clientului.

Analiștii de sistem au următoarele responsabilități:

• Analizarea și înțelegerea cerințelor software-ului vizat
• Înțelegerea modului în care proiectul va contribui la obiectivele organizației
• Identificarea surselor de cerințe
• Validarea cerințelor
• Dezvoltarea și implementarea planului de management al cerințelor
• Documentarea cerințelor de afaceri, tehnice, cerințele de proces și de produs
• Coordonare cu clienții pentru a prioritiza cerințele și pentru a elimina și ambiguitatea
• Finalizarea criteriilor de acceptare cu clientul și alte părți interesate

Metrice și măsuri software

Măsurile software pot fi înțelese ca un proces de cuantificare și simbolizare a diferitelor atribute și aspecte ale software-ului.

Metricele software furnizează măsuri pentru diverse aspecte ale procesului software și ale produsului software.

Măsurile software sunt cerințe fundamentale ale ingineriei software. Ele nu numai că ajută la controlul procesului de dezvoltare a software-ului, dar ajută și la menținerea unei calități excelente a produsului final.

Potrivit lui Tom DeMarco, un (inginer software), „Nu poți controla ceea ce nu poți măsura”. Prin spusele sale, este foarte clar cât de importante sunt măsurile software.

Să vedem câțiva parametri software:

• Metricele de mărime – LOC (Lines of Code), calculate de cele mai multe ori în mii de linii de cod sursă livrate, notate ca KLOC.

  Function Point Count este o măsură a funcționalității oferite de software. Function Point count definește dimensiunea aspectului funcțional al software-ului.

• Măsurători de complexitate – Complexitatea ciclomatică a lui McCabe cuantifică limita superioară a numărului de căi independente dintr-un program, care este percepută ca fiind complexitatea programului sau a modulelor sale. Este reprezentată în termeni de concepte ale teoriei grafurilor prin utilizarea graficului fluxului de control.

• Metricele calității – Defectele, tipurile și cauzele acestora, consecințele, intensitatea gravității și implicațiile lor definesc calitatea produsului.

  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.