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