Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: Elder от 03 Декабря 2012, 16:27:19
-
Господа и дамы, очень интересует как вы совмещаете варианты использования и функциональные требования для проектируемой системы. Я все никак не могу определиться, стоит ли в ТЗ включать и полный набор функциональных требований и все ВИ. Или, например, проработать функциональные требования верхнего уровня, а конкретизировать все с помощью ВИ или все описать в виде ВИ. Что можете посоветовать из своего опыта? Для каких систем, какой метод лучше, как считает? Надеюсь, что корректно выразил свою мысль.
-
включать в ТЗ ВИ не имеет смысла. ВИ - это способ реализации, а ТЗ - набор требований. Требовать надо не столько КАК должно быть сделано, а ЧТО должно быть сделано. По большому счету система для заказчика представляет собой "черный ящик", ему не очень важно, что внутри...
К тому же в случае изменения требований будете и ВИ переписывать?
Плюс к этому, не забывайте о необходимости проверять соответствие требованиям (ПМИ и т.п.).
-
включать в ТЗ ВИ не имеет смысла. ВИ - это способ реализации, а ТЗ - набор требований. Требовать надо не столько КАК должно быть сделано, а ЧТО должно быть сделано. По большому счету система для заказчика представляет собой "черный ящик", ему не очень важно, что внутри...
К тому же в случае изменения требований будете и ВИ переписывать?
Плюс к этому, не забывайте о необходимости проверять соответствие требованиям (ПМИ и т.п.).
Благодарю за ваше мнение. Но тогда у меня возникает вопрос: получается, что ВИ я создаю для выявления и конкретизации функциональных требований, так? И дальше (если требования составлены без ошибок), созданные ВИ остаются не нужными, за исключением использования их для тест кейсов или просмотра их программистами ?
-
Давайте возьмём 2 верхних уровня функциональных требований (без технических):
1. Бизнес-требования: «Система должна позволять отправлять почтовые сообщения» — этот уровень лучше описывается атомарными и группированными требованиями такого рода. Эти требования можно хранить в концепции и ТЗ.
2. Требования/решения пользовательского уровня: «Система должна позволять выбирать адресатов письма из адресной книги», «Система должна сообщать о факте успешной отправки письма» можно хранить атомарно, а лучше в способах применения. Эти требования можно документально хранить в приложении к ТЗ или уже в ТП.
-
получается, что ВИ я создаю для выявления и конкретизации функциональных требований, так? И дальше (если требования составлены без ошибок), созданные ВИ остаются не нужными, за исключением использования их для тест кейсов или просмотра их программистами ?
IMHO Вы неверно понимаете суть ВИ. ВИ - это способ реализации требования, т.е. своего рода проектное решение верхнего уровня (с точки зрения использования программы). Для реализации одного и того же требования разные проектные группы могли бы придумать и реализовать разные ВИ, решающие одну и ту же задачу.
Таким образом, в ходе разработки ВИ не выкидываются, а "прорабатываются вглубь". На основе некоторых (или даже многих) ВИ действительно можно разрабатывать тест кейсы, но это не означает, что все тест кейсы должны разрабатываться только на основе ВИ. И вообще-то тесты лучше разрабатывать не программистам-разработчикам системы, а специализирующимся на тестировании тестировщикам (в старых книжках, типа PeopleWare, упоминается т.н. "Черная команда").
-
Давайте возьмём 2 верхних уровня функциональных требований (без технических):
1. Бизнес-требования: «Система должна позволять отправлять почтовые сообщения» — этот уровень лучше описывается атомарными и группированными требованиями такого рода. Эти требования можно хранить в концепции и ТЗ.
2. Требования/решения пользовательского уровня: «Система должна позволять выбирать адресатов письма из адресной книги», «Система должна сообщать о факте успешной отправки письма» можно хранить атомарно, а лучше в способах применения. Эти требования можно документально хранить в приложении к ТЗ или уже в ТП.
Спасибо, что откликнулись. Под "способами применения" вы понимаете варианты использования? и по пункту № 2, то есть в ТЗ должено существовать функциональное требование «Система должна позволять выбирать адресатов письма из адресной книги» и параллельно с ним, в отдельном файле может быть ВИ «Выбор адресатов». ВИ обязательно нужно согласовывать с заказчиком ?
-
IMHO Вы неверно понимаете суть ВИ. ВИ - это способ реализации требования, т.е. своего рода проектное решение верхнего уровня (с точки зрения использования программы). Для реализации одного и того же требования разные проектные группы могли бы придумать и реализовать разные ВИ, решающие одну и ту же задачу.
Таким образом, в ходе разработки ВИ не выкидываются, а "прорабатываются вглубь". На основе некоторых (или даже многих) ВИ действительно можно разрабатывать тест кейсы, но это не означает, что все тест кейсы должны разрабатываться только на основе ВИ. И вообще-то тесты лучше разрабатывать не программистам-разработчикам системы, а специализирующимся на тестировании тестировщикам (в старых книжках, типа PeopleWare, упоминается т.н. "Черная команда").
Но ВИ нужно тоже согласовывать с заказчиком, ведь это отличный способ показать как система будет работать, а не просто требование, что должно быть. И как я понимаю, все ВИ можно складировать в отдельные текстовые документы, группируя в папки (по актору, подсистеме или по др. атрибутам) ?
-
В книге "Путь аналитика", насколько я помню, предлагается способ:
1. Высокоуровневые требования.
2. Варианты использования, поясняющие эти требования.
Именно по такому принципу я в последнее время и формирую спецификации.
-
В книге "Путь аналитика", насколько я помню, предлагается способ:
1. Высокоуровневые требования.
2. Варианты использования, поясняющие эти требования.
Именно по такому принципу я в последнее время и формирую спецификации.
Да, тоже это читал, но не представляю как это уложить в ТЗ.
-
Но ВИ нужно тоже согласовывать с заказчиком, ведь это отличный способ показать как система будет работать, а не просто требование, что должно быть. И как я понимаю, все ВИ можно складировать в отдельные текстовые документы, группируя в папки (по актору, подсистеме или по др. атрибутам) ?
Еще раз говорю, не нужно смешивать (и путать!) требования и ВИ: первое определяет ЧТО должно быть сделано, второе - КАК, т.е. придуманный разработчиком способ работы с программной - проектное решение, определенная новизна, вот эту новизну и нужно согласовывать с тем, кто потом будет с этим работать. Довольно подробно этот аспект описан у Леффингуэлла сотоварищи.
а оформлять... да как хотите, так и оформляйте... Важно, чтобы это было удобно и понятно и заказчику, и исполнителю. Цель ведь не наплодить документов, а внятно описать все существенные аспекты разработки. Содержание первично - форма вторична. Хорошая структура = хороший инструмент.
-
Спасибо, что откликнулись. Под "способами применения" вы понимаете варианты использования?
Да
и по пункту № 2, то есть в ТЗ должено существовать функциональное требование «Система должна позволять выбирать адресатов письма из адресной книги» и параллельно с ним, в отдельном файле может быть ВИ «Выбор адресатов».
Да, в ТЗ можно указать ФТ «Выбор адресатов из адресной книги», вот только выявлять его, как вы правильно писали раньше, удобнее через разработку набора способов применения, относящихся к фиче «Отправка писем». Например, через разработку способа применения «Отправить письмо».
«Выбор адресатов» — это вообще не ВИ, это его шаг. Способ применения — это, ради чего происходит сеанс работы в системе.
ВИ обязательно нужно согласовывать с заказчиком ?
В общем случае да, но обычно он делегирует эту функцию своим экспертам.
-
Спасибо, что откликнулись. Под "способами применения" вы понимаете варианты использования?
Да
Цитировать
и по пункту № 2, то есть в ТЗ должено существовать функциональное требование «Система должна позволять выбирать адресатов письма из адресной книги» и параллельно с ним, в отдельном файле может быть ВИ «Выбор адресатов».
Да, в ТЗ можно указать ФТ «Выбор адресатов из адресной книги», вот только выявлять его, как вы правильно писали раньше, удобнее через разработку набора способов применения, относящихся к фиче «Отправка писем». Например, через разработку способа применения «Отправить письмо».
«Выбор адресатов» — это вообще не ВИ, это его шаг. Способ применения — это, ради чего происходит сеанс работы в системе.
Цитировать
ВИ обязательно нужно согласовывать с заказчиком ?
В общем случае да, но обычно он делегирует эту функцию своим экспертам.
Спасибо за исчерпывающие ответы! Теперь все устаканилось.