Această serie de articole este destinată tuturor persoanelor implicate în proiecte de dezvoltare de software: şefi de departament, şefi de proiect, analişti (în primul rând lor), arhitecţi software, programatori sau specialişti în asigurarea calităţii...

Analiza cerinţelor software (pe care o vom numi în continuare Analiza de business sau Analiză software) este aceea dintre disciplinele existente în domeniul Software care determină ce trebuie făcut, preluând nevoia clientului şi exprimând-o într-un inteligibil pentru dezvoltator....

Adevăruri ale dezvoltării software care susțin nevoia Analizei cerințelor. Unul dintre ele este: "Întotdeauna, într-un proiect software apar situaţii neprevăzute. Situaţiile neprevăzute nu sunt o abatere de la regulă ci sunt chiar regula"...

Deşi în limba engleză este denumit Software Development Life Cycle (SDLC) am ales traducerea „Ciclul de dezvoltare al produsului software”, chiar dacă tendinţa întâlnită cel mai adesea este să se traducă prin „Ciclul de viaţă al produsului software”...

Asumarea realităţii că întotdeauna, în decursul proiectului, cerinţele se vor schimba a condus la apariţia unui model de dezvoltare realist, care să fie adaptat acestei realităţi şi care să permită înglobarea schimbării în cel mai bun mod cu putinţă...

Elementul central în Analiză este, cu siguranţă, cerinţa software. În jurul cerinţelor se desfăşoară totul: cerinţele trebuie culese de la clienţi, cerinţele trebuie documentate, trebuie gestionate, dezvoltate, testate. În fond, modelul creat prin specificaţiile software este un model compus din cerinţe care trebuie să se transforme în produsul final...

Prin descompunere, problema era spartă în sub-probleme astfel: - sub-problema 1: cunoaşterea necesarului real: - sub-problema 1.1: cunoaşterea vânzărilor din trecut; - sub-problema 1.2: cunoaşterea comenzilor curente de la clienţi; - sub-problema 1.3: cunoaşterea stocului curent...

Pornind de la problema iniţială, fiecare nivel de descompunere reprezintă o soluţie, dar în acelaşi timp o problemă. Totuşi, la un anumit nivel trebuie să se găsească soluţia finală. Judecând lucrurile practic, ar fi o eroare să ne închipuim că putem să lungim lucrurile la nesfârşit. Undeva trebuie să se termine (aşa cum bugetul alocat proiectului se termină sigur undeva). ...

Probabil ca într-o lume ideala, în care programatorii ar fi avut la dispozitie un buget nelimitat, termene nelimitate, o echipa stabila si un set stabil de functionalitati, proiectul s-ar fi sfârsit cu bine. Asta însemnând ca functionalitatile cerute ar fi fost cândva gata, la parametrii de calitate ceruți...

Acestea pot fi cerinţe legate de atributele de calitate a produsului, cerinţe privind performanţa, respectarea unor standarde, regulamente, contracte, interfeţe externe sau alte constrângeri de design...

Atunci când sunteţi în situaţia de a culege, analiza şi specifica cerinţe trebuie să aveţi în vedere că, indiferent de forma în care o specificaţi, în limbaj natural, în UML sau în orice alt limbaj, sub formă de use case-uri sau full text, indiferent de tipul lor, cerinţele trebuie să aibă anumite caracteristici care le fac să fie cerinţe adevărate, corect specificate şi posibil de realizat, în parametrii bugetari şi de calitate determinaţi...

A. Dezvoltarea cerinţelor – etapă care are ca scop crearea modelului iniţial; B. Managementul cerinţelor - etapă care are ca scop introducerea schimbării, în mod controlat, în proiect, astfel încât să fie respectate restricţiile externe (buget, calitate, resurse umane)....