Использование ВИ и функциональных требований вместе/раздельно или как?(Прочитано 14302 раз)
Господа и дамы, очень интересует как вы совмещаете варианты использования и функциональные требования для проектируемой системы. Я все никак не могу определиться, стоит ли в ТЗ включать и полный набор функциональных требований и все ВИ. Или, например, проработать функциональные требования верхнего уровня, а конкретизировать все с помощью ВИ или все описать в виде ВИ. Что можете посоветовать из своего опыта? Для каких систем, какой метод лучше, как считает? Надеюсь, что корректно выразил свою мысль.



включать в ТЗ ВИ не имеет смысла. ВИ - это способ реализации, а ТЗ - набор требований. Требовать надо не столько КАК должно быть сделано, а ЧТО должно быть сделано. По большому счету система для заказчика представляет собой "черный ящик", ему не очень важно, что внутри...
К тому же в случае изменения требований будете и ВИ переписывать?
Плюс к этому, не забывайте о необходимости проверять соответствие требованиям (ПМИ и т.п.).
Лью воду...



включать в ТЗ ВИ не имеет смысла. ВИ - это способ реализации, а ТЗ - набор требований. Требовать надо не столько КАК должно быть сделано, а ЧТО должно быть сделано. По большому счету система для заказчика представляет собой "черный ящик", ему не очень важно, что внутри...
К тому же в случае изменения требований будете и ВИ переписывать?
Плюс к этому, не забывайте о необходимости проверять соответствие требованиям (ПМИ и т.п.).
Благодарю за ваше мнение. Но тогда у меня возникает вопрос: получается, что ВИ я создаю для выявления и конкретизации функциональных требований, так? И дальше (если требования составлены без ошибок), созданные ВИ остаются не нужными, за исключением использования их для тест кейсов или просмотра их программистами ?



Давайте возьмём 2 верхних уровня функциональных требований (без технических):

1. Бизнес-требования: «Система должна позволять отправлять почтовые сообщения» — этот уровень лучше описывается атомарными и группированными требованиями такого рода. Эти требования можно хранить в концепции и ТЗ.

2. Требования/решения пользовательского уровня: «Система должна позволять выбирать адресатов письма из адресной книги», «Система должна сообщать о факте успешной отправки письма» можно хранить атомарно, а лучше в способах применения. Эти требования можно документально хранить в приложении к ТЗ или уже в ТП.



Цитата: skillu
получается, что ВИ я создаю для выявления и конкретизации функциональных требований, так? И дальше (если требования составлены без ошибок), созданные ВИ остаются не нужными, за исключением использования их для тест кейсов или просмотра их программистами ?

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

Таким образом, в ходе разработки ВИ не выкидываются, а "прорабатываются вглубь". На основе некоторых (или даже многих) ВИ действительно можно разрабатывать тест кейсы, но это не означает, что все тест кейсы должны разрабатываться только на основе ВИ. И вообще-то тесты лучше разрабатывать не программистам-разработчикам системы, а специализирующимся на тестировании тестировщикам (в старых книжках, типа PeopleWare, упоминается т.н. "Черная команда").
« Последнее редактирование: 04 Декабря 2012, 00:06:26 от Водолей »
Лью воду...



Давайте возьмём 2 верхних уровня функциональных требований (без технических):

1. Бизнес-требования: «Система должна позволять отправлять почтовые сообщения» — этот уровень лучше описывается атомарными и группированными требованиями такого рода. Эти требования можно хранить в концепции и ТЗ.

2. Требования/решения пользовательского уровня: «Система должна позволять выбирать адресатов письма из адресной книги», «Система должна сообщать о факте успешной отправки письма» можно хранить атомарно, а лучше в способах применения. Эти требования можно документально хранить в приложении к ТЗ или уже в ТП.
Спасибо, что откликнулись. Под "способами применения" вы понимаете варианты использования?  и по пункту № 2, то есть в ТЗ должено существовать функциональное требование «Система должна позволять выбирать адресатов письма из адресной книги» и параллельно с ним, в отдельном файле может быть ВИ «Выбор адресатов». ВИ обязательно нужно согласовывать с заказчиком ?



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

