Бизнес изисквания: дизайн и примери за дизайн

Бизнес изискванията са спецификации, които, след като бъдат предоставени, осигуряват стойност и описват характеристиките на предложената система от гледна точка на крайния потребител. И те се наричат също списък на заявленията на заинтересованите страни. Продуктите, софтуерът и процесите са начини, как да поставите и да отговарят на нуждите на предприятието. Вследствие на това бизнес изискванията често се обсъждат в контекста на разработването или придобиването на софтуер или други системи.

Определение

Объркването на терминологията се дължи на три основни причини:

1. Обичайната практика е да се говори за цели или очаквани ползи как да правим бизнес-изисквания.
2. Хората са склонни да използват този термин, за да обозначат характеристиките на продукта, системата или софтуера, които са предназначени да създават.
3. Широко разпространен модел твърди, че двата типа изисквания се различават само по нивото на детайлност или абстракция - когато бизнес изискванията са на високо ниво, често неясни и се декомпозират на подробни приложения към компонент.

Това недоразумение може да бъде избегнато, като се признае, че концепцията не е цели, а по-скоро отговаря на тях (т.е. предоставя стойност), когато те са изпълнени. Бизнес изискванията не се разлагат на продукти, системи и софтуер. По-скоро е обратното. Продуктите и техните приложения са в отговор на бизнес изискванията - вероятно за да ги изпълнят. Тази концепция съществува в производствената среда и трябва да бъде открита, докато търсенето на продукти се определя от човека. Изискванията към бизнес плана не се ограничават до наличието на високо ниво, а трябва да бъдат сведени до детайлите. Независимо от степента на подробност, заявките винаги носят стойност, когато са изпълнени.

Обновяване на продукта

В проекти за разработване на системи или софтуер за изискванията на малкия бизнес обикновено са необходими разрешения от заинтересованите страни. Те водят до създаването или актуализирането на продукта. Бизнес изискванията към системите и софтуера обикновено се състоят от функционални и нефункционални изисквания. Разбира се, те обикновено се определят във връзка с първата версия на възможностите на продукта. Вторият често отразява дизайна на бизнес изискванията, които понякога се разглеждат като ограничения. Те могат да включват необходимите аспекти на производителността или сигурността, които се прилагат на производствено ниво.

Акцент върху процесите

Приложенията често са изброени в белите книги. Акцентът при тях е върху процеса или дейността по точното планиране и разработване на бизнес изискванията, а не върху начина на постигането им. Този параметър обикновено се делегира от спецификацията, документа за системни заявки или друга опция. Възможно е да възникне объркване между двете, ако не се вземат предвид всички разлики. В резултат на това много бели книги всъщност описват изискванията към даден продукт, система или софтуер.

Преглед

Бизнес изискванията в контекста на разработването на софтуер или на жизнения цикъл на софтуера са концепция за идентифициране и документиране на всички потребители. Например, като клиенти, служители и доставчици, в ранните етапи на цикъла на разработване на системата, за да се направлява проектирането на бъдещата система. Заявленията често се регистрират от анализатори. Те са тези, които анализират изискванията на бизнес процеса и често проучват "както е", за да се определи целевата "бъдеща.

Състав на приложенията

Изискванията към бизнес процесите често включват:

1. Контекст, област и предистория, включително причини за промяна.
2. Ключови заинтересовани страни, които имат изисквания.
3. Фактори за успех за бъдещото или целевото състояние.
4. Ограничения, наложени от бизнеса или други системи.
5. Модели и анализ на процесите, често с помощта на блок-схеми, за да се представи всичко "както е".
6. Логически модел на данните и препратки към речника.
7. Речници на бизнес термини и местен жаргон.
8. диаграми на потока данни за илюстриране на начина, по който данните преминават през информационните системи (за разлика от блок-схемите, изобразяващи алгоритмичния поток на бизнес транзакциите).

Роли

Най-популярният формат за записване на бизнес изисквания е документ. Тяхната цел е да определят какви резултати ще са необходими на системата, но в крайна сметка тя може да бъде разработена без допълнителни условия. Вследствие на това документите се допълват от информационни материали, в които подробно се описват технологичните характеристики и инфраструктурните очаквания, включително всички професионални изисквания, отнасящи се до качеството на услугата.Това са например производителност, възможност за поддръжка, адаптивност, надеждност, наличност, сигурност и мащабируемост.

Пълнота

Създаването на прототипи на ранен етап от тестването позволява да се оцени пълнотата и точността на идентифицираните бизнес изисквания. Заинтересованите страни първо преминават през процедурата, за да помогнат за определянето на структурата. Резултатът се насочва към екипите за разработване на бизнес изискванията на проекта, които изграждат системата. Други заинтересовани страни тестват и оценяват окончателната разгърната проекция. Яснотата изисква проследяване на заявките и тяхното разрешаване с официален процес за определяне на подходящия шаблон.

