Към съдържанието
wannacode

Доброто изискване

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

Проблем

„Отстъпката се показва ясно“

Изискването е едно изречение: „Отстъпката се показва ясно в количката.“ Дизайнерът я слага със сив шрифт под сумата. Тестерът я вижда: показана е, четлива е, минава. Собственикът я вижда на пускането и пита къде е червеният зачертан ред, който е искал.

Всеки е прочел „ясно“ по своему. Никой не е сбъркал, а продуктът пак не е това, което трябваше.

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

Идеята

Какво прави едно изискване добро

Стандартът ISO/IEC/IEEE 29148 изрежда качествата на доброто изискване. Ето ги с магазина:

Качество Значи Пример за нарушение
Необходимо (necessary) махнеш ли го, нещо важно липсва „Логото е в горния ляв ъгъл“, записано като изискване, което никой не е поискал.
Уместно (appropriate) нивото на детайла пасва; не казва как, когато трябва да каже какво „Поръчката се пише в таблица с три колони“ на ниво „какво трябва на счетоводството“.
Еднозначно (unambiguous) чете се само по един начин „Кодът важи веднъж“: на клиент или на поръчка?
Пълно (complete) не трябва нищо повече, за да се разбере и провери „Връщане до 14 дни“: от кога?
Единично (singular) казва едно нещо „Показва сумата и позволява смяна на адреса.“
Осъществимо (feasible) може да се направи с времето, парите и технологиите наличност в реално време от доставчици без връзка
Проверимо (verifiable) има начин да се докаже, че е изпълнено „Количката се отваря бързо.“
Вярно (correct) казва точно нуждата „Над 50 €“, когато собственикът иска „от 50 €“.
Съответстващо (conforming) следва формата, приет в екипа всички изисквания са „И-номер, изречение, мерило“, а това е абзац без номер.

Не учи таблицата наизуст. Важните въпроси са три: разбира ли се по един начин, може ли да се провери и това ли е нуждата.

По-точно, за любопитните

Деветте качества по-горе са от второто издание на ISO/IEC/IEEE 29148 (2018), за отделно изискване. Английските имена: necessary, appropriate, unambiguous, complete, singular, feasible, verifiable, correct, conforming. Българските са превод на курса.

Списъкът се е менял между изданията и между източниците. По-стари текстове изреждат и „проследимо“ (traceable) и „без решение вътре“ (implementation-free). Проследимостта тук е в отделен модул, а „без решение вътре“ е част от „уместно“: решението е грешка, когато е на ниво, на което трябва нужда.

IREB CPRE има свой списък с качества, близък, но не със същите имена. Ако се готвиш за изпит, учи списъка от програмата, по която се явяваш. Идеята в двата е една: изискването трябва да се разбира по един начин, да може да се провери и да казва истинската нужда.

Пробвай

Кое качество липсва?

1. „Количката показва сумата и позволява смяна на адреса за доставка.“
2. „Доставката е безплатна при поръчка над 50 €.“ Собственикът е искал „от 50 € включително“.
3. „Магазинът показва точната наличност на всеки продукт във всички складове на всички доставчици в реално време.“ Доставчиците нямат връзка към системата.
4. „Системата пише всяка поръчка в таблица с колони номер, сума и дата.“ Изискването е на ниво „какво трябва на счетоводството“.

Идеята

Думите-капани

Някои думи почти винаги значат дефект. Когато ги видиш, спри:

  • „бързо“, „удобно“, „лесно“, „ясно“, „модерно“: няма мерило. Всеки ги чете по своему, и никой тест не може да падне. Това е непроверимо.
  • „и т.н.“, „и други“, „при нужда“: списъкът е отворен. Програмистът ще допише своето, тестерът своето. Това е непълно.
  • „ако е възможно“, „по възможност“, „където е уместно“: вратичка. Изискване, което може да не се изпълни, без да е нарушено, не е изискване. И това е непроверимо.
  • „веднъж“, „над“, „до 14 дни“: думи, които се четат по два начина. Това е двусмислено.
  • „потребителят“, „системата позволява“: кой точно? Клиент, служител, всеки посетител? Това е изискване без роля.
  • „бутон“, „таблица“, „в браузъра“ в изискване за нужда: решение вместо нужда.
  • И когато две изисквания казват различни неща за един и същ случай, те противоречат си.

