Комментарии 20
Набор UseCase это несомненно важная часть тз, но далеко не единственная. Не менее важной частью (как минимум) является E-R диаграмма (диаграмма сущности-связи).А кроме того, в тз должны быть нефункциональные требования (например требования на отзывчивость системы), скетчи интерфейса, и т.п.
+1
Получается, что на самом деле программисты программируют интерфейс системы. И техническое задание по сути должно представлять из себя в первую очередь описание интерфейса.
Вы взяли какой-то узкий класс программистов. Есть ещё много тех, которые программируют участки, которые никак не связаны с интерфейсом системы или связаны весьма опосредовано. Это системные функции, библиотеки, драйвера и множество другого.
+2
И библиотеки и драйверы тоже прекрасно вписываются в схему «все возможные действия пользователя с создаваемым интерфейсом и
реакция системы на действия пользователя.» Только в роли пользователя там выступают другие части программы или даже железа. Но в целом — то же самое: запрос — ответ/реакция/встречный запрос.
реакция системы на действия пользователя.» Только в роли пользователя там выступают другие части программы или даже железа. Но в целом — то же самое: запрос — ответ/реакция/встречный запрос.
+1
Интерфейсы бывают не только пользовательскими (*UI), но и программными (API).
0
И какой, по-вашему, API у задачи, которая на верхнем уровне (а это именно то, что пишется в ТЗ) звучит как «каждый час должны экспортироваться данные туда-то»?
0
Это точно мне вопрос? Потому что я не понял, что в моем комментарии имеет отношение к тому, что вы спрашиваете.
0
Да, вам. Из вашей фразы, что интерфейсы бывают не только пользовательскими, но и программными, я сделал вывод, что вы считаете, что программист всегда программирует интерфейс системы. Вот я и поинтересовался, какой интерфейс у описанной мной системы.
Если я вас неправильно понял, то извините.
Если я вас неправильно понял, то извините.
+1
Это вопрос мне, наверное.
Действующее лицо: робот
Событие: срабатывание раз в час
Основной сценарий:
1.Робот запускает процедуру экспорта данных
2.Система производит экспорт.
Всё.
Далее в разделе «Алгоритмы» можно уже более подробно описать алгоритм экспорта
Действующее лицо: робот
Событие: срабатывание раз в час
Основной сценарий:
1.Робот запускает процедуру экспорта данных
2.Система производит экспорт.
Всё.
Далее в разделе «Алгоритмы» можно уже более подробно описать алгоритм экспорта
0
Наглядная демонстрация того, что это требование вырождено, в нем нет смысла. Намного проще написать функциональное требование «экспорт должен проводиться раз в час».
+2
никакой вырожденности нет. всё по правилам
И смысл есть, т.к. такая форма представления чётко указывает на операцию, которую программист должен запрограммировать, а именно — экспорт.
ТЗ, в принципе, и пишутся для того, чтобы перечислить все операции, которые программистам нужно сделать, верно?
И смысл есть, т.к. такая форма представления чётко указывает на операцию, которую программист должен запрограммировать, а именно — экспорт.
ТЗ, в принципе, и пишутся для того, чтобы перечислить все операции, которые программистам нужно сделать, верно?
0
И смысл есть, т.к. такая форма представления чётко указывает на операцию, которую программист должен запрограммировать, а именно — экспорт.
А кто будет программировать «робота», который запускает этот экспорт раз в час?
ТЗ, в принципе, и пишутся для того, чтобы перечислить все операции, которые программистам нужно сделать, верно?
Нет. ТЗ пишется для того, чтобы описать желаемую функциональность (и нефукциональные характеристики) системы.
+2
Что бы ни программировал программист, все его задачи можно свести к программированию реакции системы на действия пользователя.
Либо вы бесконечно широко трактуете понятие «пользователь», либо это обобщение неверно. В частности, большую часть интеграционных задач так описывать неудобно.
Да, несомненно, ощутимую часть требований можно (и нужно) выразить в сценариях использования, но есть требования, для которых это неоправданно.
+4
Usecase — это требования более высокого уровня, чем описание пользовательского интерфейса.
Все руководства по разработке usecase рекомендуют избегать каких-либо предположений о реализации пользовательского интерфейса при описании сценариев. Хорошо написанный usecase может быть без реализован при выборе любого UI — например, и оконного, и консольного.
Все руководства по разработке usecase рекомендуют избегать каких-либо предположений о реализации пользовательского интерфейса при описании сценариев. Хорошо написанный usecase может быть без реализован при выборе любого UI — например, и оконного, и консольного.
+2
Собственно Коберн пишет об этом совершенно недвусмысленно:
<<Памятка 7. Не допускайте деталей графического интерфейса пользователя в варианте использования.
…
Описывать движения пользователя при манипулировании интерфейсом в документе о требованиях не следует, так как:
— Документ становится излишне длинным
— Требования становятся неустойчивыми в том смысле, что небольшие изменения в проекте интерфейса вызывают изменения в «требованиях» (которые не были в чистом виде требованиями)
— Это задача разработчика интерфейса пользователя, которому вы должны доверять как специалисту.>>
<<Памятка 7. Не допускайте деталей графического интерфейса пользователя в варианте использования.
…
Описывать движения пользователя при манипулировании интерфейсом в документе о требованиях не следует, так как:
— Документ становится излишне длинным
— Требования становятся неустойчивыми в том смысле, что небольшие изменения в проекте интерфейса вызывают изменения в «требованиях» (которые не были в чистом виде требованиями)
— Это задача разработчика интерфейса пользователя, которому вы должны доверять как специалисту.>>
0
ну ок, давайте по-другому
Что для вас является описанием интерфейса, а что нет?
Это описание интерфейса?
1.Система выводит список документов, каждый из которых представлен своим названием, номером, примечанием и датой регистрации.
2.Пользователь ввод поисковую фразу
3.Система отбирает подходящие документы и обновляет список
4.Пользователь выбирает нужный документ
…
Что для вас является описанием интерфейса, а что нет?
Это описание интерфейса?
1.Система выводит список документов, каждый из которых представлен своим названием, номером, примечанием и датой регистрации.
2.Пользователь ввод поисковую фразу
3.Система отбирает подходящие документы и обновляет список
4.Пользователь выбирает нужный документ
…
0
Нет, это нормальный сценарий. Но пример в статье приведен совершенно противоположный (с кнопкой и окном).
0
Это основной принцип. Что бы ни программировал программист, все его задачи можно свести к программированию реакции системы на действия пользователя.
Согласен. Но стоит заменить «пользователя» на внешнюю систему. И получится, что создается система, реагирующая на внешние события.
А на её события тоже кто-то реагирует… Хм, программа не одинока в этом мрачном мире!
0
А если программирует демосцену?
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что программируют программисты?