Особливості формулювання вимог до програмного забезпечення

2) Підготувати набір обмежень різних типів, які можуть траплятися в ході реалізації програмного проекту. Якщо цей перелік ґрунтується на попередньому досвіді реалізації аналогічного проекту, то маючи деякий готовий набір шаблонів з обмеженнями, його можна використовувати як основу для опису обмежень поточного проекту. Інакше доведеться розробляти заново шаблони вимог до ПЗ.

Проаналізувати для кожної вимоги повний перелік можливих обмежень з підготовленого набору й визначити, які саме з них можна застосовувати для певної вимоги. Тут надзвичайно зручно використовувати таблицю, де стовпці відповідають різним типам обмежень, а рядки - їхнім формулюванням. Якщо для вимоги потрібно додати обмеження певного типу, то у відповідній клітинці потрібно сформулювати це обмеження; якщо ж потреби в обмеженні взагалі немає, то у відповідній клітинці потрібно поставити "немає" (або N/A, Not Available).

3) Вибрати для кожного обмеження найпридатніший для нього шаблон і сформулювати вимогу за допомогою нього.

4) Завершити процес тоді, коли всі елементи таблиці заповнені.

Використання такого підходу для підготовки шаблонів вимог до ПЗ з обмеженнями дає змогу аналогічно відповісти на два традиційні запитання:

• Як формулювати вимогу з обмеженням? Відповідь: потрібно використовувати шаблони.

• Як переконатися в тому, що всі обмеження враховані? Відповідь: потрібно використовувати таблицю для аналізу покриття вимог з відповідними обмеженнями.

У табл. 3 показано приклад набору шаблонів для формулювання вимог до ПЗ з обмеженнями. Здебільшого, для одного типу обмежень можна використовувати різні шаблони, а самі обмеження можуть мати складну класифікацію. У наведених прикладах тільки текст, виділений жирним шрифтом, стосується безпосередньо самого обмеження.

Особливості деталізації вимог до ПЗ. Використання шаблонів для формулювання вимог до ПЗ дає змогу аналітикам звернути увагу на те, що деякі обмеження або показники продуктивності системи можна окремо сформулювати, тобто можуть існувати як окремі підпункти (підкласи) відповідних функціональних вимог. Це дає змогу виділяти ці підкласи у вигляді окремих вимог та встановлювати для них зв'язки з відповідними функціональними вимогами.

Однак, у допитливого читача може виникнути питання про ступінь (глибину) деталізації інформації. А саме, як саме ми збираємося "розщеплювати атом" під час розроблення вимог до ПЗ? На це запитання можна відповісти так: вимогу можна дробити на підпункти доти, доки засіб підтримки роботи з вимогами (англ. Requirements Management Tool) дає можливість аналітику бачити кожну вимогу в потрібному контексті.

На рис. 5 наведено спосіб поділу вимоги, за якого підпункти стають дочірніми елементами до основної вимоги, утворюючи в такий спосіб певну ієрархію. При цьому головна вимога до ПЗ залишається придатною для читання та розуміння сама по собі, водночас, як дочірні її елементи можна розглядати тільки стосовно "батьківської" вимоги, хоча при відстеженні та встановленні зв'язків вони можуть існувати повністю автономно.

Ґ > Телекомунікаційна система мас забезпечувати і телефонний зв'язок

ПЗ.

Якщо знову звернутися до прикладу, наведеного на рис. 4, виділивши курсивом текст батьківської вимоги в тексті дочірніх елементів, то отримаємо таке:

• телекомунікаційна система має забезпечувати телефонний зв'язок;

• телекомунікаційна система має забезпечувати телефонний зв'язок не менше, ніж з 10 абонентами;

• телекомунікаційна система має забезпечувати телефонний зв'язок, функціонуючи в умовах відсутності зовнішнього джерела електроживлення.

Існують різні способи організації ієрархії таких підкласів. Припустимо, що потрібно описати декілька різних можливостей, які мають бути доступні вимозі "функціонуючи в умовах відсутності зовнішнього джерела електроенергії". Варіант подання вимоги до ПЗ з її деталями подано на рис. 6.

Для цього прикладу взаємозв'язок між вимогами до ПЗ виглядатиме дещо інакше:

• функціонуючи в умовах відсутності зовнішнього джерела електроенергії, телекомунікаційна система має забезпечувати телефонний зв'язок;

• функціонуючи в умовах відсутності зовнішнього джерела електроенергії, телекомунікаційна система має забезпечувати телефонний зв'язок не менше, ніж з 10 абонентами;

• функціонуючи в умовах відсутності зовнішнього джерела електроенергії, телекомунікаційна система має забезпечувати радіозв'язок;

