На самом деле этот вопрос будет скорее интересен системным аналитикам, чем программистам.

Речь пойдет не о программировании, а о том, как делать постановки (технические задания) для программистов.

Хотя, если Вы программист и посчитаете информацию полезной, то конечно можете подсказать своему аналитику пару интересных идей. :-)

Итак, представьте, что Вам нужно написать техническое задание на программное обеспечение.

Как бы Вы это сделали? Наверняка начали бы описывать внутреннее устройство и функции системы, верно?

Да, в целом так. Но дьявол, как известно, скрывается в деталях…

Обычно ТЗ — это перечисление функций: система должна выполнять то…, система должна делать это…, должны быть обеспечены такие-то и такие-то характеристики…

Однако, давайте разберемся в сути. Что же такое Техническое задание на самом деле?..

Побыв немного аналитиком, представьте себя на минуту программистом, которому нужно запрограммировать очень простую вещь: открыть пустое окно по нажатию кнопки на экране:

image


Давайте зададимся вопросом: что именно здесь программирует программист?

Ответ очевиден: он программирует действие по открытию окна, т.е. реакцию системы на нажатие кнопки пользователем.

Это основной принцип. Что бы ни программировал программист, все его задачи можно свести к программированию реакции системы на действия пользователя.

Это могут быть не только нажатия на кнопки, но и ввод данных в текстовые поля, нажатия мышкой, выборы из списка и т.п.

Более того, к такой форме можно свести вообще любые задачи программиста, даже если речь идёт о программировании какого-то внутреннего модуля, например, запуск чего-либо роботом или обмен информацией с другими системами.

Т.е. получается, что если нужно дать задание программисту, то в техническом задании лучше всего перечислить:
  • все возможные действия пользователя с создаваемым интерфейсом и
  • реакцию системы не действия пользователя.

Как-то так.

Получается, что на самом деле программисты программируют интерфейс системы. И техническое задание по сути должно представлять из себя в первую очередь описание интерфейса.

Метод составления ТЗ на основе описания интерфейсов является основной сценариев использования (use cases), речь о которых обязательно пойдёт в других статьях.

Такой подход предложили в своё время классики теории Use Cases — Крэг Ларман и Алистер Коберн, труды которых стоят того, чтобы с ними ознакомиться.

Описывайте интерфейсы в своих ТЗ и делайте такие документы, за которые программисты будут Вам благодарны!
Вы пишете ТЗ с помощью Use Cases (сценариев использования)?

