Формулиране на клиентските изисквания към един софтуерен продукт

Един от ключовите проблеми при разработването на един софтуерен продукт са непълните или неясни изисквания, зададени от клиента. Софтуерните разработчици са хора с много силно развито аналитично и детайлно мислене и имат нужда от точно и ясно обяснение какво трябва да се направи при всяка една възможна ситуация. Или, казано на програмистки език – какво трябва да се случи при всяко едно разклонение на if оператора.

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

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

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

Ето темите, които Кришна е изброил като важни, с коментари от мен:

1. Операции: Какво може да направи потребителя с един запис – разглеждане, добавяне, модифициране и изтриване? Какви са логическите ограничения върху всяка една операция? Например, може ли да се изтрие физически един запис или е необходимо да се запази за историята и само да се маркира като изтрит?
2. Сигурност: Кой може да извършва всяка една операция? Това може да звучи тривиално, но действително е необходимо клиентът да дефинира правата на достъп и на изпълнение на различните дейности в системата за всяка една категория потребители.
3. Лог и одит: Дали трябва приложението да пази информация за всяка една извършена операция и кой я е извършил? Необходимо ли е да се пази всяка една версия на записа за целите на историята? Кой има право да чете логовете? Колко време ще се пазят историческите записи и кой може да ги изтрива?
4. Зависимости: Как действие върху един обект влияе на другите части от системата? Например, може ли да бъде изтрита една фактура, ако по нея вече е регистрирано плащане?
5. Заключване и конкурентна работа: Има ли възможност за конкурентна работа на няколко потребителя върху един запис? Какви операции могат да се извършват едновременно от няколко потребителя? Какъв подход ще изберем, за да предпазим данните от повреждане, породено от едновременната работа на няколко потребителя върху тях? Тези въпроси са толкова по-важни, колкото са по-важни и отговорни данните, с които борави системата.
6. Собственост и споделяне на данните: Дали един запис принадлежи на един специфичен потребител или всеки може да манипулира данните на другите? А могат ли данните да се споделят с други хора? Кои данни са публични и кои – секретни?
7. Работен процес (Workflow): Какъв е жизнения цикъл на един обект или запис? През какви фази и състояния преминава? Кои са събитията, които прехвърлят един запис от едно състояние в друго? При какви условия е възможно това? Кой има право да го извърши? Какви са възможните следващи стъпки или състояния?
8. Формат на данните: В какви изходящи формати могат да се изваждат справките? От какви формати системата трябва да импортва данни? Какви интерфейси с външни системи ще се поддържат? Едностранни или двустранни са тези интерфейси? Например, необходимо ли е други приложения да се обръщат към нашата система? Или нашата система да се обръща към други системи? По какви протоколи става тази комуникация?
9. Визуални формати (Usability): Дали за крайния потребител е по-удобно да въвежда данните във форми, или в табличен формат? Дали им е по-лесно да работят с клавиатура или с мишка? Важен критерий ли е бързото опериране с данните и как можем да направим визуалния интерфейс по-удобен за потребителя?

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

Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се напълно безплатно за нашия бюлетин чрез RSS feed или по имейл