• функціонуючи в умовах відсутності зовнішнього джерела електроенергії, телекомунікаційна система має забезпечувати радіозв'язок не менше, ніж з 15 водіями швидкої допомоги.

Це означає, що суть такого способу деталізації вимог до ПЗ полягає в тому, що під час побудови ієрархії вимог до ПЗ (їх деталізації) батьківську вимогу потрібно формулювати так, щоб забезпечувати повний смисловий контекст для кожного дочірнього елемента, в т.ч. і можливу подальшу деталізацію дочірніх елементів на дещо дрібніші блоки інформації.

5. Критерії, яким має відповідати зміст сформульованих вимог до ПЗ

Незалежно від мовних особливостей процесу формулювання вимог до ПЗ, існують чіткі критерії, яким мають задовольняти зміст і якість сформульованої вимоги. До цих критеріїв належать такі:

• атомарність: кожне твердження (формулювання вимоги) має виглядати як один елемент ієрархії, придатний для встановлення зв'язків з ним;

• унікальність: кожна вимога має мати власну унікальну ідентифікацію;

• здійсненність: вимоги можна технічно реалізувати в установлені терміни і в межах виділеного бюджету;

• законність: кожна вимога немає суперечити чинному законодавству;

• зрозумілість: кожна вимога має бути дохідливо сформульована, має вилучати неоднозначне тлумачення;

• точність: кожна вимога має бути точною та лаконічною;

• можливість перевірки: для кожної конкретної вимоги має існувати прозорість її реалізації;

• абстрактність: формулювання вимоги немає нав'язувати певні технічні рішення, характерні для нижчих рівнів похідних вимог.

Додатково існують певні критерії, які можна застосовувати для формування наборів вимог до ПЗ:

• повнота: всі вимоги мають бути зафіксовані та згруповані у певні набори;

• несуперечність: немає існувати вимог, що суперечать одна іншій;

• відсутність надмірності: кожна вимога має бути сформульована тільки один раз (без дублювання), в якій немає уточнюватися повторно одна і та сама інформація;

• модульність: вимоги, близькі одна до іншої за змістом, мають міститися в одному наборі вимог;

• структурованість: наявність зрозумілої та чіткої структури документа для узгодження та затвердження вимог;

• задоволеність: досягнутий необхідний рівень покриття вимог зв'язками типу "задовольняється / задовольняє";

• тестованість: досягнутий необхідний рівень покриття вимог тестами.

Для демонстрації того, як не потрібно робити, нижче наведено два відомі приклади формулювання вимог згідно з розглянутими вище критеріями:

1) Система має забезпечувати максимальний рівень її продуктивності протягом всієї тривалості роботи, за винятком аварійних ситуацій, коли вона має забезпечувати рівень продуктивності до 125%, але тільки тоді, якщо аварійна ситуація триває не більше, ніж 15 хв, - в іншому випадку система має зменшити рівень продуктивності до 105%; але в разі, якщо вдається досягти рівня продуктивності тільки 95%, система має активувати режим "винятково малого рівня" і підтримувати цей рівень у межах 10% від початкового значення протягом 30 хв як мінімум.

2) Система має забезпечувати основні функції текстового редактора, зручні для використання ненавченим персоналом, і має працювати в умовах "тонкого" Et- hernet'а, прокладеного повітряною системою кабельних каналів з інтегрованими адаптерами, що поставляються з додатковими модулями пам'яті, за потреби.

Ці приклади демонструють класичні негативні ситуації, характерні для розробників вимог до ПЗ. Для того, щоб уникнути цих ситуацій, аналітику потрібно дотримуватися таких простих правил:

• уникати хаосу: формулюючи вимоги до ПЗ, потрібно сконцентрувати на найважливішому; вимога не має бути схожою на роман;

• уникати "лазівок": наприклад, таких виразів, як "якщо це потрібно", оскільки такі "дірки" роблять вимогу неоднозначною і часто марною;

• уникати розміщення понад однієї вимоги в одному розділі: часто наявність у одному пункті понад однієї вимоги легко визначити за наявності сполучника "і";

• уникати міркувань: здебільшого, роздуми мають свою певну схему і логічну структуру. Спочатку визначають головну думку, формують гіпотезу або тезу. Потім, щоб її підтвердити або спростувати, наведено доведення та аргументи. У підсумку кінцівка тексту має містити логічно обґрунтовані висновки;

• уникати використання "розмитих" понять і слів: природно, здебільшого, зазвичай, переважно, часто, інколи, нормально, типово, на загал;

• уникати використання невизначених термінів: наприклад, зручний у використанні, універсальний, гнучкий, очевидний;