Обхватът на бизнес изискванията не е непременно ограничен до фазата на дефиниране, какво трябва да бъде да се изгражда като система. Тя надхвърля простото определяне на начина на управление и поддържане на настоящата стратегия. И да гарантирате, че тя винаги е в съответствие с бизнес целите. Документът с изискванията трябва да се преработва непрекъснато по контролиран начин. Наличието на стандартизиран формат или шаблони, разработени за конкретни бизнес функции и области, може да гарантира пълнота на заявките, както и да запази фокуса на полето.

Прототипът

Макар че обикновено се счита за средство за оценка на изискванията, прототипирането обикновено измества фокуса върху продукта или системата, която се създава. Прототипите са работещ софтуер, което означава, че те се състоят от три етапа (приложение, инженеринг или технически дизайн и изпълнение), отдалечени от бизнес изискванията. Това са и предварителни версии, които разработчикът възнамерява да приложи.

Тъй като прототипите са съвсем конкретни, заинтересованите страни, които ги изпробват, могат да дадат по-значима обратна връзка за някои аспекти на това, което разработчикът създава, което е интерпретация на начина за удовлетворяване на. Освен това се набляга на графичния потребителски интерфейс, а вътрешната част е с преки пътища. Те съставляват основната част от програмната логика и в тях се изпълняват повечето бизнес изисквания. С други думи, проблемите, които разкриват прототипите, едва ли са свързани със заявките.

Развитие

Важно е да разпознавате промените в приложенията, да ги документирате и актуализирате. Въпреки това бизнес изискванията не се променят толкова, колкото информираността за тях. Бизнес изискване може да е налице, но да не е разпознато или разбрано от заинтересованите страни, анализаторите и екипа на проекта.

Промените обикновено отразяват възприетите начини за удовлетворяване на недостатъчно дефинирани материали. Голяма част от трудностите при изпълнението на бизнес изискванията всъщност отразяват общата практика, насочена към почти всички усилия, свързани с тях, към това, което всъщност е проектиране на продукт, система или софтуер на високо ниво. Това се дължи на невъзможността първо да се определят адекватно бизнес изискванията, за да се осигури стойност.

Специалистите в областта на развойната дейност обикновено продължават да преработват продукта, докато накрая се "върнат" към решение, което изглежда отговаря на нуждите, т.е. изглежда, че отговаря на производствените изисквания. Косвени методи на проба и грешка за определяне на бизнес изискванията са основа за Голяма част от "итеративното разработване", включително популярни техники, които се рекламират като "най-добри практики".

Проекти на образци

Шаблоните помагат за бързото заявяване на конкретни теми, които често могат да са свързани със заявки. Те могат да създадат стандартизирана документация, свързана с бизнес изискванията, което може да улесни разбирането. Шаблоните не гарантират точността или пълнотата на заявките. Често неправилно използваните примери оказват отрицателно въздействие върху научните изследвания, тъй като са склонни да насърчават повърхностността и най-вече механичното определяне без смислен анализ.

Трудности

Бизнес изискванията често се затягат преждевременно поради големия брой заинтересовани страни, участващи в определянето им, при което съществува възможност за конфликт на интереси. Процесът на управление и постигане на консенсус може да бъде деликатен и дори политически. По-малко сложни, макар и често срещани, са разпределените групи със заинтересовани страни на различни географски места. Естествено, служителите по продажбите са по-близо до клиентите си, а служителите в производството - до съответните си звена. Финансите и управлението на служителите, включително висшето ръководство, са по-близо до седалището на фирмата.

Бизнес изискванията, например, са необходими за система, в която има потребители от сферата на продажбите и производството. Възможно е да се сблъска с конфликт на цели - едната страна се интересува от осигуряването на възможно най-много функции, докато другият ще се съсредоточи върху най-ниските производствени разходи. Такива ситуации често завършват с консенсус, с максимални възможности за разумно и изгодно ценообразуване и дистрибуция.

За да се справим с тези предизвикателства, ранното ангажиране на заинтересованите страни се постига чрез демонстрации на прототипи и съвместна работа. Практическите семинари, както под формата на организирани сесии, така и на обикновени дискусии, помагат за постигане на консенсус, особено във връзка с чувствителни бизнес изисквания и при потенциални конфликти на интереси. Сложността на процеса е важен фактор. Това може да изисква специализирани познания, необходими за разбиране на юридически или Регулаторни изисквания, вътрешни насоки, като например брандинг или задължения за корпоративна социална отговорност. Анализът не се състои само в това да се улови "какво" на даден бизнес процес, но и "как" да се представи неговият контекст.