Управление на изискванията в проектите

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

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

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

Оценката и приоритизирането на изискванията е важна стъпка за успеха на проекта. Тъй като проектите в един все по-глобализиран свят стават все по-сложни и все по-динамични, то са необходими нови методи и средства за тяхното управление. Става дума за новата и бързо развиваща се наука за управление на изискванията в проектите Requirements Management of the Projects (RMP) или съкратено Requirements Management (RM) и за професията на специалист управление на изискванията Requirement Engineering.

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

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

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

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

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

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

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

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

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

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

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

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

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

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