Шестте вида са същите, които ще избираш в задачите по-долу.

Идеята

Как се поправя

Поправката не е по-хубава дума. Тя е мерило, условие и роля. Едно изискване на решението обикновено има тези части:

[кога] [кой] [трябва да] [какво прави] [с какво] [колко добре]

„Количката се отваря бързо“ става:

„Когато клиентът отвори количката, страницата се показва за под 2 секунди в 95 % от случаите, при 500 клиенти едновременно, на мобилна мрежа.“

„Кодът важи веднъж“ става:

„Клиентът може да ползва всеки промо код в една платена поръчка. Втори опит със същия код се отказва със съобщението „Кодът вече е ползван“.“

Изреченията станаха по-дълги, и това е цената. Но сега всеки ги чете по един начин, и тестерът знае какво да провери. Най-силната проверка е примерът: „Мария плаща с ЕСЕН10 днес и утре пак. Какво става?“

По-точно, за любопитните

IREB CPRE препоръчва шаблони за изречения на изисквания. Сред най-известните в практиката е EARS (Easy Approach to Requirements Syntax): „When [събитие], the [system] shall [отговор]“, „While [състояние], …“, „If [нежелано събитие], then …“. В английските спецификации думата shall значи задължително, should препоръчително, may по избор.

29148 дава и списък с думи и конструкции, които да се избягват, например: превъзходни степени („най-добрият“), субективни думи („удобен“), неясни местоимения („то“), вратички („ако е възможно“, „където е приложимо“), думи за пълнота, които не могат да се проверят („всички“, „винаги“, „никога“), и отрицания, когато може да се каже какво трябва.

Пробвай

Рецензирай: количката

Отбележи думите, които правят изискването лошо, и избери какъв е проблемът във всяка.

Натисни думите, които са проблем; отново, за да махнеш отметката. Със стрелките се минава от дума на дума.

Идеята

Наборът изисквания

Всяко изискване може да е добро само по себе си, а наборът пак да е лош. 29148 изрежда и качествата на целия набор:

  • пълен (complete): има всичко нужно. Липсват ли връщането, отказът или складът, наборът е непълен, колкото и хубаво да е всяко изречение;
  • непротиворечив (consistent): две изисквания не казват различно за един и същ случай;
  • осъществим (feasible): всичко заедно може да се направи с времето и парите;
  • разбираем (comprehensible): ясно е какво се очаква от системата като цяло;
  • може да се валидира (able to be validated): може да се покаже, че наборът ще покрие нуждите на бизнеса.

Противоречията са коварни, защото всяко от двете изисквания изглежда добро. „Безплатна доставка над 50 €“ на страница 3 и „без такса от 50 € включително“ на страница 17 минават поотделно всяка рецензия. Хващат се, когато ги търсиш за един и същ случай: точно 50,00 €.

Упражнение

Рецензия на изискванията

1. Промо кодове. Изискванията за промо кодовете, както са дошли от срещата.

Отбележи всяко място, което прави изискването лошо.

Натисни думите, които са проблем; отново, за да махнеш отметката. Със стрелките се минава от дума на дума.

2. Доставка. Четири изисквания от спецификацията на доставката, от различни страници.

Отбележи проблемите и избери вида на всеки. Внимавай за изисквания, които си противоречат.

Натисни думите, които са проблем; отново, за да махнеш отметката. Със стрелките се минава от дума на дума.

3. Връщане. Изискванията за връщане на продукт.

Отбележи всяко място, което прави изискването лошо.

Натисни думите, които са проблем; отново, за да махнеш отметката. Със стрелките се минава от дума на дума.

Тест

Провери се

1. „Количката се отваря бързо.“ Какво не е наред по 29148?
2. Кое е качество на набора изисквания, а не на едно изискване?
3. Изискване може да е проверимо и пак грешно. Кое качество липсва тогава?
4. Защо „ако е възможно“ е проблем?
5. Кога е най-евтино да се намери дефектът „над 50 €“ вместо „от 50 €“?

Създаден от Иво Гергов като част от кампанията на Evo Tech за достъпно обучение по програмиране ·