Задание
Выберите какой-нибудь рабочий документ, который актуален для вас. Попробуйте определить, является ли содержащаяся на нём информация только эпистемой, или какой-то специальной эпистемой (описанием, моделью), или частично тем, частично другим, самостоятельно. Запишите свою догадку.
Решение V1
Выбираю рабочий документ - high level requirements to new Liveness service.
Итак, чтобы корректно решить поставленную задачу, сделаем небольшой рекап того, что такое эпистема, описание и модель.
Эпистема - любое знание о мире, любой его кусочек.
Описание - детальное изложение знания о мире. Правда, какой уровень детализации требуется – не очень понятно.
Описание рассказывает как устроена та или иная система, какой объем работ включен в проект Х и так далее.
Модель: ссылается на объекты; позволяет предсказывать поведение описываемых объектов.
Документ описывающий новый Liveness сервис не является эпистемой, потому что он достаточно детально описывает (1) потребности бизнеса, ввиду которых требуется создание нового сервиса, (2) приводит рассуждения (но не обязывает) о том, как сервис должен быть устроен внутри, (3) описывает ключевые шаги процесса прохождения Liveness, (4) описывает виды атак, к которым процесс должен быть устойчив.
Документ последовательно отвечает на вопросы ЗАЧЕМ выполнять работы и КАК примерно выполнять ее. Подобный уровень детализации выше, чем полагается у эпистемы (хотя у меня нет точного критерия разделения).
Документ не является моделью, потому что по нему невозможно предсказать поведение описываемых объектов.
Решение V2
Далее в руководстве я нашел уточненное определение понятия описание.
Если вы натыкаетесь на слово «описание», значит, имеется в виду, что:
- вы отсылаете к каким-то конкретным объектам/described_entity,
- описанным с какой-то определённой точки зрения/viewpoint,
- в определённом контексте/bounded context,
- и можете проверить, что описание соответствует описываемым объектам в нужные моменты времени.
Отсылаюсь ли я к каким-то конкретными объектам?
Да, отсылаюсь к будущему (еще не построенному) сервису поддерживающему процесс прохождения Liveness верификации.
С какой точки зрения создано описание?
- Viewpoint 1 - Я говорю - нужно решить бизнес задачу уйти от вендор-лока, то есть чтобы компания перестала зависеть от одного единственного поставщика сервиса. Роль - ? не знаю как назвать. Стратег? Нет. …. затрудняюсь здесь
- Viewpoint 2 - Нужно чтобы переход на нового вендора не занимал много времени - здесь я переживаю о будущем бюджете. Роль? Финансист?
- Viewpoint 3 - Нужно чтобы процесс был устойчив к фроду. Здесь мой интерес- чтобы фродеры не могли взломать процесс верификации, тем самым образом получив несанкционированный доступ к какому-либо ресурсу. Роль - специалист безопасности?
Описание определённом контексте/bounded context?
Да, контекст Liveness вверификации.
Могу проверить, что описание соответствует описываемым объектам в нужные моменты времени?
Да, смогу, сейчас система в стадии разработки. Описания (код) упоминаемых объектов - создается.
Итого вывод V2 - документ является описанием.
Обсуждение с LLM усиленной FPF
LLM согласна, что документ является описанием.
Но, судя по всему, в FPF другой набор типов эпистем, а именно (1) интенция, (2) описание - мы здесь, (3) спецификация.
Окей, несколько другая терминология, чем в руководств.
А также из интересного с LLM
LLM утверждает, что для того, чтобы мое описание стало спецификацией, необходимо переписать текст
в логические пред- и постусловия, оперирующие строго типизированными переменными, которые система сможет проверить
Пример:
Было (уровень F2-F3, описание): Вендор должен поддерживать сравнение двух переданных изображений: одного из документа клиента, а другого — из live-сессии.
Стало (уровень F4, предикаты первого порядка): Мы переписываем текст в логические пред- и постусловия, оперирующие строго типизированными переменными, которые система сможет проверить.
∀ v ∈ LivenessVendors, ∀ req ∈ FaceCompareRequest:admissible(req) ↔ hasImage(req.docImage) ∧ hasMedia(req.liveMedia)execute(v, req) → result ∈ {Match, NoMatch, Unknown}
Интересный результат.
Значит ли это, что требования нужно писать в таком виде? Не думаю.
Но может быть такой уровень описания требований есть необходимый промежуточный уровень между человеко-читаемым текстом (мой вариант) и будущим исходным кодом? То есть, если строить AI-based конвеер продуктовой разработки, то должен быть уровень описаний как этот, и отдельный агент, создающий вот такие опсиания?
Припаркую эту мысль.