Лекции (1 курс, 2 семестр) УТкПО / Управление требованиями к программному обеспечению 2
.pdf
ВИДЫ
ТРЕБОВАНИЙ
Функциональные требования включают в себя перечень сервисов, которые должна выполнять система, причем должно быть указано, как система реагирует на те или иные входные данные, как она ведет себя в определенных ситуациях и т.д. В некоторых случаях указывается, что система не должна делать (так называемые обратные требования).
Нефункциональные требования описывают характеристики системы и ее окружения, а не поведение системы. Здесь также может быть приведен перечень ограничений, накладываемых на действия и функции, выполняемые системой. Они включают временные ограничения, ограничения на процесс разработки системы, стандарты и т.д.
ВИДЫ
ТРЕБОВАНИЙ
Требования предметной области характеризуют ту предметную область, где будет эксплуатироваться система. Эти требования могут быть функциональными и нефункциональными.
Бизнес-правила. Представляют собой определенные корпоративные политики, промышленные стандарты, законы и иные нормативные документы и контролирующие принципы, которые отражают объективные условия, в которых предполагается эксплуатация программного продукта. Бизнес-правила иногда хранятся отдельно от требований, в другом документе. Кроме того, часто бизнес-правила специально составляются для какой-либо предметной области, хранятся отдельно от бизнес-правил других предметных областей и могут повторно использоваться в схожих проектах, т.е. управление бизнес-правилами следует осуществлять на корпоративном уровне.
Категории бизнесправил
факты (некие истинные утверждения относительно предметной области);
ограничения (перечень недопустимых операций программной системы);
активаторы операций (инициируют выполнение некоторой последовательности действий);
выводы (формируют новый факт на основе имеющихся); вычисления (формулы для вычисления определенных атрибутов предметной области, например скидки при покупке товара).
ВИДЫ
ТРЕБОВАНИЙ
Функциональные требования включают в себя перечень сервисов, которые должна выполнять система, причем должно быть указано, как система реагирует на те или иные входные данные, как она ведет себя в определенных ситуациях и т.д. В некоторых случаях указывается, что система не должна делать (так называемые обратные требования).
Нефункциональные требования описывают характеристики системы и ее окружения, а не поведение системы. Здесь также может быть приведен перечень ограничений, накладываемых на действия и функции, выполняемые системой. Они включают временные ограничения, ограничения на процесс разработки системы, стандарты и т.д.
Функциональ
ные требования.
Эти требования описывают поведение системы и сервисы (функции), которые она выполняет, и зависят от типа разрабатываемой системы и от потребностей пользователей.
Если функциональные требования оформлены как пользовательские, они, как правило, описывают систему в обобщенном виде. В противоположность этому функциональные требования, оформленные как системные, описывают систему максимально подробно, включая ее входные и выходные данные, исключения и т.д.
Функциональные требования для программных систем могут быть описаны разными способами.
Функциональ
ные требования.
Функциональные требования регламентируют функционирование или поведение системы (behavioral requirements). Функциональные требования отвечают на вопрос "что должна делать система" в тех или иных ситуациях. Функциональные требования определяют основной "фронт работ" Разработчика, и устанавливают цели, задачи и сервисы, предоставляемые системой Заказчику.
Функциональные требования записываются, как правило, при посредстве предписывающих правил: "система должна позволять кладовщику формировать приходные и расходные накладные". Другим способом являются так называемые варианты использования (users cases) - популярный и весьма продуктивный способ представления требований.
Use case -
вариант
использовани я, прецедент.
Данный термин был введен в обиход программной инженерии шведским учёным Айваром Якобсоном .
Согласно нотации UML 2.4.1
(http://www.omg.org/spec/UML/2.4.1/),
прецеденты являются средством для определения требуемых использований системы. Как правило, они применяются для извлечения требований к системе, то есть, того, что система предполагает делать.
Основными понятиями, связанными с вариантами использования являются акторы, прецеденты, и объект.
Use case -
вариант
использовани я, прецедент.
Объектом является рассматриваемая система, в которой применяются прецеденты.
Пользователи и любые другие системы, которые могут взаимодействовать с объектом, представлены в качестве акторов. Акторы всегда моделируют сущности, находящиеся за пределами системы.
Требуемое поведение объекта задается одним или несколькими вариантами использования, которые определяются в соответствии с потребностями акторов. Строго говоря, термин "вариант использования" относится к типу прецедента. Экземпляр прецедента относится к проявлению поведения, соответствующего типу прецедента.Такие случаи, как правило, описывается через спецификацию взаимодействий.
Нефункциональные требования
Как следует из названия, нефункциональные требования не связаны непосредственно с функциями, выполняемыми системой. Они связаны с такими интеграционными свойствами системы, как надежность, время ответа или размер системы.
Кроме того, нефункциональные требования могут определять ограничения на систему, например на пропускную способность устройств ввода-вывода или форматы данных, используемых в системном интерфейсе.
Нефункциональные требования
Как следует из названия, нефункциональные требования не связаны непосредственно с функциями, выполняемыми системой. Они связаны с такими интеграционными свойствами системы, как надежность, время ответа или размер системы.
Кроме того, нефункциональные требования могут определять ограничения на систему, например на пропускную способность устройств ввода-вывода или форматы данных, используемых в системном интерфейсе.