Изменения

Есть идея, что системы сначала надо описывать как черный ящик, и способам такого описания посвящена инженерия требований. Цель - проверив систему на соответствие требованиям мы гарантируем гладкое внедрение. Проблема в том, что так - не работает. А значит, нет смысла чересчур углубляться в требования, а стоит быстро переходить к моделям системы, либо использовать легкие варианты фиксации требований. В докладе будет обзор разных подходов к написанию постановок: процедурный и объектный подходы, DDD, UseCase и UserStory, способы описания бизнес-архитектуры. Основой доклада послужили мои статьи [https://habr.com/ru/company/custis/blog/703758/ Какие нужны требования: развитие концепта], [https://habr.com/ru/company/custis/blog/705958/ Domain Driven Design: модели вместо требований],[https://habr.com/ru/company/custis/blog/709912/ Agile-методы: light-версии требований]. Материал был доработан при подготовке доклада. В том числе, появились слайды 28-30, описывающие особенности работы над постановками по замене основной информационной системы. Возможно, об этом я напишу отдельную статью. В 2017 на AnalystDays я делал доклад о сборке метода для написания постановок [[Как выбрать для проекта практики проектирования и работы с требованиями (Максим Цепков на AnalystDays-2017)|'''Как выбрать для проекта практики проектирования и работы с требованиями''']], но там содержание существенно отличалось: фокус был на том, на какие вопросы следует ответить и какие аспекты этого процесса рассмотреть, в то время как в этом докладе фокус - на различии разных методов и их назначение.