Две концепции валидации и верификации часто путают. Кроме того, проверку системных требований часто путают с проверкой самой системы.
Предлагаю разобраться в этом вопросе.
В статье «Моделирование объекта в целом и как композиции» Я рассмотрел два подхода к моделированию объекта: как целого и как структуры.
В данной статье нам понадобится это разделение.
Пусть у нас есть спроектированный функциональный объект. Рассмотрим этот объект как часть проектирования другого функционального Объекта.
Пусть существует описание конструкции Объекта, такое, что оно содержит описание объекта.
В таком описании объект имеет описание в целом, то есть описываются его интерфейсы взаимодействия с другими объектами в рамках проектирования Объекта.
Пусть дано описание объекта как структуры.
Пусть имеется информационный объект, содержащий требования к оформлению описания объекта как структуры.
Пусть имеется совокупность знаний, содержащая правила вывода, на основе которых из описания объекта в целом получается описание объекта как структуры.
Совокупность знаний – это то, чему дизайнеров учат в институтах – очень-очень много знаний.
Они позволяют на основе знаний об объекте спроектировать его структуру.
Итак, мы можем начать.
Мы можем утверждать, что если правильно описан объект в целом, правильна совокупность знаний и соблюдены правила вывода, то результирующее описание конструкции объекта будет правильным.
То есть на основе этого описания будет построен функциональный объект, соответствующий реальным условиям эксплуатации.
Какие риски могут возникнуть: 1. Использование неверных знаний об Объекте.
Модель Объекта в головах людей может не соответствовать действительности.
Например, они не знали о реальной опасности землетрясений.
Соответственно, требования к объекту могут быть сформулированы неверно.
2. Неполная запись знаний об Объекте – что-то упущено, допущены ошибки.
Например, знали о ветрах, но забыли о них упомянуть.
Это может привести к недостаточно полному описанию требований к объекту.
3. Неправильный багаж знаний.
Нас учили ставить массу выше других параметров, а оказалось, что надо увеличивать скорость.
4. Неверное применение правил вывода к описанию объекта.
Логические ошибки, чего-то не хватает в требованиях к проектированию объекта, нарушено отслеживание требований.
5. Неполная запись результатов проектирования системы.
Всё учли, всё рассчитали, но записать забыли.
6. Созданная система не соответствует описанию.
Понятно, что все артефакты проекта появляются, как правило, в законченном виде только ближе к концу проекта, да и то не всегда.
Но, если предположить, что развитие водопадное, то риски такие, как я описал.
Проверка каждого риска — это определенная операция, которой можно дать название.
Если кому интересно, можете попробовать придумать и озвучить эти термины.
Что такое проверка? По-русски верификация — это проверка на соблюдение правил.
Правила оформляются в виде документа.
То есть должен быть документ с требованиями к документации.
Если документация соответствует требованиям данного документа, то она прошла проверку.
Что такое валидация? В русском языке валидация — это проверка правильности выводов.
То есть должен существовать совокупность знаний, описывающая, как получить описание конструкции на основе данных об объекте.
Проверка правильности применения этих выводов и есть валидация.
Валидация включает проверку описания на последовательность, полноту и понятность.
Валидацию требований часто путают с проверкой продукта, созданного на основе этих требований.
Тебе не следует этого делать.
Теги: #анализ требований #валидация #верификация #тестирование ИТ-систем
-
Короткие Имена
19 Oct, 24 -
Об Агрессивном Офисе
19 Oct, 24 -
Рулетка С Шансом На Успех
19 Oct, 24 -
Воспоминания Бумера - Vax/Vms
19 Oct, 24