Проголосовало 115 человек. Воздержалось 100 человек.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Комментарии (20)


  1. mird
    11.09.2015 10:28
    +1

    Набор UseCase это несомненно важная часть тз, но далеко не единственная. Не менее важной частью (как минимум) является E-R диаграмма (диаграмма сущности-связи).А кроме того, в тз должны быть нефункциональные требования (например требования на отзывчивость системы), скетчи интерфейса, и т.п.


  1. Grox
    11.09.2015 10:33
    +2

    Получается, что на самом деле программисты программируют интерфейс системы. И техническое задание по сути должно представлять из себя в первую очередь описание интерфейса.

    Вы взяли какой-то узкий класс программистов. Есть ещё много тех, которые программируют участки, которые никак не связаны с интерфейсом системы или связаны весьма опосредовано. Это системные функции, библиотеки, драйвера и множество другого.


    1. Mrrl
      11.09.2015 10:49
      +1

      И библиотеки и драйверы тоже прекрасно вписываются в схему «все возможные действия пользователя с создаваемым интерфейсом и
      реакция системы на действия пользователя.» Только в роли пользователя там выступают другие части программы или даже железа. Но в целом — то же самое: запрос — ответ/реакция/встречный запрос.


      1. varenich
        11.09.2015 11:06

        Совершенно верно!


    1. kosmos89
      11.09.2015 13:27

      Интерфейсы бывают не только пользовательскими (*UI), но и программными (API).


      1. lair
        11.09.2015 15:40

        И какой, по-вашему, API у задачи, которая на верхнем уровне (а это именно то, что пишется в ТЗ) звучит как «каждый час должны экспортироваться данные туда-то»?


        1. kosmos89
          11.09.2015 16:06

          Это точно мне вопрос? Потому что я не понял, что в моем комментарии имеет отношение к тому, что вы спрашиваете.


          1. lair
            11.09.2015 16:12
            +1

            Да, вам. Из вашей фразы, что интерфейсы бывают не только пользовательскими, но и программными, я сделал вывод, что вы считаете, что программист всегда программирует интерфейс системы. Вот я и поинтересовался, какой интерфейс у описанной мной системы.

            Если я вас неправильно понял, то извините.


            1. varenich
              11.09.2015 16:18

              Это вопрос мне, наверное.

              Действующее лицо: робот
              Событие: срабатывание раз в час

              Основной сценарий:
              1.Робот запускает процедуру экспорта данных
              2.Система производит экспорт.

              Всё.

              Далее в разделе «Алгоритмы» можно уже более подробно описать алгоритм экспорта


              1. lair
                11.09.2015 18:07
                +2

                Наглядная демонстрация того, что это требование вырождено, в нем нет смысла. Намного проще написать функциональное требование «экспорт должен проводиться раз в час».


                1. varenich
                  11.09.2015 18:15

                  никакой вырожденности нет. всё по правилам

                  И смысл есть, т.к. такая форма представления чётко указывает на операцию, которую программист должен запрограммировать, а именно — экспорт.

                  ТЗ, в принципе, и пишутся для того, чтобы перечислить все операции, которые программистам нужно сделать, верно?


                  1. lair
                    11.09.2015 18:16
                    +2

                    И смысл есть, т.к. такая форма представления чётко указывает на операцию, которую программист должен запрограммировать, а именно — экспорт.

                    А кто будет программировать «робота», который запускает этот экспорт раз в час?

                    ТЗ, в принципе, и пишутся для того, чтобы перечислить все операции, которые программистам нужно сделать, верно?

                    Нет. ТЗ пишется для того, чтобы описать желаемую функциональность (и нефукциональные характеристики) системы.


  1. lair
    11.09.2015 10:36
    +4

    Что бы ни программировал программист, все его задачи можно свести к программированию реакции системы на действия пользователя.

    Либо вы бесконечно широко трактуете понятие «пользователь», либо это обобщение неверно. В частности, большую часть интеграционных задач так описывать неудобно.

    Да, несомненно, ощутимую часть требований можно (и нужно) выразить в сценариях использования, но есть требования, для которых это неоправданно.


  1. Greesha
    11.09.2015 12:42
    +2

    Usecase — это требования более высокого уровня, чем описание пользовательского интерфейса.

    Все руководства по разработке usecase рекомендуют избегать каких-либо предположений о реализации пользовательского интерфейса при описании сценариев. Хорошо написанный usecase может быть без реализован при выборе любого UI — например, и оконного, и консольного.


    1. Greesha
      11.09.2015 12:53

      Собственно Коберн пишет об этом совершенно недвусмысленно:

      <<Памятка 7. Не допускайте деталей графического интерфейса пользователя в варианте использования.

      Описывать движения пользователя при манипулировании интерфейсом в документе о требованиях не следует, так как:
      — Документ становится излишне длинным
      — Требования становятся неустойчивыми в том смысле, что небольшие изменения в проекте интерфейса вызывают изменения в «требованиях» (которые не были в чистом виде требованиями)
      — Это задача разработчика интерфейса пользователя, которому вы должны доверять как специалисту.>>


      1. varenich
        11.09.2015 13:38

        ну ок, давайте по-другому

        Что для вас является описанием интерфейса, а что нет?

        Это описание интерфейса?

        1.Система выводит список документов, каждый из которых представлен своим названием, номером, примечанием и датой регистрации.
        2.Пользователь ввод поисковую фразу
        3.Система отбирает подходящие документы и обновляет список
        4.Пользователь выбирает нужный документ


        1. Greesha
          11.09.2015 14:14

          Нет, это нормальный сценарий. Но пример в статье приведен совершенно противоположный (с кнопкой и окном).


          1. varenich
            11.09.2015 14:23
            -2

            Согласен, но суть-то в том, что как его не описывай, всё равно описывается действия пользователя с интерфейсом системы.
            Да, может уровнем чуток по-выше, без привязки к конкретным элементам экрана, но всё равно это интерфейс.


  1. richtrr
    12.09.2015 02:31

    Это основной принцип. Что бы ни программировал программист, все его задачи можно свести к программированию реакции системы на действия пользователя.

    Согласен. Но стоит заменить «пользователя» на внешнюю систему. И получится, что создается система, реагирующая на внешние события.
    А на её события тоже кто-то реагирует… Хм, программа не одинока в этом мрачном мире!


  1. Juster
    12.09.2015 19:45

    А если программирует демосцену?