Читайте также:
|
При разработке программных систем главной задачей является определения требований к системе.
Требование – это возможность, которую кто-либо ожидает от данного ПО.
В стандарте IEEE - требование определяется следующим образом (IEEE – Institute of Electrical and Electronic Engineers – Институт инженеров по электротехнике и электронике).
1. Условие или возможность, необходимая пользователю для решения проблемы или достижения цели.
2. Условие или возможность, которой должна обладать система или компонент системы, соответствующие договору, стандарту, спецификации или другому официальному документу.
3. Документированное представление условий или возможностей, перечисленных в предыдущих пунктах.
Классификация требований в SWEBOK (свод знаний по программной инженерии):
1. Требования к продукту и процессу. Требования к продукту- определяют те параметры, которые необходимо получить. Требования к процессу – определяют параметры процесса, с помощью которого может быть создан программный продукт.
2. Функциональные и нефункциональные требования. Функциональные- регламентируют функционирование или поведение системы (что должна делать система). Нефункциональные – внутренние или внешние условия или атрибуты функционирования системы. Функциональные требования записываются в виде
-предписывающих правил: "система должна позволять кладовщику формировать приходные и расходные накладные".
-вариантов использования:uses cases
3. Независимые требования - это требования, которые не могут быть адресованы к компонентам системы в отдельности, а являются свойством системы в целом. Пример, требования к «пропускной способности» коллцентра, которая будут зависеть от того, каким образом будут взаимодействовать коммуникационное оборудование, оператор и программное обеспечение в конкретных условиях.
4. Требования с количественной оценкой – требования, поддающиеся количественному измерению/ определению. Например, система должна обеспечить пропускную способность с определенным количеством запросов в секунду
5. Системные и программные требования. Система является более емким понятием, чем ПО, и включает определение, в котором функционирует ПО: аппаратные средства, ПО и др.
отсюда, естественным образом, вытекают требования к системе в целом и программному обеспечению (или программной системе), в частности.
Классификация требований по К.Вигерсу:
1. Функциональные
2. Нефункциональные
3. Системные
Функциональные:
- бизнес-требования (определяют высокоуровневые цели Заказчика. Формируются топ-менеджерами либо акционерами) Пример, система должна сократить срок выполнения обрабатываемых на предприятии заказов в два раза
- пользовательские описывают цели/задачи пользователей системы, которые должны выполняться пользователями при помощи ПО. Пример, система должна представлять диалоговые средства сотруднику, отвечающему за его планирование и исполнение
• для ввода информации о заказе,
• фиксации информации в базе данных
отслеживании информации о заказе
- функциональные определяют функциональность ПО, которая должна быть создана. Пример функциональных требований (или просто функций) по работе с электронным заказом: заказ может быть создан, отредактирован, удален и перемещен с участка на участок
Нефункциональные требования:
- бизнес-правила включают или связаны с корпоративными регламентами, стандартами, законными актами и т.д
- внешние интерфейсы – интерфейс пользователя, интерфейс внешних устройств, программный интерфейс, интерфейс передачи информации.
- атрибуты качества описывают характеристики продукта в различных «измерениях», важных для пользователей и/или разработчиков (применимость, надежность, производительность)
- ограничения – формулировки условий, модифицирующих требования или наборы требований, сужая выбор сужая выбор возможных решений по их реализации.
Системные требования описывают высокоуровневые требования к программному обеспечению, содержащему несколько или много взаимосвязанных подсистем и приложений. При этом, система может быть как целиком программной, так и состоять из программной и аппаратной частей.
Например, параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных,...), которые, в свою очередь, могут относиться, например, к внешним интерфейсам.
Классификация требований в RUP:
- модели требований (FURPS+)
- уровни требований.
FURPS+:
Functionality, функциональность
Usability, удобство использования
Reliability, надежность
Performance, производительность
Supportability, поддерживаемость
+ необходимо помнить о таких возможных ограничениях, как:
ограничения проектирования,
ограничения разработки,
ограничения на интерфейсы,
физические ограничения.
Уровни требований:
- потребность – определяют проблемы бизнеса, которые должны быть соотнесены с использованием или приобретением системы.
- свойство продукта (фича)- набор логически связанных функциональных требований, которые обеспечивают возможности пользователя и удовлетворяют бизнес цели.
- программные требования
Свойства требований:
1) Полнота – скорее тенденция, к которой нужно приблизиться. Требование полноты можно рассматривать в двух аспектах: полнота отдельного требования и полнота системы требований.
Полнота отдельного требования - свойство, означающее, что текст требования не требует дополнительной детализации, то есть в нем предусмотрены все необходимые нюансы, особенности и детали данного требования.
Полнота системы требований - свойство, означающее, что совокупность артефактов, описывающих требования, исчерпывающим образом описывает все то, что требуется от разрабатываемой системы.
2) Ясность (определенность, недвусмысленность, однозначность спецификаций)
3) Корректность и согласованность (непротиворечивость). Можно выделить вертикальную и горизонтальную согласованность. требования не должны противоречить, соответственно, требованиям своего уровня иерархии и требованиям "родительского" уровня. Так, требования пользователей не должны противоречить бизнес-требованиям, а функциональные требования - требованиям пользователя.
4) Варифицируемость (пригодность к проверке).
5) Необходимость и полезность при эксплуатации -Необходимыми следует считать свойства, без выполнения которых невозможно, либо затруднено выполнение автоматизированных бизнес-функций пользователей; полезными при эксплуатации следует считать любые свойства, повышающие эргономические качества продукта.
6) Осуществимость (выполнимость) - разумный баланс между ценностью (степенью необходимости и полезности) и потребными ресурсами.
7) Трассируемость требования определяется возможностью отследить связь между ним и другими артефактами информационной системы (документами, моделями, текстами программ и пр.).
8) Упорядоченность по важности и стабильности Приоритет требования представляет собой количественную оценку степени значимости (важности) требования. Приоритеты требований обычно назначает представитель Заказчика. Разработчик, отталкиваясь от приоритетности требований, управляет процессом реализации информационной системы.
Стабильность требования характеризует прогнозную оценку неизменности требований во времени.
9) Наличие количественной метрики - Количественные метрики играют важную роль в верификации и аттестации информационных систем.
Дата добавления: 2015-11-26; просмотров: 3135 | Нарушение авторских прав