Опис вимог до програмного забезпечення (SRD)
Вступ
Призначення, мета
<Визначити продукт, вимоги до якого описані в цьому документі. Описати межі продукту, зокрема, якщо цей документ описує лише частину системи чи окрему підсистему.>
1.2 Продукти-аналоги (при наявності таких)
<Навести у вигляді таблиці порівняння результати аналізу основних функціональних і нефункціональних характеристик продуктів-аналогів. Можна включати зразки користувацьких інтерфейсів та посилання на Web адреси.>
Загальний опис
Характеристики продукту
<Резюмувати основні характеристики продукту або істотні функції, які він здійснює чи дозволяє здійснювати користувачу. Деталі представляються в Розділі 3, тому тут потрібне узагальнення вищого рівня. Ефективним є представлення основних груп пов’язаних вимог і їхніх зв’язків діаграмами варіантів використання.>
2.2 Класи користувачів та їх характеристики
<Визначити різні класи користувачів, які будуть використовувати продукт. Класи користувачів можуть бути диференційовані базуючись на частоті використання, підмножині функцій продукту, яка використовується, технічній експертизі, рівнях безпеки чи привілеїв, рівню освіти чи досвіду. Описати доцільні характеристики кожного класу користувачів. Відділити пріоритетні класи користувачів від тих, що є менш важливими.>
2.3 Середовище функціонування
<Описати середовище в якому буде функціонувати продукт, включаючи апаратну платформу, операційну систему, їі версії, і будь-які інші програмні компоненти чи аплікації, з якими воно має коректно співіснувати.>
Характеристики системи
<Ця частина ілюструє організацію функціональних вимог до продукту через характеристики системи, основні сервіси, які надає продукт. Цей розділ можна представити варіантами використання, режимами операцій, користувацькими класами, , чи їх комбінації, залежно від того, що найбільш логічно для продукту.>
Характеристика системи 1
<Не записуйте “Характеристика системи 1”. Задавайте конкретну, змістовну назву характеристики кількома словами.>
3.1.1 Опис і пріоритет
<Надайте короткий опис характеристики і відзначте, якого вона пріоритету Високого, Середнього, чи Низького.>
3.1.2 Послідовності дія/відгук
<Список послідовностей дій користувача і відгуків системи, що спричиняють режим визначений для цієї характеристики. Це відповідає елементам діалогу асоційованим з варіантами використання.>
3.1.3 Функціональні вимоги
<Перелічити детальні функціональні вимоги асоційовані із цією характеристикою. Це можливості продукту, які мають бути реалізовані, щоб користувач скористався сервісами чи виконав варіант використання. Включаючи, як продукт повинен реагувати на помилкові умови чи неправильні введення. Вимоги мають бути короткими, повними, недвозначними, верифіковуваними, і необхідними.>
<Кожна вимога має бути унікально ідентифікована номером чи значущою міткою певного виду, наприклад
REQ-1.1:
REQ-1.2: .>
3.2 Характеристика системи 2 (і т.д.)
4. Вимоги зовнішніх інтерфейсів
4.1 Користувацькі інтерфейси (при потребі)
<Описати логічні характеритики кожного інтерфейсу між ПЗ та користувачами. Може включати зразки зображень екрану.>
4.2 Апаратні інтерфейси (при потребі)
<Описати логічні та фізичні характеристики кожного інтерфейсу між ПЗ та апаратними компонентами системи. Може включати типи підтримуваних пристроїв, природу даних і керуючих взаємодій між ПЗ та апаратними засобами і комунікаційні протоколи, які будуть використані.>
4.3 Програмні інтерфейси (при потребі)
<Описати зв’язок між продуктом і іншими специфічними програмними компонентами (назва і версія), включаючи бази даних, операційні системи, інструменти, бібліотеки і інтегровані комерційні компоненти. Визначити дані і повідомлення, які поступають в систему і виходять з неї і описати мету кожної.>
4.4 Комунікаційні інтерфейси (при потребі)
<Описати вимоги, що пов’язані з комунікаційними функціями, необхідними цьому продукту, зокрема, електронна пошта, веб броузер, мережеві протоколи, електронні форми і т.п. Визначити прийнятні формати повідомлень. Визначити комунікаційні протоколи, які будуть використовуватись, такі як FTP чи HTTP. Визначити безпеку комунікацій чи питання шифрування, швидкість передачі даних, і механізми синхронізації.>
5. Інші нефункційні вимоги
5.1 Вимоги продуктивності
<Якщо є вимоги продуктивності до продукту в різних середовищах, описати їх та пояснити. Визначити часові залежності для систем реального часу. Описати такі вимоги настільки точно, як це можливо.>
Вимоги безпеки
<Визначити вимоги, що стосуються безпеки чи питань секретності, щодо використання продукту чи захисту даних, які використовуються чи створюються. Визначити вимоги аутентифікації користувачів.>
5.3 Атрибути якості програмного продукту
<Визначити додаткові якісні характеристики до продукту, які будуть важливими для замовників чи розробників. Зокрема, це може бути: адаптовуваність, придатність, коректність, гнучкість, функціональна сумісність, супроводжуваність, портативність, надійність, стійкість, тестопридатність та зручність використання.>
6. Інші вимоги
<Визначити інші вимоги, що не розкриті в SRS. Це може включати вимоги бази даних, вимоги інтернаціоналізації, юридичні вимоги і т.п.>
Додаток Б. Рекомендації до створення звіту про тестування
1. Вступ.
2. Розробка тестів (які види тестування використовувались, які були розроблені тестові випадки).
2.1. Функціональні тести.
2.2. GUI тести.
2.3. Тести на безпеку.
…
2.N. Тестування продуктивності.
3. Функціональне тестування.
3.1. Пройдені тести, їх результат.
3.2. Не пройдені тести.
4. GUI тестування.
…
N-2.Тестування продуктивності.
N-1.Метрики (покриття програмних вимог тестами).
N. Критерій прийняття/відхилення релізу.
2. Розробка тестів. Під час фази розробки тестових випадків було спроектовано тести для функціонального тестування, тестування безпеки чи GUI тестування та сценарії для тестування продуктивності (або вказати інші види тестів, які використовувалися). Кожен тестовий випадок містить детальні кроки, тестові дані і очікувані результати.
2.1. Функціональні тестові випадки. Під час фази розробки тестів було спроектовано 34 функціональні тестові випадки. Таблиця показує розподіл функціональних тестових випадків і наборів тестових даних для цих випадків за варіантами використання.
| Варіанти використання | Тестові випадки | Тестові дані |
| Setup Account | ||
| Trade Securities | ||
| View Performance | ||
| Edit Security | ||
| Edit Trader Account | ||
| View System Reports | ||
| Загалом |
Додаток 2 «Специфікація тестів для функціонального тестування» містить деталі функціональних тестових випадків.
| # | Тестові випадки | Тестові дані |
| 1. | Verify Image And Text | |
| 2. | Verify Sort Order Fields | |
| 3. | Verify Scrolling | |
| 4. | Verify Required Fields | |
| 5. | Verify Max Length In Edit Fields | |
| 6. | Verify Links | |
| 7. | Verify Default Values In Fields | |
| 8. | Verify Data Validation In Edit Fields | |
| 9. | Verify Buttons | |
| 10. | Verify Confirmation Message | |
| 11. | Verify UI Skin-ability | |
| Загалом |
2.2. GUI тестові випадки. Було розроблено 11 GUI тестових випадків. Нижче наведена таблиця показує список GUI тестових випадків з кількістю наборів тестових даних для кожного тестового випадку.
Додаток 3 «Специфікація тестів для GUI тестування» містить детальні GUI тестові випадки.
…
2.n. Аналогічний опис тестових випадків для інших видів тестування
3. Функціональне тестування
Результати тестування
Результати функціонального тестування наведено в додатку Результати виконання функціонального тестування .
Підсумок тестування
33 тести з 34 функціональних тестів наведених в Додатку2 «Специфікація тестів для функціонального тестування» пройшли успішно (169 із 170 множин тестових даних пройшли), отже функціональне тестування розглядається як частково успішне – 97% тестових випадків пройшли, 99.94% наборів тестових даних пройшли.
Відомі дефекти
Дефект #1
Коли адміністратор редагує профіль користувача система не інформує адміністратора, що користувач в даний момент залогований.
Опис:
Відповідно до тестового випадку Edit Trader Account (UTASK10298) система повинна інформувати адміністратора, що користувач в даний момент залогований, якщо адміністратор намагається редагувати профіль користувача.
Дефект полягає в тому, що система не інформує адміністратора про те, що користувач залогований. Адміністратор може змінювати профіль користувача у той час коли користувач залогований у систему.
Подолання дефекту:
Цей дефект неможливо виправити без шкоди для WEB сервера системи. Проблема полягає в тому, що доступ до контейнера сесії є обмеженим і небезпечним.
GUI тестування
Результати тестування
Результати GUI тестування представлені у додатку Результати виконання GUI тестування.
Підсумок тестування
10 з 11 GUI тестів наведених у Додатку Test Design Specification GUI Testing.doc [3] пройшли успішно (324 із 327 наборів тестових даних пройшли), отже GUI тестування можна розглядати як частково успішне- 90.9% тестових випадків пройшли успішно, 99.1% наборів тестових даних пройшли.
Відомі дефекти
Дефект #2
Каристувач не може переміщувати вказівник прокрутки на сторінці Портфоліо користувача. Цей дефект проявляється лише в оглядачі FireFox.
Опис:
Каристувач не може переміщувати вказівник прокрутки на сторінці Портфоліо користувача. Вказівник прокрутки можна перемітити лише з допомогою стрілок прокрутки. Цей дефект проявляється лише в оглядачі FireFox.
Подолання дефекту:
Це дефект FireFox v x.x: вказівник прокрутки фрейму об’єкта втрачає фокус.
Критерій успіх/провал проекту
Умови тестування, які визнавалися успішними були наступні:
Розробка тестів:
· Всі заплановані тестові випадки розроблено;
· Покриття тестами програмних вимог досягає 100%;
· Покриття тестами варіантів використання досягає 100%;
Тестування:
· Всі розроблені тестові випадки виконано;
· Виконано тестування продуктивності, вимоги продуктивності задоволено;
· Всі внутрішні дефекти виправлені і виправлення підтверджено.
Всі наведені умови задоволено, проект вважається успішним.
Додаток В. План забезпечення якості програмного продукту
SQAP включає розділи, відповідно до стандарту IEEE 730 Standard for Software Quality Assurance Plans (Стандарт планування забезпечення якості ПЗ - IEEE 730). Розділи повинні бути впорядковані в описаній послідовності. Якщо немає інформації, що відноситься до розділу, то нижче заголовку розділу потрібно вказати: "Цей розділ не відповідає даному плану", разом з відповідними причинами виключення.
SQAP складається з наступних пунктів:
1. Мета.
2. Управління.
3. Документація.
4. Стандарти, практики, узгодження і метрики.
5. Тестування.
6. Звіти про помилки та коригувальні дії.
7. Засоби, методи та методології.
8. Медіа-контроль.
9. Контроль постачання.
10. Збір, підтримка і зберігання обліку.
11. Навчання.
12. Управління ризиками.
Деякі матеріали можуть бути наведені в інших документах. В такому випадку посилання на ці документи повинні бути присутні в SQAP.
4.1. (Нумерацію ставити згідно диплому) Мета (розділ 1 SQAP)
Цей розділ повинен визначати конкретні цілі та границі окремого SQAP. Тут наводиться перелік програмних засобів, які охоплюються SQAP, і плановане використання програмного забезпечення. Для кожної одиниці програмного забезпечення повинен бути наведений опис життєвого циклу, який охоплюється SQAP.
4.2. Управління (розділ 2 SQAP)
Цей розділ описує структуру організації проекту, її завдання, ролі та обов'язки (див. IEEE Std 1058 ™ -1998 [B13]).
4.2.1. Організація
Цей розділ описує організаційну структуру, яка контролює і забезпечує якість програмного забезпечення. Повинен бути наведений опис кожного з основних елементів організації разом з ролями і делегованими повноваженнями. Рівень організаційної свободи і об'єктивність оцінки та контролю якості програмного забезпечення, повинні бути чітко описані і задокументовані. Крім того, повинні бути ідентифіковані організації, відповідальні за підготовку і підтримку SQAP.
Завдання
У цьому розділі наводиться опис:
1. Етапів життєвого циклу програмного забезпечення, охоплених SQAP.
2. Завдань, що мають бути виконані.
3. Вхідних і вихідних критеріїв для кожного завдання.
4. Взаємозв’язків між цими завданнями і планованих основних контрольних точок. Також повинні бути вказані послідовність завдань та їх зв'язок з графіком проекту.
4.2.3. Ролі та обов'язки
Цей розділ має визначити конкретні організаційні елементи, які є відповідальними за виконання кожного завдання.
4.2.4. Оцінка ресурсів, необхідних для забезпечення якості.
Цей розділ передбачає оцінку ресурсів і витрат, які будуть витрачені на забезпечення якості і завдання контролю якості.
4.3. Документація (розділ 3 SQAP)
Мета
Цей розділ повинен виконувати наступні функції:
а) Визначити документацію для регулювання розробки, контролю та перевірки, використання та технічного обслуговування програмного забезпечення.
б) Описати документи, які повинні бути розглянуті і перевірені на відповідність. Для кожного документа в списку, визначити перегляди і аудити, які будуть проводитися, і критерії, за якими відповідність повинна бути підтверджена.
4.3.2. Мінімальні вимоги до документації
Опис мінімальних вимог до написання документів, метою яких є перевірка того, що реалізація програмного забезпечення задовольняє технічні вимоги.
Опис вимог до програмного забезпечення (SRD)
SRD повинен визначати вимоги для конкретного програмного продукту, програми або набору програм, які виконують певні функції в конкретному середовищі. SRD може бути записаний постачальником (внутрішнім або зовнішнім), замовником, або обома. У SRD слід розглянути основні питання функціональності, зовнішні інтерфейси, продуктивність, атрибутів та обмежень на реалізацію. Кожна вимога повинна бути однозначно ідентифікована та визначена так, що її задоволення здатне бути об'єктивно перевіреним і підтвердженим (див. IEEE Std 830 ™ -1998 [В5]).