Уровни требований:
· Бизнес-требования . Определяются целями и политикой организации их высказывают те, кто финансирует проект
· Требования пользователей . Определяют цели и задачи, которые позволит решить система, или что пользователи смогут делать с помощью системы.
· Системные требования . Определяют функциональность и характеристики системы, которую должны построить разработчики, для того чтобы пользователи смогли выполнить свои задачи. (Описание железа, описание системы и т.д.)
У каждого уровня есть функциональный и нефункциональный вид
Виды требований
· Функциональные требования определяют функции, которые выполняет система, и зависит от потребностей пользователей и типа решаемой задачи.
· Нефункциональные требования определяют характеристики и ограничения системы и не связаны непосредственно с функциональными требованиями
Нефункциональные требования:
Производительность
Требования к производительности определяют насколько быстро и качественно система должна выполнить определенные функции. Они определяют время отклика, пропускную способность и т.д.
Надежность и доступность
Надежность – это вероятность работы системы без сбоев в течение определённого времени
Безопасность
Это требования связаны с блокировкой неавторизованного доступа к данным и функциям системы, предотвращением потерь информации и т.п.
Легкость сопровождения и эксплуатации
Этот атрибут определяет насколько просто и удобно модифицировать продукт и исправлять найденные в ней ошибки. Он важен для продуктов, которые подвергаются частым изменениям.
Мобильность
Этот атрибут определяет усилия, необходимые для перенесения продукта из одной операционной среды в другую.
Повторное использование
Затраты на разработку повторно используемых компонент сравнительно велики, но эффект их использования в дальнейшем может компенсировать эти затраты. Для минимализации затрат в требованиях необходимо перечислить элементы проекта, которые должны быть спроектированы так, чтобы упростить их повторное использование.
Тестируемость
Этот атрибут показывает легкость, с которой компоненты проекта и комплексный продукт могут быть проверены на наличие ошибок.
Требования к требованиям:
1. Корректность
Бывает, что в требованиях допускают ошибки при составлении
2. Недвусмысленность
Точность формулировки в требованиях может по разному интерпретироваться тестировщиками, разработчиками и другими участниками проекта
3. Полнота
Часто в требованиях забывают описать валидации на поля или единицы измерения, в каких будет показываться значения или даже целые секции, которые могут быть пропущены по невнимательности
4. Непротиворечивость
Одна часть требований может гласить что на какое то действие нужно выполнять то-то, в тоже время как в другой части требования можно найти что та же самая функциональность должна выполнять что то другое.
5. Упорядоченность по важности и стабильности
В хороших требованиях можно увидеть как заказчик, клиенты или другие заинтересованные лица упорядочили требования по их важности и стабильности.
6. Поддаваемость проверки
Требования должны быть составлены таким образом, чтобы тестировщики буквально черпали от туда тест кейсы, на каждый хороший пункт из требований обычно можно написать несколько тест кейсов которые покроют данный пункт требований
7. Модифицируемость
Требования должны быть хорошо организованны и иметь прекрасные ссылки, разбиение. В больших системах, приложениях требования могут быть поддерживаемы с помощью автоматизируемого средства и легко модифицируемы