Главная страница Случайная страница
Разделы сайта
АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника
Формулировка замечаний к требованиям
|
|
Формулировка вопросов
По результатам предварительного ознакомления с материалами и анализа выступления докладчиков экспертами были сформулированы следующие вопросы.
1.1. Как устроена расчётная система, позволяющая определять время выполнения работ заказа?
1.2. Кто из акторов отвечает за ведение справочника работ?
1.3. Сколько заказов в среднем проходит в день по мастерской?
1.4. Каков механизм передачи информации от менеджера к мастеру?
1.5. Каков горизонт планирования?
Общая оценка требований
Для удобства оперирования с требованиями все они были сведены в таблицу 1.
Введена следующая типизация требования (поле «тип»):
§ UC – функциональное, в форме прецедента;
§ F – функциональное;
§ U – нефункциональное (применимость);
§ R – нефункциональное (надёжность);
§ P – нефункциональное (производительность);
§ S – нефункциональное (пригодность к эксплуатации).
§ O –прочее.
Количественное оценивание требований
Свойства требований были оценены по количественной шкале [0, 1]: 0 – очень низкое качество; 1 – очень высокое качество. Для свойств полноты и ясности шкала – дробная, для свойств корректности и верифицируемости – бинарная (0 или 1). В результирующей таблице для каждого из свойств представлены 4 оценки.
Табл. 1. Реестр требований; количественная оценка
| Код | Наименование | Тип | Полнота | Ясность | Коррект-ность | Верифици-руемость |
| M1 | Регистрация заказа | UC | 0, 3 | 0, 7 | ||
| M2 | Изменение заказа | UC | 0, 5 | 0, 6 | ||
| M3 | Удаление заказа. | UC | 0, 4 | 0, 6 | ||
| M4 | Запрос о заказе | UC | 0, 6 | 0, 8 | ||
| D1 | Планирование нового заказа | UC | 0, 6 | 0, 8 | ||
| D2 | Коррекция плана | UC | 0, 4 | 0, 6 | ||
| D3 | Планирование срочного заказа | UC | 0, 5 | 0, 7 | ||
| С1 | Назначение исполнителей | UC | 0, 7 | 0, 9 | ||
| С1 | Фиксация результатов | UC | 0, 5 | 0, 6 | ||
| F1 | Авторизация и аутентификация пользователей в системе | F | 0, 8 | 0, 9 | ||
| F2 | Ведение справочника ресурсов | F | 0, 4 | 0, 5 | ||
| U1 | Удобство использования | U | 0, 8 | |||
| U2 | Помощь в режиме online | U | 0, 6 | 0, 7 | ||
| R1 | Доступность | R | 0, 8 | 0, 9 | ||
| P1 | Одновременно работающие пользователи | P | 0, 5 | 0, 6 | ||
| P2 | Время отклика | P | 0, 6 | 0, 7 | ||
| S1 | Масштабируемость | S | 0, 4 | 0, 5 | ||
| S2 | Обновление версий | S | 0, 8 | 0, 9 | ||
| X1 | Требования к СУБД и доступу к данным | O |
Формулировка замечаний к требованиям
Для всех требований, количественная оценка которых составила менее 0, 5, подготовлены замечания.
2.2.1. M1. Полнота. Выбранная степень подробности оставляет открытыми ряд вопросов, основной из которых – как осуществляется расчёт времени работ заказа.
2.2.2. D1. Корректность. Требование сформулировано не вполне корректно, т.к. фраза «доступны только совместимые ресурсы» не подкрепляется механизмом определения совместимости ресурсов нигде по тексту.
2.2.3 D3. Ясность. Требования сформулированы не до конца, не четко, т.к. фраза «выполнить в ближайшее время» не подкрепляется четкой датой исполнения.
2.2.4 M3. Верифицируемость. Доказательство с помощью формальных методов правильности или неправильности требовании к системе в соответствии с формальным описанием свойств системы.
Оценка вариантов использования
Все требования, представленные в форме вариантов использования, были оценены по ряду параметров:
§ автономность и законченность;
§ наличие цели (измеримого значения);
§ правильный выбор уровня абстракции;
§ полнота описания альтернативных сценариев;
§ полнота описания нефункциональных требований;
§ структурированность.
|
|