Главная Случайная страница Контакты | Мы поможем в написании вашей работы! | ||
|
Управление требованиями - это вид коммуникационных работ по взаимодействию заказчика и исполнителя с целью выявить требования на всех этапах (стадиях) жизненного цикла ИС (рис.7.):
Рис.7. Виды требований к ИС
На иллюстрации обозначены:
Бизнес-требования (business requirements) содержат высокоуровневые цели организации или заказчиков системы.
Требования пользователей (user requirements) описывают цели и задачи, которые пользователям позволит решить система.
Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований.
Системные требования (system requirements) обозначают высокоуровневые требования к продукту, которые содержат многие эподсистемы, то есть система.
Бизнес-правила (business rules) включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы.
Спецификации требований к ПО (software requirements specification, SRS) документируют функциональные требования, где описывается так полно, как необходимо, ожидаемое поведение системы.
Нефункциональные требования описывают цели и атрибуты качества, внешние взаимодействия между системой и внешним миром, а также ограничения дизайна и реализации.
Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся легкость и простота использования, легкость перемещения, целостность, эффективность и устойчивость к сбоям.
Требования к внешнему интерфейсу определяют правила внешних взаимодействий между системой и внешним миром.
Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта.
Новые требования к ИС могут быть установлены на всех этапах жизненного цикла ИС, роль управления требованиями в процессе разработки системы можно представить рис.8.
Рис.8. Порядок спецификации требований
Спецификация требований не содержит деталей дизайна или реализации (кроме известных ограничений), данных о планировании проекта или сведений о тестировании. Из этого документа должно быть абсолютно ясно, что надлежит построить команде разработчиков. Для проекта, как правило, создаются требования других типов: документ, где описана среда разработки, ограничения бюджета, руководство пользователя или требования для выпуска продукта и продвижения его в поддерживаемую среду. Все это относится к требованиям к проекту, но не к продукту.
К действиям по разработке (извлечению, документированию, анализу, утверждению, проверке) требований относятся:
идентификация классов пользователей для данного продукта;
выяснение потребностей тех, кто представляет каждый класс пользователей;
определение задач и целей пользователей, а также бизнес-целей, с которыми эти задачи связаны;
анализ информации, полученной от пользователей, чтобы отделить задачи от функциональных и нефункциональных требований, бизнес - правил, предполагаемых решений и поступающих извне данных;
распределение высокоуровневых требований по компонентам ПС, определенным в системной архитектуре;
установление относительной важности атрибутов качества;
установление приоритетов реализации;
документирование собранной информации и построение моделей;
просмотр спецификации требований, который позволяет удостовериться в том, что запросы пользователей всеми понимаются одинаково, и устранение возникших проблем до передачи документа разработчикам.
К действиям по управлению требованиями относятся:
определение основной версии требований (моментальный срез требований для конкретной версии продукта);
просмотр предлагаемых изменений требований и оценка вероятности воздействия каждого изменения до его принятия;
включение одобренных изменений требований в проект установленным способом;
согласование плана проекта с требованиями;
обсуждение новых обязательств, основанных на оцененном влиянии изменения требований;
отслеживание отдельных требований до их дизайна, исходного кода и вариантов тестирования;
отслеживание статуса требований и действий по изменению на протяжении всего проекта.
Требования к системе должны быть оценены с учетом следующих критериев (при этом результаты оценок должны быть документально оформлены):
a) учет потребностей заказчика;
b) соответствие потребностям заказчика;
c) тестируемость;
d) выполнимость проектирования системной архитектуры;
e) возможность эксплуатации и сопровождения.
Дата публикования: 2015-02-17; Прочитано: 1080 | Нарушение авторского права страницы | Мы поможем в написании вашей работы!