Таким образом, в ходе разработки ВИ не выкидываются, а "прорабатываются вглубь". На основе некоторых (или даже многих) ВИ действительно можно разрабатывать тест кейсы, но это не означает, что все тест кейсы должны разрабатываться только на основе ВИ. И вообще-то тесты лучше разрабатывать не программистам-разработчикам системы, а специализирующимся на тестировании тестировщикам (в старых книжках, типа PeopleWare, упоминается т.н. "Черная команда").

Но ВИ нужно тоже согласовывать с заказчиком, ведь это отличный способ показать как система будет работать, а не просто требование, что должно быть. И как я понимаю, все ВИ можно складировать в отдельные текстовые документы, группируя в папки (по актору, подсистеме или по др. атрибутам) ?



В книге "Путь аналитика", насколько я помню, предлагается способ:

1. Высокоуровневые требования.
2. Варианты использования, поясняющие эти требования.

Именно по такому принципу я в последнее время и формирую спецификации.



В книге "Путь аналитика", насколько я помню, предлагается способ:

1. Высокоуровневые требования.
2. Варианты использования, поясняющие эти требования.

Именно по такому принципу я в последнее время и формирую спецификации.

Да, тоже это читал, но не представляю как это уложить в ТЗ.



Цитата: skillu
Но ВИ нужно тоже согласовывать с заказчиком, ведь это отличный способ показать как система будет работать, а не просто требование, что должно быть. И как я понимаю, все ВИ можно складировать в отдельные текстовые документы, группируя в папки (по актору, подсистеме или по др. атрибутам) ?

Еще раз говорю, не нужно смешивать (и путать!) требования и ВИ: первое определяет ЧТО должно быть сделано, второе - КАК, т.е. придуманный разработчиком способ работы с программной - проектное решение, определенная новизна, вот эту новизну и нужно согласовывать с тем, кто потом будет с этим работать. Довольно подробно этот аспект описан у Леффингуэлла сотоварищи.

а оформлять... да как хотите, так и оформляйте... Важно, чтобы это было удобно и понятно и заказчику, и исполнителю. Цель ведь не наплодить документов, а внятно описать все существенные аспекты разработки. Содержание первично - форма вторична. Хорошая структура = хороший инструмент.
Лью воду...



Спасибо, что откликнулись. Под "способами применения" вы понимаете варианты использования?
Да
Цитировать
и по пункту № 2, то есть в ТЗ должено существовать функциональное требование «Система должна позволять выбирать адресатов письма из адресной книги» и параллельно с ним, в отдельном файле может быть ВИ «Выбор адресатов».
Да, в ТЗ можно указать ФТ «Выбор адресатов из адресной книги», вот только выявлять его, как вы правильно писали раньше, удобнее через разработку набора способов применения, относящихся к фиче «Отправка писем». Например, через разработку способа применения «Отправить письмо».

«Выбор адресатов» — это вообще не ВИ, это его шаг. Способ применения — это, ради чего происходит сеанс работы в системе.

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



Спасибо, что откликнулись. Под "способами применения" вы понимаете варианты использования?
Да
Цитировать
и по пункту № 2, то есть в ТЗ должено существовать функциональное требование «Система должна позволять выбирать адресатов письма из адресной книги» и параллельно с ним, в отдельном файле может быть ВИ «Выбор адресатов».
Да, в ТЗ можно указать ФТ «Выбор адресатов из адресной книги», вот только выявлять его, как вы правильно писали раньше, удобнее через разработку набора способов применения, относящихся к фиче «Отправка писем». Например, через разработку способа применения «Отправить письмо».

«Выбор адресатов» — это вообще не ВИ, это его шаг. Способ применения — это, ради чего происходит сеанс работы в системе.

Цитировать
ВИ обязательно нужно согласовывать с заказчиком ?
В общем случае да, но обычно он делегирует эту функцию своим экспертам.
Спасибо за исчерпывающие ответы! Теперь все устаканилось.




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19