Cerințe de afaceri: proiectare și exemple

Cerințele de afaceri sunt specificații care, odată furnizate, oferă valoare și descriu caracteristicile sistemului propus din punctul de vedere al utilizatorului final. Și, de asemenea, se numește o listă de cereri ale părților interesate. Produsele, software-ul și procesele sunt modalități de, cum se livrează și să satisfacă nevoile afacerii. Prin urmare, cerințele de afaceri sunt adesea discutate în contextul dezvoltării sau achiziționării de software sau alte sisteme.

Definiție

Confuzia terminologică apare din trei motive principale:

1. Este o practică obișnuită să se prezinte obiectivele sau beneficiile așteptate ale ca o afacere-cerințe.
2. Oamenii au tendința de a folosi termenul pentru a se referi la caracteristicile unui produs, sistem, software care este destinat a fi construit.
3. Un model acceptat pe scară largă susține că cele două tipuri de aplicații diferă doar prin nivelul de detaliu sau abstractizare - în cazul în care cerințele de afaceri sunt de nivel înalt, adesea vagi și descompuse în aplicații detaliate la o componentă.

Această neînțelegere poate fi evitată prin recunoașterea faptului că conceptul nu reprezintă obiective, ci mai degrabă răspunde la acestea (adică oferă valoare) în îndeplinirea lor. Cerințele de afaceri nu se descompun în produs, sistem și software. Mai degrabă, este invers. Produsele și solicitările lor reprezintă un răspuns la cererile întreprinderilor - probabil pentru a le satisface. Conceptul există în mediul de producție și trebuie descoperit, în timp ce cererile de produse sunt definite de către om. Cerințele unui plan de afaceri nu se limitează la existența unui nivel înalt, ci ar trebui să fie redus la detalii. Indiferent de cantitatea de detalii, aplicațiile oferă întotdeauna valoare atunci când sunt satisfăcute.

Actualizare produs

În cadrul proiectelor de dezvoltare de sisteme sau software Pentru cerințele întreprinderilor mici, este de obicei necesar un mandat al părților interesate. Acestea sunt cele care duc la crearea sau reînnoirea produsului. Cerințele de afaceri pentru sistem și software constau, de obicei, în cereri funcționale și nefuncționale. Bineînțeles, acestea sunt definite de obicei împreună cu capacitatea produsului de primă opțiune. A doua reflectă adesea, de fapt, proiectarea cerințelor de afaceri, care sunt uneori considerate constrângeri. Acestea pot include aspectele necesare privind performanța sau siguranța aplicabile la nivelul producției.

Puncte importante ale procesului

Cererile sunt adesea enumerate în documentele oficiale. Accentul este pus pe procesul sau activitatea de planificare și dezvoltare precisă a cerințelor de afaceri, mai degrabă decât pe modul de realizare a acestora. Acest parametru este de obicei delegat prin caietul de sarcini sau prin documentul de solicitare a sistemului sau prin altă opțiune. Se poate crea confuzie între cele două dacă nu se ține cont de diferențele dintre ele. Prin urmare, multe cărți albe descriu de fapt cerințele pentru un produs, sistem sau software.

Prezentare generală

Cerințele de afaceri în contextul dezvoltării sau ciclului de viață al software-ului reprezintă conceptul de identificare și documentare a oricăror utilizatori. cum ar fi clienții, angajații și furnizorii, în etapele timpurii ale ciclului de dezvoltare a sistemului, pentru a ghida proiectarea viitoare. Solicitările sunt adesea capturate de analiști. Aceștia sunt cei care analizează cerințele procesului de afaceri și adesea studiază "Așa cum este"pentru a identifica ținta "viitorului.

Compoziția aplicațiilor

Cerințele proceselor de afaceri includ adesea:

1. Context, zonă și context, inclusiv motivele modificării.
2. Principalele părți interesate care au cerințe.
3. Factori de succes pentru starea viitoare sau țintă.
4. Constrângeri impuse de întreprinderi sau alte sisteme.
5. Modele și analize de proces, folosind adesea diagrame de flux pentru a reprezenta totul "așa cum este".
6. Modelul logic de date și referințe de vocabular.
7. Glosare de termeni de afaceri și jargon local.
8. Diagrame de flux de date pentru a ilustra modul în care datele circulă prin sistemele informatice (spre deosebire de diagramele de flux care descriu fluxul algoritmic al tranzacțiilor comerciale).

Roluri

Cel mai popular format pentru înregistrarea cerințelor de afaceri este documentul. Scopul lor este de a defini ce rezultate vor fi cerute sistemului, dar acesta poate fi dezvoltat în cele din urmă fără alte condiții. În consecință, documentele sunt completate de materiale de bază care detaliază performanțele tehnologiei și așteptările privind infrastructura, inclusiv orice cerințe profesionale, Calitatea serviciilor.Acestea sunt, de exemplu, performanță, mentenabilitate, adaptabilitate, fiabilitate, disponibilitate, securitate și scalabilitate.

Completitudine

Prototiparea într-un stadiu incipient al testării permite evaluarea completitudinii și acurateței cerințelor de afaceri identificate. Părțile interesate parcurg mai întâi procedura pentru a contribui la definirea cadrului. Iar rezultatul este transmis echipelor de cerințe de afaceri ale proiectului care construiesc sistemul. Alte părți interesate testează și evaluează proiecția finală implementată. Claritatea necesită urmărirea cererilor și soluționarea acestora, cu un proces formal pentru a determina modelul adecvat.

