Данная статья относится к циклу статей по разработке требований. Если ты сразу попал на неё и не читал предыдущие, то конечно же тебе необходимо вначале прочитать статьи начиная с первой. Не переживай в конце каждой статьи есть ссылка на следующую, поэтому в итоге ты вернешься к этой статье.
Те кто прочитал все предыдущие статьи ─ начинаем.
Мы подошли ко второму разделу “Рамки и ограничения”. Напомню, мы разрабатываем документ о концепции и границах. В прошлой статье мы закончили описание концепции, теперь пришла пора обозначить границы проекта.
Да, в рамках данного проекта может показаться, что все границы ясны. Однако попрошу вас вспомнить, что когда мы подготавливали техническую часть по регистрации, мы представляли себе немного по другому границы этого проекта. Думаю каждый из вас имел в тот момент свое представление и перспективы развития этого проекта.
Постепенно заполняя каждый раздел этого документа мы видим, что границы все расширяются и расширяются. Могу сказать с абсолютной точностью, что границы проекта могут расширяться бесконечно, если их не зафиксировать. А как их фиксировать? Конечно же подписанием оговоренных границ. А что подписывать? Конечно же документ и повторюсь, этот документ называется о концепции и границах. Именно поэтому он такой большой, т.к. необходимо зафиксировать все детали до начала разработки.
Первая и наверное фундаментальная часть, которая показывает настоящие границы проекта - это диаграмма потоков данных, в частности контекстная. Почему контекстная? Просто потому, что она одна из немногих диаграмм, способных показать абсолютно всех внешних участников, которые будут взаимодействовать с подсистемой (в нашем случае с телеграм ботом) и отправлять ей данные.
Начинаем конечно же с объяснения всем читателям, что это такое и как с этим работать.
Обратите внимание, что необходимо указывать ссылки на рисунки. Читатель должен четко понимать на что именно он должен обращать внимание, даже учитывая факт того, что рисунок идет следом за текстом. Рисунок естественно нумеруем и даём ему название.
В любой схеме обязательно должна присутствовать легенда. Нельзя просто так взять и оставить маркировку цветов стрелок на додумывание читателем. Он в результате может так додумать, что все ваши задумки будут восприняты наоборот. Поэтому детализируйте, подсказывайте и описывайте.
Просто давать контекстную диаграмму нельзя, она лишь визуальная часть для понимания. Но заключительной частью должно быть четкое пояснение каждой сущности.
На схеме сущности могут располагаться по определенным вами правилам, но последовательность их объяснения должна отражать последовательность работы с подсистемой. Следовательно, дальше описываем сущность Сотрудники.
Важно понимать один ключевой момент: в диаграмме вы не можете отражать развернутые пояснения, поэтому подписи потоков данных приходится писать лаконично. Однако, информативность таких строк не всегда понятна читателю документу, в частности заказчику нужно будет разжёвывать это каждый раз, когда он будет обращаться к этой диаграмме.
Поэтому, в описании каждой сущности необходимо не просто переписывать подписи потоков данных, а разворачивать их смысл, т.е. объяснять что там подразумевается.
В потоках данных относительно разрабатываемой подсистемы могут участвовать не только пользователи системы, но и другие информационные системы. Поэтому стоит подчеркнуть, что в контекстной диаграмме отражаются абсолютно все её участники. Тем более в данном проекте Google таблица играет роль хранилища данных.
Описание контекстной диаграммы является 50% успехом описания границ проекта. Я думаю и так видно из просмотренного материала, что диаграмма четко обозначила все границы и никакие дополнительные идеи о добавлении еще одной или нескольких сущностей не возникают. А происходит это потому, что контекстная диаграмма является полной. Именно этот момент важен в её построении. Продумывайте все возможные потоки, которые исходят из сущностей.
Не смотрите, что в данной диаграмме используется по две стрелки из каждой сущности. Просто сам проект небольшой. В больших разрабатываемых подсистемах потоки данных могут занимать гораздо больше одной или двух стрелок. Продумывайте и показывайте данную диаграмму всем участникам разработки проекта, каждый должен внести свой комментарий. Чем больше читают этот документ, тем лучше он становится.
На сегодня все, в следующей статье будем делать декомпозицию процессов контекстной диаграммы. Подпишись 🙏 на канал, чтобы ничего не пропустить.