Меню

Як перевірити специфікацію вимог до програмного забезпечення (SRS)?

how test software requirements specification

Спробуйте Наш Інструмент Для Усунення Проблем

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

У цій статті про специфікацію вимог до програмного забезпечення (SRS) зазначено, що вимоги повинні бути чіткими, конкретними, вимірюваними та повними без суперечностей.

Краще вловити неоднозначності вимог і виправити їх у самому життєвому циклі раннього розвитку.

Як перевірити специфікацію вимог до програмного забезпечення (SRS) _

Вартість виправлення помилки після завершення розробки або випуску продукту занадто висока. Тому важливо провести аналіз вимог та вловити ці неправильні вимоги до специфікацій проектування та етапів реалізації проекту SDLC.

Що ви дізнаєтесь:

Як виміряти функціональні документи SRS?

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

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

найкраще програмне забезпечення для створення ігор для початківців

Як ви заморозите Вимогу в цьому випадку?

Якими будуть ваші критерії задоволення вимог? Щоб отримати відповідь, поставте це питання зацікавленим сторонам: Скільки часу на відгук для вас нормально? Якщо вони скажуть, ми приймемо відповідь, якщо це буде протягом 2 секунд, тоді це ваша міра вимог. Заморозьте цю вимогу і виконайте ту ж процедуру для наступної вимоги.

тестувати засоби управління даними з відкритим кодом -

Ми щойно дізналися, як виміряти вимоги та заморозити їх на етапах проектування, впровадження та тестування.

Давайте візьмемо ще один приклад: Я працював над веб-проектом. Клієнт (зацікавлені сторони) вказав вимоги проекту на початковій фазі розробки проекту. Мій менеджер розповсюдив усі вимоги в команді для перевірки. Коли ми розпочали обговорення цих вимог, ми були просто вражені!

Кожен мав своє власне уявлення про вимоги. Ми виявили багато неоднозначностей у термінах, зазначених у документах вимог, які згодом були надіслані клієнту для ознайомлення.

Клієнт використовував багато неоднозначних термінів, що мали багато різних значень, що ускладнювало нам аналіз точного значення. Наступна версія документа вимоги від клієнта була досить зрозумілою, щоб замерти на етапі проектування.

З цього прикладу ми дізналися, що 'Вимоги повинні бути чіткими та послідовними'

Наступним критерієм для тестування специфікації вимог є 'Відкрийте відсутні вимоги', давайте подивимось на це.

Дізнайтесь про відсутні вимоги

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

Специфікації повинні містити обидва типи вимог, тобто те, що система повинна робити, а що не повинна.

Як правило, я використовую свій власний метод, щоб розкрити невизначені вимоги. Коли я читаю Документ специфікації вимог до програмного забезпечення (SRS) , Я зазначаю своє власне розуміння зазначених вимог, а також інші вимоги, які повинен охоплювати документ ЄСВ.

Це допомагає мені задавати запитання щодо невизначених вимог, тим самим пояснюючи це.

Для перевірки повноти вимог розділіть вимоги на три розділи, вимоги „Повинен реалізувати”, вимоги, які не вказані, але „передбачувані”, і третій тип - „вимоги”. Перевірте, чи всі типи вимог розглянуті до етапу проектування програмного забезпечення.

Перевірте, чи вимоги пов’язані з ціллю проекту

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

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

Але як вирішити, чи відповідні вимоги чи ні?

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

гарнітура віртуальної реальності для xbox one -

Коротше кажучи, документ 'Специфікація вимог' (SRS) повинен містити таке:

  • Функціональність проекту (Що слід робити, а чого не робити).
  • Програмне забезпечення, апаратні інтерфейси та інтерфейс користувача.
  • Критерії коректності системи, безпеки та продуктивності.
  • Проблеми впровадження (ризики), якщо такі є.

Висновок

Я охопив майже всі аспекти вимірювання потреб. Щоб бути конкретнішим щодо вимог, я резюмую тестування вимог одним реченням:

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

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

Чи маєте ви досвід у тестуванні вимог до програмного забезпечення?

Будь ласка, не соромтеся поділитися ними в коментарях нижче.

Рекомендована література

^