Свойства требований к программной системе. Анализ требований требований к программной системе.
Перечислим основные свойства программных требований:
Недвусмысленность
Должен существовать только один путь интерпретации требования. Иногда двусмысленность проявляется в виде неопределенных акронимов.
Пример:
Треб.1: Система не должна принимать пароли более 15-ти символов.
Не совсем ясно, что система должна делать:
Система не должна позволять пользователю вводить более чем 15 символов.
Система должна отсекать введенную строку до 15-ти символов.
Система не должна отображать сообщение об ошибке, если пользователь вводит более чем 15 символов.
Исправленное требование содержит пояснение:
Треб.1: Система не должна принимать пароли более 15-ти символов. Если пользователь вводит более 15-ти символов при выборе пароля, сообщение об ошибке должно информировать пользователя о необходимом исправлении пароля.
Тестируемость (Возможность Проверки)
Тестеры должны иметь возможность проверить, было ли требование реализовано корректно. Тестирование должно быть либо пройдено, либо нет. Чтобы быть пригодным для тестирования, требование должно быть ясным, точным и недвусмысленным. Использование некоторых слов может сделать требование невозможным для тестирования:
Некоторые прилагательные: устойчивый, безопасный, точный, эффективный, целесообразный, гибкий, настраиваемый, надежный, дружелюбный, адекватный.
Некоторые наречия и фразы с ними: быстро, безопасно, своевременно.
Неспецифичные слова или акронимы: и т.д., и/или, TBD (to be determined).
Треб.1: Система должна препятствовать одновременному доступу большого числа пользователей.
Какое количество здесь имеется в виду под «большим числом» - 10, 100 или 1000?
Ясность (Краткость, Сжатость, Простота, Точность)
Требования не должны содержать ненужных выражений или информации. Они должны быть изложены кратко и просто:
Треб.1: Иногда пользователь будет вводить Airport Code (Код Аэропорта), который система будет распознавать. Но иногда код можно заменить близлежащим городом, и тогда пользователю не нужно знать код аэропорта, т.к. система будет понимать название города.
Это предложение может быть заменено на более простое:
Треб.1: Система должна идентифицировать аэропорт на основании Airport Code (Кода Аэропорта) или City Name (Названия Города).
Корректность
Если требование содержит факты, эти факты должны быть достоверны:
Треб.1: Цены на аренду машин должны включать все соответствующие налоги (включая налог штата - 6%)
Налог зависит от штата, так что представленная цифра в 6 % - некорректна.
Понятность
Требования должны быть грамматически правильные, написаны в соответствующем стиле. Должны быть использованы стандартные соглашения. Слово «должен» должно быть использовано вместо «будет», «обязан» или «может».
Реалистичность (Правдоподобность, Выполнимость)
Требование должно быть выполнимо в рамках существующих ограничений, таких как время, деньги и доступные ресурсы.
Треб.1: Система должна иметь интерфейс на естественном языке, который будет понимать команды на английском языке.
Это требование может быть нереальным из-за короткого периода времени разработки.
Независимость
Чтобы понять требование, не нужно знать какое-либо другое требование.
Треб.1: Список доступных рейсов должен включать номер рейса, время отправления и время прибытия для каждого отрезка пути.
Треб.2: Он должен быть отсортирован по ценам.
Слово «Он» во втором предложении относится к предыдущему требованию. И если порядок требований изменить, это требование будет непонятно.
Элементарность
Требование должно содержать отдельный трассируемый элемент (для которого возможно отслеживание связи):
Треб.1: Система должна предоставлять возможность бронировать рейс, покупать билет, бронировать номер в гостинице, бронировать машину, а также предоставлять информацию о развлечениях.
Это требование содержит пять элементарных требований, которые затрудняют трассировку. Предложения, включающие предлоги «и» или «но» должны быть пересмотрены на предмет разделениях их на элементарные требования.
Необходимость
В требовании нет необходимости, если:
ни одному заинтересованному лицу требование не нужно;
удаление требования не повлияет на систему.
Пример требования, которое может быть удалено, т.к. оно не предоставляет никакой новой информации:
Треб.1: Все требования, указанные в документе Концепции должны быть реализованы и протестированы.
Независимость от Реализации (Абстрактность)
Требования не должны содержать ненужной информации о дизайне и реализации системы:
Треб.1: Информация должна храниться в текстовом файле.
Решение того, каким образом информация будет храниться, и затем передаваться пользователю, должно приниматься дизайнерами или архитекторами системы.
Постоянство
Не должно существовать конфликтов между требованиями. Конфликты могут быть прямые и косвенные.
Прямые конфликты возникают, когда ожидается различное поведение системы в одной и той же ситуации:
Треб.1: Дата должна отображаться в формате мм/дд/гггг.
Треб.1: Дата должна отображаться в формате дд/мм/гггг.
Иногда возможно разрешить конфликт путем анализа условий, которые явились источником данных требований. Например, если Треб.1 поступило от американского пользователя, а Треб.2 от французского, то предыдущие требования могут быть переписаны следующим образом:
Треб.1: Для пользователей США дата должна отображаться в формате мм/дд/гггг.
Треб.2: Для пользователей Франции дата должна отображаться в формате дд/мм/гггг.
Немногословность
Каждое требование должно быть обозначено только один раз, и не должно перекрываться другим требованием:
Треб.1: Для удобства ввода даты рейса в системе должен быть доступен календарь.
Треб.2: Система должна отображать всплывающее окно с календарем при вводе любой даты.
Первое требование (относящееся только к дате рейса) является частью второго требования (относящееся к любой дате, вводимой пользователем).
Завершенность
Требование должно быть описано для всех возможных условий.
Хорошее требование должно удовлетворять как можно большему количеству критериев. Однако они могут быть выражены в виде комбинации вышеперечисленных критериев.
При анализе требований происходит трансформация информации, полученной от заинтересованных лиц в четко и однозначно определенные требования, передаваемые инженерам для реализации в программном коде.
Анализ требований включает:
обнаружение и разрешение конфликтов между требованиями;
определение границ задачи, решаемой создаваемым программным обеспечением;
детализация системных требований для установления программных требований.
Вне зависимости от выразительных средств, которые являются лишь инструментом анализа и фиксирования результатов, результатом анализа требований должны быть однозначно интерпретируемые требований, реализация которых проверяема, а стоимость и ресурсы – предсказуемы.
Требования могут классифицироваться по следующим параметрам:
функциональные и нефункциональные требования;
внутренние (с другими требованиями) или внешние зависимости;
требования к процессу или продукту;
приоритет требований;
содержание требований в отношении конкретных подсистем создаваемого программного обеспечения;
изменяемость/стабильность требований.
Разработка модели проблемы реального мира (концептуальное моделирование) – ключевой элемент анализа требований. Цель моделирования – понимание проблемы, задачи и методов их решения до того, как начнется решение проблемы.
Объем моделей, их детализация и средства представления могут быть различны. Их выбор диктуется предпочтениями и компетенциями организаций, вовлеченных в проект.
Среди факторов, которые влияют на выбор модели, метода и детализации её представления, степени связанности с программным кодом и другими вопросами:
природа проблемы (проблемной области);
экспертиза и опыт инженеров;
требования заказчика к процессу;
доступность методов и инструментов;
внутрикорпоративные стандарты и регламенты;
культура разработки.
Вопросы моделирования тесно связаны с применяемыми методами и подходами. Поэтому, частные методы или нотации, обычно следуют распространенным в индустрии практикам и тяготеют к тем формам, с которыми связаны накопленный опыт и подтвержденные общепринятой практикой знания.
Архитектурное проектирование очень близко к концептуальному моделированию. Непосредственное отображение бизнес-сущностей реального мира на программные компоненты не является обязательным, поэтому и существует такое разделение между моделированием и проектированием. Деятельность по моделированию определяет порядок проектирования (то, «что» надо сделать), а архитектура – процедуры («как» это будет реализовано).
Процедуры анализа требований: 15 задач стандарта IEEE P1220.стр 41 в стандарте
The following section provides a list of tasks that represents a plan to analyze requirements. Part of
this notional process is based on the 15 requirements analysis tasks listed in IEEE P1220. This industry standard and others should be consulted when preparing engineering activities to help identify and structure appropriate activities.
As with all techniques, the student should be careful to tailor; that is, add or subtract, as suits the
particular system being developed. Additionally, these tasks, though they build on each other, should
not be considered purely sequential. Every task contributes understanding that may cause a need
to revisit previous task decisions. This is the nature of all System Engineering activities.
The 15 Tasks of IEEE P1220 The IEEE Systems Engineering Standard offers a process for performing Requirements Analysis that comprehensively identifies the important tasks that
must be performed. These 15 task areas to be analyzed follow and are shown in Figure 4-3.
Следующий раздел обеспечивает список задач, который представляет план проанализировать требования. Часть
этот отвлеченный процесс основывается на этих 15 аналитических задачах требований, перечисленных в IEEE P1220. С этим промышленным стандартом и другими нужно консультироваться при подготовке технических действий, чтобы помочь идентифицировать и структура надлежащие действия.
Как со всеми методами, студент должен делать все возможное настроить; т.е. добавьте или вычтите, как подходит
определенная разработанная система. Дополнительно, эти задачи, хотя они основываются друг на друге, должны
не считаться чисто последовательным. Каждая задача вносит понимание, которое может вызвать потребность
повторно посетить предыдущие решения задачи. Это - природа всех действий Системного проектирования.
15 Задач IEEE P1220, который Стандарт Системного проектирования IEEE предлагает процессу для того, чтобы выполнить Анализ Требований, который всесторонне идентифицирует важные задачи это
должен быть выполнен. Эти 15 областей задачи, которые будут проанализированы, следуют и показаны в рисунке 4-3.
Task 1. Customer Expectations
Define and quantify customer expectations. They may come from any of the eight primary functions,
operational requirements documents, mission needs, technology-based opportunity, direct communications with customer, or requirements from a higher system level. The purpose of this task is to determine what the customer wants the system to accomplish, and how well each function must be accomplished. This should include natural and induced environments in which the product(s) of the system must operate or be used, and constraints (e.g. funding, cost, or price objectives, schedule, technology, nondevelopmental and reusable items, physical characteristics, hours of operation per day, on-off sequences, etc.).
Task 2. Project and Enterprise Constraints
Identify and define constraints impacting design solutions. Project specific constraints can include:
• Approved specifications and baselines developed from prior applications of the Systems Engineering Process,
• Costs,
• Updated technical and project plans,
• Team assignments and structure,
• Control mechanisms, and
• Required metrics for measuring progress.
Enterprise constraints can include:
• Management decisions from a preceding technical review,
• Enterprise general specifications,
• Standards or guidelines,
• Policies and procedures,
• Domain technologies, and
• Physical, financial, and human resource allocations to the project.
Задача 1. Потребительские ожидания
Определите и определите количество потребительских ожиданий. Они могут произойти из любой из этих восьми первичных функций,
операционные документы требований, потребности миссии, основанная на технологии возможность, прямая связь с клиентом или требования от более высокого системного уровня. Цель этой задачи состоит в том, чтобы определить то, что клиент хочет, чтобы система выполнила, и как хорошо каждая функция должна быть выполнена. Это должно включать естественные и вызванные среды, в которых продукт (ы) системы должен работать или использоваться, и ограничения (например, финансирование, стоиться, или ценовые цели, расписание, технология, и допускающие повторное использование элементы несвязанные с развитием, физические характеристики, часы работы в день, релейные последовательности, и т.д.).
Задача 2. Проект и ограничения предприятия
Идентифицируйте и определите ограничения, влияющие на дизайнерские решения. Проект определенные ограничения может включать:
• Утвержденные спецификации и базовые линии, разработанные из предшествующих приложений Процесса Системного проектирования,
• Затраты,
• Обновленные технические и планы проекта,
• Присвоения команды и структура,
• Механизмы управления, и
• Требуемые метрики для того, чтобы измерить прогресс.
Ограничения предприятия могут включать:
• Управленческие решения от предыдущего технического анализа,
• Технические требования предприятия,
• Стандарты или инструкции,
• Политики и процедуры,
• Доменные технологии, и
• Физические, финансовые выделения, и человеческих ресурсов к проекту.
Task 3. External Constraints
Identify and define external constraints impacting design solutions or implementation of the Systems
Engineering Process activities. External constraints can include:
• Public and international laws and regulations,
• Technology base,
• Compliance requirements: industry, international, and other general specifications, standards, and guidelines which require compliance for legal, interoperability, or other reasons,
• Threat system capabilities, and
• Capabilities of interfacing systems.
Task 4. Operational Scenarios
Identify and define operational scenarios that scope the anticipated uses of system product(s). For each
operational scenario, define expected:
• Interactions with the environment and other systems, and
• Physical interconnectivities with interfacing systems, platforms, or products.
Task 5. Measures of Effectiveness and Suitability (MOE/MOS)
Identify and define systems effectiveness measures that reflect overall customer expectations and
satisfaction. MOEs are related to how well the system must perform the customer’s mission. Key MOEs include mission performance, safety, operability, reliability, etc. MOSs are related to how well the system performs in its intended environment and includes measures of supportability, maintainability, ease of use, etc.
Task 6. System Boundaries Define system boundaries including:
• Which system elements are under design control of the performing activity and which fall
outside of their control, and
• The expected interactions among system elements under design control and external and/or
higher-level and interacting systems outside the system boundary (including open systems
approaches).
Задача 3. Внешние ограничения
Идентифицируйте и определите внешние ограничения, влияющие на дизайнерские решения или реализацию Systems
Действия Процесса разработки. Внешние ограничения могут включать:
• Общественное право и нормы международного права и инструкции,
• Технологическая основа,
• Требования соответствия: отрасль, международные, и другие технические требования, стандарты и инструкции, которые требуют соответствия для юридического, функциональной совместимости или других причин,
• Системные возможности угрозы, и
• Возможности взаимодействующих через интерфейс систем.
Задача 4. Операционные сценарии
Идентифицируйте и определите операционные сценарии, которые определяют объем ожидаемого использования системного продукта (ов). Для каждого
операционный сценарий, определите ожидаемый:
• Взаимодействия со средой и другими системами, и
• Физические взаимосвязанности со взаимодействующими через интерфейс системами, платформами или продуктами.
Задача 5. Меры эффективности и пригодности (MOE/MOS)
Идентифицируйте и определите системные меры по эффективности, которые отражают полные потребительские ожидания и
удовлетворение. MOEs связаны с тем, как хорошо система должна выполнить миссию клиента. Ключевые MOEs включают производительность миссии, безопасность, удобство использования, надежность, и т.д. МОХ связан с тем, как хорошо система выполняет в ее намеченной среде и включает меры обеспеченности, пригодности для обслуживания, простоты использования, и т.д.
Задача 6. Системные Границы Определяют системные границы включая:
• Какие системные элементы находятся под контролем проекта действия выполнения и которые падают
за пределами их управления, и
• Ожидаемые взаимодействия среди системных элементов под управлением проектом и внешний и/или
более высокий уровень и взаимодействующие системы вне системной границы (включая открытые системы
подходы).
Task 7. Interfaces
Define the functional and physical interfaces to external or higher-level and interacting systems,
platforms, and/or products in quantitative terms (include open systems approach). Functional and
physical interfaces would include mechanical, electrical, thermal, data, control, procedural, and other
interactions. Interfaces may also be considered from an internal/external perspective. Internal
interfaces are those that address elements inside the boundaries established for the system ad-
dressed. These interfaces are generally identified and controlled by the contractor responsible for
developing the system. External interfaces, on the other hand, are those which involve entity rela-
tionships outside the established boundaries, and these are typically defined and controlled by the
government.
Task 8. Utilization Environments Define the environments for each operational
scenario. All environmental factors (natural or induced) which may impact system performance
must be identified and defined. Environmental factors include:
• Weather conditions (e.g., rain, snow, sun, wind, ice, dust, fog),
• Temperature ranges,
• Topologies (e.g., ocean, mountains, deserts, plains, vegetation),
• Biological (e.g., animal, insects, birds, fungi),
• Time (e.g., dawn, day, night, dusk), and
• Induced (e.g., vibration, electromagnetic, chemical).
Task 9. Life Cycle Process Concepts
Analyze the outputs of tasks 1-8 to define key life cycle process requirements necessary to develop,
produce, test, distribute, operate, support, train, and dispose of system products under development.
Use integrated teams representing the eight primary functions. Focus should be on the cost drivers and
higher risk elements that are anticipated to impact supportability and affordability over the useful life
of the system.
Задача 7. Интерфейсы
Определите функциональные и физические интерфейсы к внешним или высокоуровневым и взаимодействующим системам,
платформы и/или продукты в количественных терминах (включают подход открытых систем). Функциональный и
физические интерфейсы включали бы механический, электрический, тепловой, данные, управление, процедурный, и другой
взаимодействия. Интерфейсы можно также рассмотреть с внутренней/внешней точки зрения. Внутренний
интерфейсы - те, которые адресуют элементы в границах, установленных для системного объявления -
украшенный. Эти интерфейсы обычно идентифицирует и управляет подрядчик, ответственный за
разработка системы. Внешние интерфейсы, с другой стороны, являются теми, которые включают объект rela-
tionships вне установленных границ, и их обычно определяют и управляют
правительство.
Задача 8. Среды использования Определяют среды для каждого операционного
сценарий. Все факторы окружающей среды (естественный или вызванный), который может повлиять на производительность системы
должен быть идентифицирован и определен. Факторы окружающей среды включают:
• Погодные условия (например, дождь, снег, солнце, ветер, лед, пыль, вуаль),
• Диапазоны температуры,
• Топология (например, океан, горы, пустыни, плоскости, растительность),
• Биологический (например, животное, насекомые, птицы, грибы),
• Время (например, рассвет, день, ночь, сумрак), и
• Вызванный (например, вибрация, электромагнитная, химическая).
Задача 9. Понятия процесса жизненного цикла
Проанализируйте выводы задач 1-8 определить ключевые требования процесса жизненного цикла, необходимые, чтобы разработать,
произведите, протестируйте, распределите, управляйте, поддерживайте, обучайтесь и избавьтесь от разрабатываемых системных продуктов.
Используйте интегрированные команды, представляющие эти восемь первичных функций. Фокус должен быть на носителях затрат и
более высокие элементы риска, которые, как ожидают, влияют на обеспеченность и допустимость за срок полезного использования
из системы.
Task 10. Functional Requirements
Define what the system must accomplish or must be able to do. Functions identified through require-
ments analysis will be further decomposed during functional analysis and allocation.
Task 11. Performance Requirements
Define the performance requirements for each higher-level function performed by the system. Primary focus should be placed on performance requirements that address the MOEs, and other KPPs established in test plans or identified as interest items by oversight authorities.
Task 12. Modes of Operation
Define the various modes of operation for the system products under development. Conditions (e.g.,
environmental, configuration, operational, etc.) that determine the modes of operation should be
included in this definition.
Task 13. Technical Performance Measures (TPMs)
Identify the key indicators of system performance that will be tracked during the design process.
Selection of TPMs should be limited to critical technical thresholds and goals that, if not met, put
the project at cost, schedule, or performance risk.
TPMs involve tracking the actual versus planned progress of KPPs such that the manager can make
judgments about technical progress on a by-exception basis. To some extent TPM selection is
phase dependent. They must be reconsidered at each systems engineering process step and at the
beginning of each phase.
Task 14. Physical Characteristics
Identify and define required physical characteristics (e.g., color, texture, size, weight, buoyancy)
for the system products under development. Identify which physical characteristics are true con-
straints and which can be changed, based on trade studies.
Task 15. Human Factors
Identify and define human factor considerations (e.g., physical space limits, climatic limits, eye
movement, reach, ergonomics) which will affect operation of the system products under develop-
ment. Identify which human systems integration are constraints and which can be changed based
on trade studies.
Задача 10. Функциональные требования
Определите то, что система должна выполнить или должна быть в состоянии сделать. Функции, идентифицированные через, требуют -
анализ ments будет далее анализироваться во время функционального анализа и выделения.
Задача 11. Требования к производительности
Определите требования к производительности для каждой высокоуровневой функции, выполняемой системой. Основное внимание должно быть помещено в требования к производительности, которые адресуют MOEs и другой KPPs, установленный в планах тестирования или идентифицированный как элементы интереса полномочиями контроля.
Задача 12. Режимы работы
Определите различные режимы работы для разрабатываемых системных продуктов. Условия (например,
экологический, конфигурация, операционная, и т.д.), которые определяют, режимы работы должны быть
включенный в это определение.
Задача 13. Меры по техническим показателям (TPMs)
Идентифицируйте основные индикаторы производительности системы, которая будет прослежена во время процесса проектирования.
Выбор TPMs должен быть ограничен критическими техническими порогами и целями, которые, если не встреченный, помещают
проект по стоимости, расписание или риск производительности.
TPMs включают отслеживание фактического по сравнению с запланированным прогрессом KPPs, таким образом, что менеджер может сделать
суждения о техническом прогрессе на основе исключением. В некоторой степени выбор TPM
зависимая фаза. Они должны быть пересмотрены на каждом этапе процесса системного проектирования и на
начало каждой фазы.
Задача 14. Физические характеристики
Идентифицируйте и определите требуемые физические характеристики (например, цвет, текстура, размер, вес, плавучесть)
для разрабатываемых системных продуктов. Идентифицируйте, какие физические характеристики - истинный довод "против" -
straints и который может быть изменен, на основе торговых исследований.
Задача 15. Человеческие факторы
Идентифицируйте и определите соображения человеческого фактора (например, пределы физического пространства, климатические пределы, глаз
перемещение, достигните, эргономика), который будет влиять на работу системных продуктов под, разрабатывают -
ment. Идентифицируйте, какая человеческая системная интеграция ограничения и который может быть изменен базируемый
на торговых исследованиях.