Важнейшей задачей в разработке является четко сформулированная структура. Если не умеешь четко сформулировать структуру для документа о концепции и границах, тогда пришел по адресу.
Важность разработки требований мы разбирали на примере данной статьи, кто не читал, то рекомендую в первую очередь её прочитать, а затем вернуться сюда, тогда будет более понятен смысл того, что здесь описывается.
Сложность объяснения такой важной темы, как разработка требований, а в частности подход к разработке документа о концепции и границах, является очень высокой, если осуществлять объяснение в режиме абстрактного проекта. Чтобы этого избежать и погрузить вас в настоящую среду разработки требований, то необходимо столкнуться с настоящим проектом.
Параллельно данному циклу статей, начат другой цикл, который предполагает создание телеграм-бота на базе гугл таблиц. Естественно, при разработке требований вам в первую очередь необходимо погрузиться в контекст проблемы, а значит прочитать данную статью, чтобы двигаться дальше. Да, я понимаю, что отправил читать уже две разные статьи, но суть системного аналитика в первую очередь связана с изучением источников, поэтому нужно быть готовым кропотливо читать, изучать и задавать вопросы, а затем искать на них ответы.
Получилось слишком длинное вступление… Все, начинаем.
Что такое документ о концепции и границах? Понятно, что границы говорят нам о том, какой охват у разрабатываемого приложения и за что выходить не стоит. Другими словами границы показывают нам, где нужно остановиться.
А что такое концепция? Фактически в данном документе подразумевается фиксирование всех требований, которые касаются идеи разработки ПО.
Документ о концепции и границах можно оформлять по своему, но есть устоявшаяся структура, из которой вы можете убирать лишнее, что вам не пригодится в рамках текущего проекта.
В рамках рассматриваемого проекта нам точно не понадобится вся структура и мы будем от неё отказываться.
Будем двигаться поэтапно, в первую очередь сделаем так, чтобы в нашем документе появилась исходная информация о проекте. Невозможно двигаться в сторону решения проблемы, если мы даже не описали исходную позицию, в которой находится компания (заказчик).
Видно, что при заполнении исходных данных мы упираемся в недостающую информацию. Именно поэтому заполнение исходных данных так важно, оно позволяет определить все точки требующие дополнительного уточнения.
Ни при каких условиях нельзя оставлять такие участки. Их необходимо обязательно пометить комментарием ТДУ - требует дополнительного уточнения. Эти комментарии будут требовать от вас постоянного уточнения от клиента до тех пор, пока кнопка “Решено” на комментарии не будет нажата. А нажать вы её можете лишь в том случае, если посчитаете, что уточнять больше нечего.
Заполнение исходных данных должно быть максимально детализированным. Важно не пропускать нюансов, они важнее всего. Поэтому продолжаем заполнять исходные данные.
Как видите в нашем описании исходных данных и в фактических сведениях есть ряд недопониманий, которые мы обязаны пометить комментарием ТДУ.
Исходя из этого, вы должны понимать, что все эти ТДУ предполагают глубокое общение с заказчиком, выяснение и определение его действительных потребностей. Вам стоит понимать, что клиенты никогда не знают, что именно они хотят. В их представлении идеальным вариантом является ваше решение, на базе которого они будут критиковать те или иные нюансы. Поэтому для каждого ТДУ вам необходимо расписать четко сформулированный вопрос или же список последовательных вопросов, которые приведут клиента к точному набору требований.
Однако вам стоит запомнить, что любое упущение в подразделе исходные данные будет критическим в дальнейшей разработке требований.
Давайте подведем итог по тому, каков принцип работы с заполнением информации об исходных данных:
- нельзя писать о проблеме;
- пишем только о том, что есть у заказчика в рамках задачи на данный момент;
- выявляем каждый нюанс связанный с задачей;
- ничего не предполагаем, все данные, которые противоречивы или недостаточны, должны быть помечены комментарием ТДУ и определены при тесном взаимодействии с клиентом;
- рисуем схемы, визуализируем пояснения, делаем скрины - данный документ пишется для всех, кто будет участвовать в разработке. В первую очередь для клиента, а он должен будет читать данный документ и давать свои комментарии по нему. Клиенты понимают глазами и не вникают в тонкости кодирования, поэтому чем больше визуальной части, тем лучше между вами контакт и взаимопонимание.
Таким образом, пункт 1.1 мы завершили. В рамках данной задачи нет смыслы в описании пункта 1.2. Возможности бизнеса. Слишком узкая задача.
Далее перейдем к бизнес-проблеме и бизнес-цели. Но это сделаем в следующей статье.
Подписывайся, чтобы ничего не пропустить. Ставь лайк, если заинтересовала статья и пиши комментарии, если хочешь что-то спросить или чем-то поделиться.
