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

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

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

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

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

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

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

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

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

4 Comments

  • georgivar says:

    Usability на български се превежда ползваемост. То е качествена характеристика на даден обект – услуга, продукт, whatever – и визуалното представяне е само един от факторите, които влияят върху ползваемостта. Смея да твърдя не най-важния. Ето защо ми се струва неуместно превеждането на ползваемост с нещо от сорта на “визуални красоти”, защото е крайно време програмистите и голяма част от съсловието на разработчиците да разберат, че ползваемостта не е подправка, която се добавя към манджата за по-добър вкус, но в краен случай може и без нея.

  • Mike Ramm says:

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

    Наясно съм как се превежда usability и то няма нищо общо с “визуални красоти”, пък и тук се говори за формати, а не за красоти, все пак. 🙂

  • Angel says:

    Много добра статия, продължавайте в този дух.

  • Благодаря!

Leave a Reply

Your email address will not be published. Required fields are marked *