Вихідні критерії
Вирішено всі питання
Всі зміни внесені в документ чи інші відповідні продукти були внесені коректно.
Всі проблеми , помічені ТВД – вирішені, при цьому фіксувались дата,автор.
Документ був звірений з допомогою системного управління конфігурацією
Контрольний список дефектів.
Контрольний список дефектів, з допомогою варіантів використання
Чи є варіант використання автономною і окремою задачею
Чи чітко сформулювала мета для конкретного варіанту використання.
Чи зрозуміло, хто отримує переваги від цього варіанту використання.
Чи сформульований варіанту використання на базовому рівні
Чи всі альтернативні напрямки варіанту використання задокументовані
Чи задокументовані відомі умови виключення
Чи належним чином варіанту використання структурує вхідні і вихідні мови
Чи реалізований і піддається перевірці кожен визначений напрямок варіанту використання
Контрольний список дефектів для специфікації вимог
Організація і завершеність
Чи написані всі вимоги на одному і тому ж рівні деталізації
Чи конкретні всі внутрішні перехресні посилання
Чи забезпечують вимоги адекватну основу для проектування
Чи вказаний пріоритет реалізації кожної вимоги
Чи включені всі відомі потреби клієнта(системи)
Чи визначені всі зовнішні інтерфейси обладнання програмних продуктів і їх взаємодії
Чи задокументована очікувана поведінка системи для імовірних подій
Конкретність
Чи конфліктують певні вимоги між собою, або повторність їх
Чи написана кожна вимога зрозумілою точною і недвозначною мовою
Чи не виходять вимоги за границю проекту
Чи можна реалізувати всі вимоги ,не виходячи за рамки обмежень
Чи можна перевірити кожну вимогу з допомогою тестування ,огляду аналізів
Чи немає граматичних помилок
Чи всі повідомлення про помилки унікальні і зрозумілі
Атрибути якості
Чи всі завдання пов’язані з продуктивністю сформульовані належним чином
Чи всі задачі явно заду коментовані і оцінені з врахуванням прийнятих компромісів
Чи всі завдання , що стосуються безпеки сформульовані належним чином
Послідковуваність вимог
Чи кожна умова ідентифікована унікально і коректно
Чи послід кована кожна функціональна вимога до більш високого рівня
Особливі проблеми
Чи всі вимоги можна віднести власне до вимог,а не реалізації
Чи ідентифіковані всі функції , шо залежать від часу,чи визначені їх критерії
Чи були розглянуті належним чином потреби , пов’язані з інтернаціоналізацією
Проблеми:
Великий об’єм документації
*виділити обсяг підвищеного ризику та мало пріоритетності
Велика команда експертів
*переконатись , що кожен учасник знає свою область роботи
Взаємозв’язок вимог з іншими етапами проекту
Планування проекту
Проектування і кодування
Основна версія
вимог
Тестування
Планування проекту
Використання вимог для оцінки масштабу проекту
Оновлення планів при зміні вимог
Врахування пріоритетів вимог , при плануванні ітерації
Проектування і кодування
Врахування атрибутів якості при проектуванню архітектури
Розподіл вимог за компонентами
Відслідковування вимог до дизайну і коду
Тестування
Використання вимог при тестуванні системи
Розробка приймальних тестів
Відслідковування вимог до тестів
Необхідні елементи для ефективного планування проекту
Оцінка розміру проекту
Інформація про продуктивність спеціалістів
Вимоги з прийнятим рівнем стабільності
Емпіричний досвід менеджера
Фактор успіху на етапі планування
Переконатись , що в проект включені всі функціональні вимоги , не містить зайвого
Переконатись, що в проекті враховані всі виключення/включення.
Переконатись , що проект відповідає зданим критеріям продуктивності,стійкості,безпеки.
Надійна структура архітектури компонентів
Оцінка виконання планований потоків або розміщення функціональності в паралельних процесах
20.12.2012
Зв'язок вимог із тестування
Використання:
При тестуванні, для пошуку дефектів
Експертиза(перевірка коду на відповідність вимог)
Демонстрація (підтвердження роботоздатності продукту )
Аналіз(обговорення того, що с-ма має працювати при певних вимогах)
Принципи і вимоги при управлінні вимогами
Етапи управління вимогами
Управління
вимогами
Управління змінами |
Контроль версій |
Контроль стану вимог |
Управління (конк.) вимог |
1.Пропозиція змін 2.Аналіз вимог змін 3.Затв. рішен. 4.Оновлення документ вимог 5.Оновлення планів Оцінка змін вимог |
|
1.Визначення можливих станів вимог 2.Фіксування стану окремих вимог 3.Звіт розп. статусу вимог |
1.Визначення звязку із іншими вимогами 2. Визначення звязку вимог з іншими елемент. системи |
Базова версія вимог – набір функціон і нефункціональних вимог, які розробник зобовязан. Реалізувати в певній вибраній версії вимог.
Кожну вимогу необхідно вносити через процес внесення вимог(змін у вимоги)
Процедури визначення вимог(її управління):
Інструкція управління змінами та схеми управління
Як склад. Версія вимог
Статус вимог
Особи, які мають прово змін статусу вимог
Способи зміни вимог та їх обробки
Методи аналізу впливу пропон. Зміни
Контроль версій
Системи версійного контролю
.
Атрибути вимог:
Дата створення вимог
N:поточних версій вимог
Автор вимог
Особа відповідальна за втілення вимог
Стан вимог
Джерело вимог
Підсистема для якої призначені вимоги
Номер версії продукту для якого вона призначена
Критерії тестування прийнятності
Приорітет реалізації
Стабільність – показн. Зміни вимвимоги у майбутьньому
Контроль статусу вимог
Назва стану |
Рекомендовані стани вимог опису |
Propos(Запропонов.) |
Вимоги запропоновані авторизованим джерелом |
Appruved(Схвалена) |
Вимоги проаналізовані в базовій версії певного релізу |
Implemented(Реалізована) |
Код, що реал. Вимогу протестований. Вимога відслідкована |
Poven(Перевірена) |
Конкретна функц. Реалізована вимоги підтверджено у реальному продукті |
DeletedВидалена) |
Стосується ……. Вимоги. Запис хто видалив і чому |
Beqected(Відхил.) |
Вимога запропонована але не запланована для реалізації. У майбутніх версіях. Назва причини |
27.12.2012