BoatmansHome: Требования/ОбъектыТребований ...

Boatmans Home Start | Каталог | Изменения | Комментарии | Пользователи | Регистрация | Вход  Пароль:  
Данные материалы созданы для размещения на сайте boatmanshome.ru. Во всех случаях, кроме явно оговоренных в теле материала, автор и обладатель исключительного права - Нужненко Сергей Александрович. Во всех случаях, кроме явно оговоренных в теле материала, для данных материалов разрешено размещение ссылок и цитирование, а так же воспроизведение в личных и учебных целях. Без согласования с правообладателем запрещается для данных материалов или любой части использование в коммерческих целях, а так же распространение, публичный показ, импорт с целью распространения, прокат, переработка, сообщение для всеобщего сведения.
 

С точки зрения ключевых параметров деятельности: V (Объем результата), Q (качество результата), C (стоимость), T (время получения) требования могут быть


В отечественной практике (что и можно видеть в ГОСТах) часто фиксируются требования ко всем параметрам VQCT и такой документ называется «Техническое задание».
В западной практике часто разделяют описание по параметрам и появляется несколько связанных артефактов, например, scope (V), requirements specification (Q), plan (CT).
Эта разница добавляет путаницы при обсуждении техник работы с требованиями, так как предмет требований часто остается в контексте и понимается обсуждающими по разному.


Кроме того, какие параметры деятельности будут отражены в требованиях, необходимо понимать и класс предмета поставки, к которому эти требования предъявляются. Если взять только ИТ, то выбор тут велик, он описан в заметке ./АвтоматизированныеСистемы/КакОниЕсть.


Если коротко и грубо, то с точки зрения рамок объекта требований выбор такой (в порядке сужения и взаимной вложенности):


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


Учитывая, что все классификации условны, важно понимать, что когда мы формулируем требования, всегда надо держать в голове, к чему предъявляется требование.
Если в ходе работы мы намерены жестко отслеживать границу системы (в западной практике есть термин SUD – System Under Design – разрабатываемая система), надо учесть, что ряд требований по факту предъявляется не к системе, а к другим предметам. Например «требования к персоналу» или «требования к окружению и обеспечению». Строго говоря по отношению к SUD это ограничения (на условия ее функционирования).
Кроме этого требования могут предъявляться к подсистемам, отдельным элементам и их множествам, к проектным решениям в добавок к тому, что уже было обсуждено.


В качестве упражнения и рабочей техники попробуйте отмечать при разговоре с заказчиком и пользователями, когда собираете требования, что является объектом требований в исходной дословной формулировке: <Объект требования> должен/должна/должно <УСЛОВИЕ>. После анализа требование может быть преобразовано и переформулировано так, чтобы объектом требований была SUD, или заранее оговоренные классы внешних объектов и компонетов системы.
Приведение требований к единому объекту помогает обеспечивать их непротиворечивость и полноту. Гораздо проще сравнивать условия, наложенные на один объект. Повышение полноты требований обеспечивается вопросом: «что еще должен этот объект?».


Чтобы не путаться в объектах требований, удобно держать в голове или в документации модель системы, на которой видны границы и объекты требований. Надо заранее договориться, какими будут объекты требований в данном проекте. Эта модель дает лучшее понимание естественной классификации требований для данного проекта, а так же взаимосвязи (а значит, направлениях трассировки и взаимной проверки на непротиворечивость) требований разных типов между собой.


 
Файлов нет.[Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]