На самом деле этот вопрос будет скорее интересен системным аналитикам, чем программистам.
Речь пойдет не о программировании, а о том, как делать постановки (технические задания) для программистов.
Хотя, если Вы программист и посчитаете информацию полезной, то конечно можете подсказать своему аналитику пару интересных идей. :-)
Итак, представьте, что Вам нужно написать техническое задание на программное обеспечение.
Как бы Вы это сделали? Наверняка начали бы описывать внутреннее устройство и функции системы, верно?
Да, в целом так. Но дьявол, как известно, скрывается в деталях…
Обычно ТЗ — это перечисление функций: система должна выполнять то…, система должна делать это…, должны быть обеспечены такие-то и такие-то характеристики…
Однако, давайте разберемся в сути. Что же такое Техническое задание на самом деле?..
Побыв немного аналитиком, представьте себя на минуту программистом, которому нужно запрограммировать очень простую вещь: открыть пустое окно по нажатию кнопки на экране:
Давайте зададимся вопросом: что именно здесь программирует программист?
Ответ очевиден: он программирует действие по открытию окна, т.е. реакцию системы на нажатие кнопки пользователем.
Это основной принцип. Что бы ни программировал программист, все его задачи можно свести к программированию реакции системы на действия пользователя.
Это могут быть не только нажатия на кнопки, но и ввод данных в текстовые поля, нажатия мышкой, выборы из списка и т.п.
Более того, к такой форме можно свести вообще любые задачи программиста, даже если речь идёт о программировании какого-то внутреннего модуля, например, запуск чего-либо роботом или обмен информацией с другими системами.
Т.е. получается, что если нужно дать задание программисту, то в техническом задании лучше всего перечислить:
Как-то так.
Получается, что на самом деле программисты программируют интерфейс системы. И техническое задание по сути должно представлять из себя в первую очередь описание интерфейса.
Метод составления ТЗ на основе описания интерфейсов является основной сценариев использования (use cases), речь о которых обязательно пойдёт в других статьях.
Такой подход предложили в своё время классики теории Use Cases — Крэг Ларман и Алистер Коберн, труды которых стоят того, чтобы с ними ознакомиться.
Описывайте интерфейсы в своих ТЗ и делайте такие документы, за которые программисты будут Вам благодарны!
Речь пойдет не о программировании, а о том, как делать постановки (технические задания) для программистов.
Хотя, если Вы программист и посчитаете информацию полезной, то конечно можете подсказать своему аналитику пару интересных идей. :-)
Итак, представьте, что Вам нужно написать техническое задание на программное обеспечение.
Как бы Вы это сделали? Наверняка начали бы описывать внутреннее устройство и функции системы, верно?
Да, в целом так. Но дьявол, как известно, скрывается в деталях…
Обычно ТЗ — это перечисление функций: система должна выполнять то…, система должна делать это…, должны быть обеспечены такие-то и такие-то характеристики…
Однако, давайте разберемся в сути. Что же такое Техническое задание на самом деле?..
Побыв немного аналитиком, представьте себя на минуту программистом, которому нужно запрограммировать очень простую вещь: открыть пустое окно по нажатию кнопки на экране:
Давайте зададимся вопросом: что именно здесь программирует программист?
Ответ очевиден: он программирует действие по открытию окна, т.е. реакцию системы на нажатие кнопки пользователем.
Это основной принцип. Что бы ни программировал программист, все его задачи можно свести к программированию реакции системы на действия пользователя.
Это могут быть не только нажатия на кнопки, но и ввод данных в текстовые поля, нажатия мышкой, выборы из списка и т.п.
Более того, к такой форме можно свести вообще любые задачи программиста, даже если речь идёт о программировании какого-то внутреннего модуля, например, запуск чего-либо роботом или обмен информацией с другими системами.
Т.е. получается, что если нужно дать задание программисту, то в техническом задании лучше всего перечислить:
- все возможные действия пользователя с создаваемым интерфейсом и
- реакцию системы не действия пользователя.
Как-то так.
Получается, что на самом деле программисты программируют интерфейс системы. И техническое задание по сути должно представлять из себя в первую очередь описание интерфейса.
Метод составления ТЗ на основе описания интерфейсов является основной сценариев использования (use cases), речь о которых обязательно пойдёт в других статьях.
Такой подход предложили в своё время классики теории Use Cases — Крэг Ларман и Алистер Коберн, труды которых стоят того, чтобы с ними ознакомиться.
Описывайте интерфейсы в своих ТЗ и делайте такие документы, за которые программисты будут Вам благодарны!
Only registered users can participate in poll. Log in, please.
Вы пишете ТЗ с помощью Use Cases (сценариев использования)?
33.06% да40
66.94% нет81
121 users voted. 106 users abstained.