* уникати прийняття бажаного за необхідне: наприклад, 100% надійний, приємний для всіх користувачів, безпечний у використанні, відповідний для всіх платформ, не мав би ніколи ламатися, мав би обробляти всі несподівані збої системи та бути готовим до модернізацій для будь-яких ситуацій, які можуть виникнути в майбутньому і т.д.

Аналіз першого прикладу показує, що замість однієї вимоги потрібно писати 12. Розвиваючи цю думку, найкраще виділити 4 окремих умови використання системи - нормальне, аварійне, аварійне понад 15 хв, режим "винятково малого рівня", - і описати окремі вимоги для кожного з цих умов. Варто звернути увагу на наявну лазівку в другому прикладі. Абсолютно незрозумілий обсяг вимоги. Наприклад, цю вимогу можна інтерпретувати й так: "Система має забезпечувати основні функції текстового редактора ... за потреби".

Однак, аналітикам-початківцям потрібно пам'ятати, що не існує досконалого та вивіреного способу написання ідеальних вимог, а кращий вчитель - це досвід, який вони напрацьовують протягом тривалого часу. Бездоганну документацію з якісними формулюваннями вимог до ПЗ відрізняє технічний стиль їх викладення та користувацька термінологія, а не комп'ютерний сленг. Водночас, як би не виглядав технологічний процес розроблення ПЗ, яким би змінам він не піддавався, певна методика структуризації вимог до ПЗ (як користувацьких, так і системних), конкретні мовні особливості їх формулювання та відповідне рецензування мають залишатися незмінними протягом усіх етапів реалізації програмного проекту.

Висновки

програмний забезпечення вимога

Встановлено мовні особливості процедури формулювання вимог до ПЗ, які є загальними для будь-якого процесу його розроблення, що дає змогу аналітику на підставі їхніх можливостей з'ясувати особливості розроблення структури відповідного документа та здійснити відбір ключових вимог з множини допустимих. За результатами дослідження можна зробити такі основні висновки. Проаналізовано основні можливості вимог до ПЗ та їхні атрибути, жорстко прив'язані до цих вимог, що допомогло зрозуміти суть пропонованих принципів формулювання вимог до ПЗ. З'ясовано особливості розроблення структури документа з вимогами до ПЗ та відбору ключових вимог, що дає змогу його виконавцям здійснити чітке викладення в ньому матеріалу й завершеність думки, логічну послідовність подання інформації, її цілісність й доступність, ясність для подальшого використання та сприйняття. Встановлено взаємопов'язаність та важливість вимог до ПЗ шляхом їх класифікації, фільтрування й сортування для того, щоб згодом отримати відносно невеликі набори вимог, кожен з яких стосується тільки однієї теми для подальшого їх аналізу.

1. Виявлено мовні особливості процедури формулювання вимог до ПЗ та уточнено деякі моменти підготовки відповідних шаблонів і їхньої деталізації, які сукупно ведуть до розроблення якісного ПЗ шляхом тісної співпраці бізнес-аналітика з його замовником, де вони встановлюють і записують відповідні домовленості.

Проаналізовано критерії, які потрібно використо¬вувати для визначення якості формулювання вимог до ПЗ, що дає змогу аналітику дотримуватися деяких простих правил при їх написанні.

2. Зроблено відповідні висновки та надано рекомен¬дації щодо практичного використання запропонованих методів і засобів формулювання якісних вимог до ПЗ.

Перелік використаних джерел

1.Berenbach, B., Paulish, D., Katzmeier, J., & Rudorfer, A. (2009). Software & Systems Requirements Engineering: In Practice. New York: McGraw-Hill Professional.

2.Dick, J., Hull, E., & Jackson, K. (2017). Requirements Engineering.

3.(4rd ed.) Springer. https://doi.org/10.1007/978-3-319-61073-3 Futrell, R. T., Shafer, D. F., & Shafer, L. I. (2002). Quality Software Project Management. Prentice Hall. 1639 p.

4.Hovorushchenko, T. O. (2018). Teoretychni ta prykladni zasady infor- matsiinoi tekhnolohii otsiniuvannia dostatnosti informatsii shchodo yakosti u spetsyfikatsiiakh vymoh do prohramnoho zabezpechen- nia. Abstract of Doctoral Dissertation for Technical Sciences (05.13.06 - Information technologies). Lviv: Ukrainska akademiia drukarstva. 43 p. [In Ukrainian].

5.Hrytsiuk, Yu. I. (2018). Analysis of Software Requirements: Tutorial.

Lviv: Publishing House of Lviv Polytechnic. 460 p. [In Ukrainian]. Hrytsiuk, Yu. I., & Leshkevych, I. F. (2017). The Problems of Definition and Analysis of Software Requirements. Scientific Bulletin of UNFU.

Размещено на Allbest.ru