Domeniul de aplicare al cerințelor de afaceri nu se limitează neapărat la etapa de definire a, ce ar trebui să fie construit ca un sistem. Acest lucru merge dincolo de a prevedea modul de gestionare și de menținere a unei strategii existente. Și să se asigure că rămâne aliniat cu obiectivele de afaceri. Documentul de cerințe trebuie să fie revizuit continuu, într-un mod controlat. Existența unui format standardizat sau a unor șabloane concepute pentru anumite funcții și domenii de afaceri poate asigura caracterul complet al interogărilor, pe lângă menținerea unui domeniu concentrat.

Exemplu

Deși este considerată în general un mijloc de evaluare a cerințelor, prototiparea se concentrează de obicei pe produsul sau sistemul care se creează. Prototipurile sunt software care rulează, ceea ce înseamnă că ele constau în trei etape (aplicație, inginerie sau proiectare tehnică și implementare), departe de cerințele de afaceri. Și acestea sunt, de asemenea, versiuni preliminare pe care dezvoltatorul intenționează să le implementeze.

Deoarece prototipurile sunt destul de concrete, părțile interesate care le încearcă pot oferi un feedback mai semnificativ cu privire la unele aspecte ale ceea ce dezvoltatorul creează, ceea ce reprezintă o interpretare a modului de a satisface. În plus, se pune accent pe interfața grafică cu utilizatorul, iar partea internă este reprezentată de scurtături. Acestea constituie cea mai mare parte a logicii programului și aici vor fi îndeplinite majoritatea cerințelor de afaceri. Cu alte cuvinte, problemele pe care le dezvăluie prototipurile nu au legătură cu cererile.

Dezvoltare

Este important să recunoaștem schimbările în cereri, să le documentăm și să le actualizăm. Cu toate acestea, solicitările de afaceri tind să nu se schimbe atât de mult pe cât se conștientizează. O cerință de afaceri poate fi prezentă, dar nu este recunoscută sau înțeleasă de către părțile interesate, analiști și echipa de proiect.

Schimbările tind să reflecte modalitățile percepute de a satisface materiale definite inadecvat. O mare parte din dificultățile întâmpinate în îndeplinirea cerințelor de afaceri reflectă de fapt o practică comună în aproape toate eforturile implicate în ceea ce este de fapt un produs de nivel înalt, un sistem sau o proiectare de software. Acest lucru se datorează eșecului de a defini mai întâi în mod adecvat cerințele de afaceri pentru a oferi valoare.

De obicei, specialiștii în dezvoltare continuă să revizuiască produsul până când, în cele din urmă, "revin" la o soluție care pare să îndeplinească ceea ce este necesar, adică pare să îndeplinească cerințele de producție. Metodele indirecte de încercare și eroare pentru identificarea cerințelor de afaceri sunt baza pentru O mare parte din "dezvoltarea iterativă", inclusiv metodele populare care sunt promovate ca fiind "cele mai bune practici".

Exemple de design

Șabloanele ajută la solicitarea promptă a unor subiecte specifice, care pot fi adesea relevante pentru cererile de informații. Acestea pot crea o documentație standardizată a cerințelor de afaceri care poate facilita înțelegerea. Modelele nu garantează acuratețea sau caracterul complet al cererilor. Exemplele adesea folosite în mod greșit au un impact negativ asupra cercetării, deoarece tind să promoveze superficialitatea și, în principal, definirea mecanică fără o analiză semnificativă.

Provocări

Cerințele de afaceri sunt adesea restrânse prematur din cauza bazei mari de părți interesate implicate în definirea lor, unde este posibil să apară conflicte de interese. Procesul de gestionare și de obținere a consensului poate fi sensibil și chiar de natură politică. Mai puțin complexe, deși frecvente, sunt echipele distribuite cu părți interesate în diferite locații geografice. În mod firesc, personalul de vânzări este mai aproape de clienții lor, în timp ce personalul de producție este mai aproape de unitățile lor respective. Gestionarea finanțelor și a personalului, inclusiv a conducerii superioare, mai aproape de sediul social.

Cerințele de afaceri, de exemplu, sunt necesare pentru un sistem care implică utilizatori implicați în vânzări și producție. Se poate confrunta cu un conflict de obiective - o parte interesat să ofere cât mai multe caracteristici, în timp ce celălalt se va concentra pe cel mai mic cost de producție. Astfel de situații se finalizează adesea prin consens, cu cea mai bună oportunitate pentru prețuri și distribuție rezonabile și avantajoase.

Pentru a rezolva aceste probleme, implicarea timpurie a părților interesate se realizează prin demonstrații de prototipuri și prin colaborare. Atelierele de lucru practice, atât sub forma unor sesiuni organizate, cât și a unor simple discuții, contribuie la obținerea unui consens, în special în ceea ce privește cerințele sensibile ale întreprinderilor și în cazul în care există un potențial conflict de interese. Complexitatea procesului este un factor important. Acest lucru poate necesita expertiză în, necesare pentru înțelegere legal sau Cerințe de reglementare, orientări interne, cum ar fi angajamentele de branding sau de responsabilitate socială corporativă. Analiza nu se referă doar la capturarea "ce" unui proces de afaceri, ci și la "cum" de prezentare a contextului acestuia.