Воркшоп (Workshop). План и пример воркшопа

Скачать План воркшопа по GCI.docx
Воркшоп – это коллективное обучающее мероприятие, участники которого получают новые знания и навыки в процессе динамической групповой работы. Одной из нескольких целей воркшопа является уточнение требований к продукту.

План воркшопа «Приложение с аналитикой по магазинам — GCI»

Цели и границы

Цели воркшопа:

  1. Ознакомиться более подробно с приложением GCI.
  2. Понять, какие возможности использования имеются у приложения.
  3. Выявить дополнительные требования, которые не удовлетворены этим приложением. Другими словами понять объем и направление необходимых доработок.

Границы:

  1. Целью воркшопа является верхнеуровневые требования к аналитике, т.е. без погружения в формулы KPI.
  2. Какие KPI подходят, какие KPI нужны, какой уровень детализации данных нужен в приложении.
  3. Приложения содержат ограниченный набор исторических данных (1 день, по нескольким магазинам), т.к. слабый сервер.

Ожидаемый конечный результат: Понять насколько полезным является приложение GCI для бизнес-подразделения и насколько аналитика в таком виде полезна. Выявить дополнительные требования к приложению анализа данных по магазинам.

Продолжительность:3 часа

Целевая аудитория: Аналитики отдела снабжения и закупок

Состав воркшопа

Этап 1 «Общая вводная по приложениям GRI и GCI»

Общий этап для двух воркшопов по приложениям GRI и GCI.

Описание результатов и дополнительных требований (см. План воркшопа по GRI).

Этап 2 «Обзор приложения GСI и выявление дополнительных требований»

Предполагаемая продолжительность 3 часа
Цели 1. Получить подробное представление о возможностях приложения GCI;
2. Выявить дополнительные требования к приложению;
3. Оценить достаточность детализации данных;
4. Оценить группировку данных;
5. Оценить достаточность данных для аналитики по магазинам.
Подпункты этапа ——————————————————————————————-
· Шаг 1 Обзор видов анализа в приложении GСI
· Шаг 2 Обзор дашборда приложения GCI (панель с группами KPI)
· Шаг 3 Обзор видов анализа для каждой группы KPI
· Шаг 4 Обсуждение табличного и графического представления данных
· Шаг 5 Обзор показателей в графическом и табличном представлении данных
· Шаг 6 Выявление дополнительных требований:
· Количество пользователей
· Дополнительные KPI
· Интеграция с другими источниками данных (помимо GOLD)
· Требования к скорости доработки приложений
· Требования по ограничению видимости данных разным пользователям
· Требования к объему данных

Описание результатов и дополнительных требований:

Оценка приложения

Приложение GCI оценивается каждым участником в отдельности и затем считается общий балл.

Складская аналитика в приложении GCI 1 = Плохо

5 = Отлично

Участник воркшопа:
1 Глубина детализирования данных для складской аналитики
2 Достаточность показателей KPI
3 Достаточность исторических данных
4 Возможность использования приложения GCI без дополнительных доработок
5 Удобство интерфейса для анализа
6 Общее впечатление от приложения GCI
7 Удовлетворенность параметрами перезагрузки данных (1 раз в сутки, ночью)
ИТОГОВАЯ ОЦЕНКА (сумма/количество):
Дополнительные комментарии:

Скачать План воркшопа по GCI.docx


Пояснение принципа прослеживания требований

Сбор и анализ требований

Сбор и анализ требований

Первые 90% работы отнимают
10% времени, а последние 10%
— оставшиеся 90% времени.
Правило 90/90

Все требования к проектируемой системе предлагается размещать на нескольких иерархических уровнях. На самом нижнем уровне располагаются требования, которые одинаково подходят для автоматизации технологических процессов в целом без учета особенностей конкретной прикладной области. Здесь необходимо обратиться к ГОСТам и другим нормативным документам. Далее следует уровень требований к автоматизированной системе определенного (заданного) класса с учетом соответствующих нормативных документов, определяющих порядок и описание заданного технологического процесса. И наконец, третий уровень составляют требования к конкретной системе. Кроме того, в стандарте IEEE 830-1993 Спецификация требований к ПО (Software Requirements Specification – SRS) проведено деление всех требований на две группы. Первая группа документирует потребности заказчика и записывается на языке, понятном заказчику – это т.н. С-требования. Вторая группа документирует требования в специальной, структурированной форме. Этот документ называют требованиями разработчика, или D-требованиями.

В ГОСТ 24.103-84 «Автоматизированные системы управления. Основные положения» перечислены общесистемные принципы, которые необходимо соблюдать при создании АСОИУ:

  1. системность – заключается в том, что при создании, функционировании и развитии АСУ должны быть установлены и сохранены связи между структурными элементами, обеспечивающие ее целостность;
  2. развитие – заключается в том, что АСУ должна создаваться с учетом возможности пополнения и обновления функций и видов ее обеспечения путем доработки программных и (или) технических средств или настройкой имеющихся средств;
  3. совместимость – заключается в обеспечении способности взаимодействия АСУ различных видов и уровней в процессе их совместного функционирования;
  4. стандартизация и унификация – заключается в рациональном применении типовых, унифицированных и стандартизованных элементов при создании и развитии АСУ;
  5. эффективность – заключается в достижении рационального соотношения между затратами на создание АСУ и целевыми эффектами, получаемыми при ее функционировании.

Кроме того, в п.3.4. ГОСТ 24.103-84 при создании АСУ рекомендуется максимально использовать типовые проектные решения, пакеты прикладных программ, унифицированные пакеты а также применять для новых объектов управления ранее созданные проекты АСУ. Это положение полностью соответствует принципам инженерии ПО, в особенности, концепции повторного использования компонентов.
ГОСТ 24.104-85 «Автоматизированные системы управления. Общие требования» устанавливает требования к каждому виду обеспечения отдельно. Перечислим те из них, на которые нужно обратить внимание.

Требования к программному обеспечению:

  1. В АСУ должны быть преимущественно использованы системы управления базами данных (СУБД), зарегистрированные в установленном порядке.
  2. Программное обеспечения АСУ должно иметь средства диагностики технических средств АСУ и контроля на достоверность входной информации.
  3. В программном обеспечении АСУ должны быть реализованы меры по защите от ошибок при вводе и обработке информации, обеспечивающие заданное качество выполнения функций АСУ.

Требования к информационному обеспечения АСУ

  1. Форма представления выходной информации АСУ должна быть согласована с заказчиком (пользователем) системы.
  2. В АСУ должны быть предусмотрены необходимые меры по контролю и обновлению данных в информационных массивах АСУ, восстановлению массивов после отказа каких-либо технических средств АСУ, а также контролю идентичности одноименной информации в базах данных.

Требования безопасности

  1. Неправильные действия персонала АСУ не должны приводить к аварийной ситуации.

Особую роль среди общесистемных требований играют требования к надежности и безопасности.

Кроме сбора требований особое значение имеет процесс управления требованиями. В технологии Rational Unified Process определяются пять уровней зрелости процесса управления требованиями:

  1. требования записаны в согласованном формате;
  2. требования организованы, используются стандартные форматы и метаданные о требованиях, поддерживается контроль версий;
  3. требования структурированы в соответствии со своими типами (функциональными и нефункциональными);
  4. требования отслеживаются в соответствии с их типом;
  5. требования интегрируются с процессами управления изменениями, моделирования, кодирования и т.д.

Чтобы соответствовать первому уровню, достаточно взять стандартный текстовый редактор или электронную таблицу для хранения требований; при этом принципы их использования разными группами команды разработки не стандартизованы. На втором уровне документы с описанием требований должны иметь согласованный формат, следовать определенной схеме нумерации и контроля версий. Уровень структурированных требований означает переход к созданию стандартных спецификаций с целым рядом атрибутов (приоритет требования, риск, стоимость и др.). Следующие уровни ставят задачу отслеживания зависимостей между различными требованиями, а также их влияния на другие модели в жизненном цикле ПО.

Хорошую спецификацию отличают следующие элементы:

  1. Акцент на деталях и их четкое определение.
  2. Забота о недопущении неверного толкования.
  3. Непротиворечивость внутри данной спецификации и другими спеками.
  4. Логическая взаимосвязь компонентов.
  5. Полнота охвата предмета.
  6. Соответствие нормативным актам.
  7. Соответствие деловой практике.

С-Требования

Требования заказчика к системе (С-требования) фиксируются разработчиками посредством проведения специально организованного опроса-интервью. Но перед этим необходимо идентифицировать пользователей системы, т.е. указать категории лиц, которые должны или гипотетически могут в настоящий момент или в будущем воспользоваться разрабатываемой системой. В зависимости от масштабов системы эта задача может оказаться не тривиальной, поэтому требует особого внимания, поскольку при создании системы необходимо учесть требования всех заинтересованных лиц.

Перед проведением интервью:

  • перечислить и расставить приоритеты в списке интервьюированных;
  • спланировать интервью с фиксированным временем начала и конца;
  • составить глоссарий проекта, в котором перечисляются основные термины предметной области.

Во время интервью:

  • задокументировать требования;
  • составить эскиз графического интерфейса;
  • спланировать следующую встречу.

После интервью:

  • составить черновик С-требований SRS с использованием CASE-инструментов;
  • определить конфигурацию оборудования;
  • передать черновик С-требований заказчику для получения его замечаний.

Рисунок – Порядок составления С-требований
Порядок составления С-требований

Заказчики разрабатывают концепцию, часто подсознательную и неполную того, как их приложение будет работать. Эту концепцию иногда называют моделью приложения, или концепцией работы. Для формализации концепции работы приложения, представленной заказчиком, инженеры могут использовать комбинации следующих технологий:

  • Методология SADT;
  • Диаграммы вариантов использования (use case) UML.
  • Диаграммы последовательности (sequence diagram) UML.
  • Диаграммы состояний (statechart diagram) UML.
  • Прототипирование дизайна пользовательского интерфейса входит в фазу проектирования программного обеспечения, однако его также можно считать и частью фазы формирования требований.

Порядок анализа требований заказчика включает следующие шаги:
1. Если требование простое и не имеет связей с другими требованиями, его выражают четкими предложениями в соответствующем разделе SRS.
2. Если требование представляет собой взаимодействие пользователя и приложения, то его, как правило, выражают с помощью варианта использования. Для этого:
2.1. Задают имена вариантам использования;
2.2. Определяют действующие лица;
2.3. Записывают последовательность действий пользователя и приложения;
2.4. Минимизируют ветвление.
3. Если требование затрагивает элементы обработки, каждый из которых получает и выдает данные, используют диаграмму потоков данных (DFD). При этом:
3.1. Определяют элементы обработки (обычно высокого уровня);
3.2. Определяют хранилища данных;
3.3. Показывают пути передачи данных между обрабатывающими элементами. Указывают типы данных, передаваемых в каждом случае.
4. Если требование затрагивает состояния, в которых может находиться программа (или части программы), строят диаграмму состояний в следующей последовательности:
4.1. Определяют состояния (каждое состояние обычно определяют отглагольным существительным, например «Ожидание»);
4.2. Указывают исходное и конечное состояние.
4.3. Определяют события, происходящие вне рассматриваемой части системы, и приводящие к переходу между состояниями;
4.4. Определяют вложенные состояния.

Как только С-требования собраны, как правило, возникает необходимость обновления SPMP. Такое обновление происходит в течение всего жизненного цикла системы. После анализа С-требований также может быть уточнена оценка стоимости системы.
Задача формулирования и корректного управления требованиями становится нетривиальной, если количество требований исчисляется несколькими десятками.

D-Требования

Разработчикам программного обеспечения нужна база для проектирования и разработки. Эта база представляет собой детальные требования (D-требования). D-требования состоят из полного списка конкретных свойств и функциональности, которую должна иметь программа. Каждое из этих требований пронумеровано, помечено и отслеживается по ходу разработки. D-требования должны быть согласованы с С-требованиями.
Типичная последовательность действий для сбора и документирования D-требований показана на рисунке.

Рисунок – Порядок получения D-требований
Порядок получения D-требований

Существуют несколько типов D-требований:
1. Функциональные требования – определяют работу, которую должно выполнять проектируемая система (например, «приложение будет вычислять стоимость портфеля акций пользователя»).
2. Нефункциональные требования.
2.1. Производительность. Требования к производительности определяют временные ограничения, которые должны быть выполнены в программе. Заказчики и разработчики обсуждают ограничения по времени вычислений, использованию оперативной памяти, объему запоминающих устройств и т. д.
2.2. Надежность и безопасность. Требования надежности определяют надежность в измеряемых величинах. Требования такого типа предполагают вероятность неидеальной работы программы и ограничивают область ее несовершенства. Особое внимание в ПЗ необходимо уделить вопросам обеспечения безопасности системы с учетом возможности искажения данных посредством несанкционированного доступа, сбоя системного или прикладного ПО.
2.3. Обработка ошибок. Эта категория требований объясняет, как программа должна реагировать на возникающие ошибки. Например, что должна делать программа, если она получает сообщение из другой программы в неразрешенном формате? Это не касается ошибок, генерируемых самой программой.
2.4. Интерфейсные требования. Интерфейсные требования описывают формат, в котором программа общается с окружением.
2.5. Ограничения. Ограничения на проектирование или реализацию описывают границы или условия того, как приложение должно быть задумано и разработано. Например, накладываются ограничения на инструменты и языки программирования ввиду сложившихся традиций организации, опыта программистов, совместимости и проч.
3. Обратные требования – это функционал, который система не обеспечивает.

 

Типичная последовательность получения функциональных D-требований с использованием объектно-ориентированного подхода приведена ниже:

1. Процесс начинается с перечисления классов, упомянутых в вариантах использования – это т.н. классы анализа.
2. Полученный набор классов обычно неполон и следует попытаться найти остальные классы предметной области.
3. Для каждого из полученных классов выписывается вся необходимая функциональность программы, за которую отвечает данный класс. Например, «у каждого клиента будет имя» (атрибут класса Клиент) и «программа должна иметь возможность вычислять капитал каждого клиента» (метод класса Клиент). События, которые должны обрабатывать объекты класса, также должны быть определены. В это же время должны быть разработаны и планы тестирования для каждого D-требования.
4. Связи между классами определяются в два этапа:
4.1. Начальный набор связей определяется на основе анализа диаграмм сотрудничества (collaboration) или диаграмм последовательности. Если два объекта взаимодействуют (обмениваются сообщениями), между ними на диаграмме должна существовать связь (путь взаимодействия), которая преобразуется в двунаправленную ассоциацию между соответствующими классами. Если сообщения между некоторой парой объектов передаются только в одном направлении, то для соответствующей ассоциации вводится направление навигации.
4.2. Анализируются и уточняются ассоциации между классами-сущностями. Задаются мощности ассоциаций, могут использоваться множественные ассоциации, агрегации, обобщения и ассоциации-классы.
5. D-требования проверяются и сравниваются с С-требованиями.
6. D-требования проверяются заказчиком и, затем, публикуются.

Особое внимание необходимо уделить вопросу получения классов анализа, поскольку – это творческий процесс, тесно связанный с анализом информации о предметной области.

При получении классов анализа необходимо учитывать следующие аспекты:

  1. Класс анализа является четкой абстракцией, моделирующей один конкретный элемент предметной области. Он должен имеет от 3-х до 5-ти операций. Все свойства класса служат реализации его назначения. Однако для реализации своего назначения класс должен иметь минимальное количество связей с другими классами.
  2. В классах анализа содержаться только ключевые атрибуты и операции, определенные на очень высоком уровне абстракции. Как правило, каждая операция уровня анализа затем разбивается на несколько операций уровня проекта.
  3. Необходимо избегать глубоких деревьев наследования (3 и более уровней), поскольку частой ошибкой при построении иерархии наследования является использование функциональной декомпозиции, где каждый уровень абстракции имеет только одну операцию. Наследование использует только там, где есть явная иерархи наследования, вытекающая непосредственно из предметной области.
  4. При выявлении классов посредством анализа текста С-требования, существительные указывают на классы или атрибуты, а глаголы служат признаком операций. Однако синонимы и омонимы могут стать причиной появления ложных классов.
  5. При выявлении классов совместно с пользователями часто используют т.н. CRC(Class-Responsibilities-Collaborators)-анализ с помощью стикеров и мозговой штурм.

Без возможности четкого контроля каждого требования от проекта до программного кода, реализующего это требование, было бы сложно убедиться в том, что программа разработана в соответствии с установленными требованиями. Когда требования меняются (чего следует ожидать), это становится еще сложнее. Возможность отображать каждое требование на соответствующие части проекта и программы называется прослеживанием.
Один из способов, помогающих обеспечить прослеживание, заключается в отображении каждого функционального D-требования на конкретную функцию целевого языка. На рисунке демонстрируется обеспечение принципа прослеживания для некоторого требования №NNN «Поиск учебно-методических материалов (УММ)»:

  1. С-требования, сформулированные заказчиком при проведении анкетирования (или интервью), отображаются на диаграмме вариантов использования;
  2. на этапе проработки D-требований, каждое С-требование представляется комплектом из трех диаграмм: деятельности, классов и последовательностей;
  3. при проектировании архитектуры системы для удовлетворения требования №NNN в некотором классе слоя предметной области предусматривается соответствующий метод(ы) (например, «findByAuthor» и «findByTitle)»;
  4. на стадии детального проектирования прорабатывается алгоритм метода, отвечающего за выполнение требования №NNN, а также создается ER-диаграмма БД и конструируется SQL-запрос(ы), выполнение которого обеспечит удовлетворение данного требования;
  5. на стадии реализации для выполнения требования №NNN разрабатываются листинги соответствующих методов и, наконец, на стадии тестирования выполнение требования №NNN проверяется с использованием составленного плана тестирования.

Рисунок – Пояснение принципа прослеживания
Пояснение принципа прослеживания требований

На протяжении всего процесса проектирования необходимо прилагать усилия по планированию будущего тестирования. Существует несколько преимуществ в написании тестов одновременно с требованиями.
Во-первых, это позволяет прояснить требование.
Во-вторых, это переносит некоторую часть работы из фазы тестирования проекта в фазу разработки требований. Пусть, например, SRS включает в свой состав D-требование №NNN следующего содержания: «NNN. ФИО каждого студента информационной системы «Деканат» будет представлять собой строку символов от 1 до 256». C целью планирования процедуры тестирования необходимо составить проект плана тестирования, примерная форма которого может быть представлена в виде таблицы .

Таблица «Тестовые данные для проверки D-требования №nnn»

№ п/п Входные тестовые данные Ожидаемый результат
1 Иванов Иван Иванович Иванов Иван Иванович
2 length()<10 Сообщение с вопросом о корректности вводимых данных
3 length()>256 Сообщение с вопросом о корректности вводимых данных
4

При формировании требований к АСОИУ необходимо обеспечить достижение ряда показателей, среди которых наиболее значимыми являются: прослеживание, полнота, согласованность и т.д. Набор D-требований согласован, если между требованиями нет противоречий. По мере увеличения числа D-требований согласованность может стать труднодостижимой, но объектно-ориентированная организация требований помогает избежать несогласованности благодаря классификации D-требований по классам и с помощью разложения их на простейшие составляющие.
С целью проверки указанных характеристик составляют таблицу, форма которой приведена на рисунке:

Рисунок «Шаблон таблицы для проверки D-требований»
Шаблон таблицы для проверки D-требований

Во втором столбце таблицы приводится идентификатор D-требования. В столбце 3 приводится идентификатор С-требования, в состав которого входит данное D-требование. В столбце 4 приводятся идентификаторы D-требований, выполнение которых необходимо и достаточно для реализации данного D-требования. В столбце 5 делают отметку, если данное D-требование не противоречит никакому другому D-требованию из перечисленных в таблице. В столбце 6 делают отметку, если данное D-требование может быть реализовано с учетом ограничений, накладываемых другими С- или D-требованиями, средой разработки, аппаратной платформой и т.д.

В столбце 7 делают отметку, если данное D-требование не может быть истолковано двояко. В столбце 8 делают отметку, если данное D-требование сформулировано предельно просто. В случае отсутствия отметки необходимо привести дополнительные разъяснения по содержанию такого требования. В столбце 9 делают отметку, если в данном требовании указаны допустимые отклонения от необходимого результата. В столбце 10 делают отметку, если формулировка данного D-требования не претерпит существенных изменений при возникновении в будущем необходимости наращивания функциональных возможностей системы. В столбце 11 делают отметку, если для данного требования составлен план тестирования. В столбце 12 делают отметку по окончании реализации данного D-требования в виде программного кода.

Порядок разработки каждого D-требования показан выше на рисунке и включает следующие шаги:

  1. Предварительный анализ требования:
    1. Классификация требования как функциональное или нефункциональное (рекомендуется использовать подсказки IEEE SRS для большинства нефункциональных требований);
    2. выбор метода организации функциональных требований.
  2. Обеспечение прослеживания требования. Убедиться в возможности прослеживания при проектировании и реализации.
  3. Обеспечение тестируемости требования. Спланировать конкретный тест, устанавливающий выполнение требования.
  4. Проверка недвусмысленности требования.
  5. Назначение требованию приоритет. Например, высокий («важно»), средний («желательно») или низкий («не обязательно»).
  6. Проверка полноты требования. Для каждого требования следует убедиться в присутствии всех остальных необходимых или сопутствующих требований.
  7. Добавление состояния ошибки:
    1. сформулировать, что требуется выполнить при возникновении нештатных ситуаций;
    2. в критичных местах добавить состояния ошибок программирования.
  8. Проверка согласованности. Необходимо убедиться, что ни одно требование не противоречит каким-либо аспектам другого требования.

Как только все D-требования собраны, необходимо обновить SPMP и передать D-требования под управление конфигурациями.
Для формализации и детальной фиксации требований рекомендуется использовать спецификацию требований к программному обеспечению (Software Requirements Specification — SRS) в соответствии со стандартом IEEE 830-1993.


Подходы к управлению требованиями, Лешек А. Мацяшек

Страница разрабатывается

Описание книги

В книге описывается методология и технология объектно-ориентированной разработки современных информационных систем (ИС) и предлагается итеративный подход к разработке ИС с пошаговым наращиванием их возможностей. Весь комплекс вопросов анализа и проектирования ИС рассматривается в контексте использования языка UML.

Описание типов требований

Документ описания требований
1. Предварительные замечания к проекту
1.1. Цели и рамки проекта
1.2. Деловой контекст
1.3. Участники проекта
1.4. Идеи в отношении решений
1.5. Обзор документа
2. Системные сервисы
2.1. Рамки системы
2.2. Функциональные требования
2.3. Требования к данным
3. Системные ограничения
3.1. Требования к интерфейсу
3.2. Требования к производительности
3.3. Требования к безопасности
3.4. Эксплуатационные требования
3.5. Политические и юридические требования
3.6. Другие ограничения
4. Проектные вопросы
4.1. Открытые вопросы
4.2. Предварительный план-график
4.3. Предварительный бюджет
Приложения
Глоссарий
Деловые документы и формы
Ссылки

Три группы моделей спецификаций требований:
1. Модели состояний — детализируют требования к данным
— Моделирование классов
— Моделирование ассоциаций
— Моделирование отношений агрегации и композиции
— Моделирование отношений обобщения
— Моделирование объектов
2. Модели поведения — модели поведения обеспечивают детализированные спецификации для функциональных требований
— Моделирование прецедентов
— Моделирование видов деятельности
— Моделирование взаимодействий
— Моделирование открытых интерфейсов
3. Модели изменения состояний — охватывают два вида требований. Они призваны объяснить, каким образом действие функций приводит к изменению данных.
— Моделирование состояний объектов

Методы сбора требований

Традиционные методы выявления требований:
— Интервьюирование заказчиков и экспертов в проблемной области
— Анкетирование
— Наблюдение
— Изучение документов и программных систем

Современные методы выявления требований:
— Прототипирование
— Совместная разработка приложений (JAD-метод)
— Быстрая разработка приложений (RAD-метод)


Подходы к управлению требованиями в IBM OpenUP и FURPS+

Страница разрабатывается

Описание методологии

Инфраструктура разработки программного обеспечения, которая строится на методах гибкой разработки с использованием унифицированного процесса Rational (Rational Unified Process). OpenUP — это экономичный унифицированный процесс, использующий принципы итеративности и инкрементальности в рамках структурированного жизненного цикла.

FURPS — классификация требований к программным системам. Требования были разработаны и представлены Hewlett-Packard. В настоящее время используется аббревиатура FURPS+.

Описание типов требований

Уровни требований

Три уровня требований:
1. Уровень концепции
Модель бизнес-процесса
Потребности заинтересованных лиц
Словарь предметной области
Бизнес-правила (ограничения)

2. Уровень пользователя
Функции системы
Варианты использования
Нефункциональные требования

3. Уровень системы
Эскизы интерфейса пользователя
Раскадровка

Требования в модели FURPS+

Модель «FURPS+» — функциональные, нефункциональные и вспомогательные требования:

Функциональные требования
— Функции системы
— Требования по аудиту системы
Есть ли необходимость в том, чтобы отслеживать, кто, когда и как использует систему?
— Требования по лицензированию
Будет ли система или её части лицензироваться? Если в системе будет использоваться
открытое ПО, то все ли соглашения могут быть соблюдены?
— Требования к функции печати
Будет ли доступна функция печати?
— Требования к отчетности
— Требуется ли функция генерации отчётов?
— Требования по безопасности
Будет ли контролироваться вход в систему? — аутентификация пользователей
Требуется ли защита системы или ее данных?

Нефункциональные требования
— Требования удобства использования
— Требования надежности
— Требования производительности

— Требования по обеспечению технической поддержкой
— Ограничения

Вспомогательные требования

Модель FURPS+ (Robert Grady at Hewlett-Packard):
— Функциональные требования (Functionality)
— Требования удобства использования (Usability)
— Требования надежности (Reliability)
— Требования производительности (Performance)
— Требования возможности сопровождения (Supportability)

Символом «+» обозначены дополнительные условия, к которым относятся:
— проектные ограничения
— требования управления системой
— требования к графическому интерфейсу пользователя
— физические требования
— юридические требования

Дополнительные требования:
— Требования к лицензированию
— Требования к документированию

Architect’s Checklist: A Guide to FURPS+

Functionality

  • The value added purpose of the product. Also…
  • Connectivity – protocols (e.g. Bluetooth), or re-sync of offline clients
  • Interoperability – inter-app platform and language independence
  • Extensibility, Expandability – plugins, late binding
  • Composability – service or message oriented considerations, governance
  • Manageability – administration of fielded product
  • Licensing

Usability

  • Ergonomics – human factors engineering
  • Look and Feel – along with branding instancing
  • Accessibility – special needs accommodation
  • Localization — adding language resources
  • Documentation

Reliability

  • Accuracy – the correctness of output
  • Availability – mean time between failures
  • Recoverability – from partial system failures
  • Verifiability – (contractual) runtime reporting on system health
  • Survivability – continuous operations through disasters (earthquake, war, etc.)

Performance

  • Efficiency – of space (bandwidth, RAM, etc)
  • Responsiveness – time constraints
  • Scalability – well handling under increased load
  • Speed — Throughput. Latency.

Supportability:

  • Maintainability (i.e. “build-time” issues)
  • Testability – at unit, integration, and system levels
  • Buildability – fast build times, versioning robustness
  • Portability – minimal vendor or platform dependency
  • Reusability – of components
  • Brandability — OEM and partner support
  • Internationalization – prep for localization

Serviceability (i.e. “run-time” issues)

  • Continuity – administrative downtime constraints
  • Configurability/Modifiability – of fielded product
  • Installability, Updateability – ensuring application integrity
  • Deployability – mode of distributing updates
  • Restorability — from archives
  • Logging – of event or debug data

Security: Confidentiality Preservation, Access Control, Non-repudiation (Integrity Verification, Authenticity Verification – PKI), Identity Verification (logon paradigm), Availability of Service, Auditing Evidence.

Методы сбора требований

  • Мозговой штурм
  • Интервьюирование пользователей
  • Погружение в среду пользователя
  • Изучение аналогов
  • Изучение «книги жалоб и предложений»
  • Разговор с командой поддержки
  • Изучение усовершенствований, сделанных пользователями
  • Совместный семинар
  • Демонстрация прототипа заинтересованным лицам

Подходы к управлению требованиями, Алистер Коберн

Страница разрабатывается

Описание книги

Книга содержит общее введение в написание вариантов использования и подробное описание составных частей варианта использования.

Классификация требований

Приемлемая схема требований
1. Цель и область действия
1.1. Что представляют собой общая область действия и цель?
1.2. Участники (Кого это интересует?)
1.3. Что входит в область действия и что нет?
2. Используемые термины/Глоссарий
3. Варианты использования
3.1. Основные действующие лица и их общие цели
3.2. Варианты использования для бизнес-процессов
3.3. Системные варианты использования
4. Используемая технология
4.1. Какие технологические требования предъявляются к данной системе?
4.2. С какими системами будет взаимодействовать данная система, каковы требования?
5. Другие требования
5.1. Процесс разработки
5.1.1. Кто участвует в проекте?
5.1.2. Какие оценки проекта будут отражены (простой, ранний, быстрый или гибкий)?
5.1.3. Какая обратная связь или прозрачность проекта нужна пользователям и организаторам?
5.1.4. Что мы можем купить, что должны построить, с кем конкурируем?
5.1.5. Какие еще существуют технологические требования (тестирование, установка и т.д.)?
5.1.6. От чего зависит развитие проекта?
5.2. Бизнес-правила
5.3. Производительность
5.4. Эксплуатация, безопасность, документация
5.5. Использование (простота использования)
5.6. Сопровождение и мобильность
5.7. Нерешенные или отложенные вопросы
6. Людские резервы, правовые, политические, организационные вопросы
6.1. Как влияют людские резервы на функционирование системы?
6.2. Какие существуют правовые и политические требования?
6.3. Какие последствия для людей будет иметь создание этой системы?
6.4. Каковы требования к обучению?
6.5. Какое влияние оказывает система на окружающее сообщество?

Методы сбора требований

не описаны


Подходы к управлению требованиями, Вигерс Карл

Страница разрабатывается

Описание книги

Книга посвящена разработке качественных требований к продукту. В ней описаны дюжины проверенных на практике способов выявления, формулирования, разработки, проверки, утверждения и тестирования требований к ПО, которые помогут разработчикам ПО, менеджерам и маркетологам создать эффективное ПО.

Описание требований

Три уровня требований к ПО:

  • Бизнес-требования
  • Требования пользователей
  • Функциональные требования

Бизнес-требования (business requirements) содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга. Бизнес-требования формулируют в документе об образе и границах проекта — уставе проекта (project charter), или документом рыночных требований (market requirements document). Определение границ проекта представляет собой первый этап управление общими проблемами расползания границ.
Требования пользователей (user requirements) описывают цели и задачи, которые пользователям позволит решить система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие — отклик». Таким образом, в этом документе указано, что клиенты смогут делать с помощью системы.
Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда именуемые требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
Термином системные требования (system requirements) обозначают высокоуровневые требования к продукту, которые содержат многие подсистемы, то есть система (IEEE, 1998с). Говоря о системе, мы подразумеваем программное обеспечение или подсистемы ПО и оборудования. Люди — часть системы, поэтому определенные функции системы могут распространяться и на людей.
Бизнес-правила (business rules) включают корпоративные политики,правительственные постановления, промышленные стандарты и вычислительные алгоритмы. Бизнес-правила не являются требованиями к ПО, потому что они находятся снаружи границ любой системы ПО. Однако они часто налагают ограничения, определяя, кто может выполнять конкретные варианты использования, или диктовать, какими функциями должна обладать система, подчиняющаяся соответствующим правилам. Иногда бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональности. Следовательно, вы можете отследить происхождение конкретных функциональных требований вплоть до соответсвующих им бизнес-правил.
Нефункциональные требования содержат цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся легкость и простота использования, легкость перемещения, целостность, эффективность и устойчивость к сбоям. Другие нефункциональные требования описывают внешние взаимодействия между системой и внешним миром, а также ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта.

Функциональные требования:
Бизнес-требования
Требования пользователей
Системные требования
Функциональные требования

Нефункциональные требования:
Бизнес-правила
Атрибуты качества
Внешний интерфейс
Ограничения

Методы сбора требований

Фокус-группы типичных пользователей
Проведение совместных семинаров
Наблюдение за пользователями на рабочих местах
Изучение отчетов о проблемах работающих систем с целью поиска новых идей
Повторное использование требований в разных проектах


Подходы к управлению требованиями, Элизабет Халл

Страница разрабатывается

Описание книги

В книге описан процесс разработки и управлениями требованиями, также подробно рассмотрены основные методы моделирования требований.

Классификация требований

Требования в системной инженерии:
— Пользовательские требования
Определяет — что пользователь желает достичь с помощью создаваемой системы. Следует избегать формулировки конкретных решений.
— Системные требования
Абстрактно определяет — как система будет удовлетворять пользовательским требованиям. Следует избегать точных описаний реализации предлагаемых решений.
(Системные требования — Архитектура системы) Определяет — как конкретная архитектура системы будет удовлетворять системным требованиям.
— Требования к подсистемам
— Требования для компонентов

Методы сбора требований

Источники пользовательских требований
— Интервью с представителями заинтересованных сторон
— Сценарии использования (обычно получаемые в результате интервью)
— Описательная документация (например, различные отчеты, анализ рынка)
— Действующие системы, которые необходимо модернизировать
— Проблемы, обнаруженные в существующих системах, и идеи как их исправить
— Опыт работы с аналогичными системами
— Разного рода прототипы, макеты, эскизы, т.д. продукта или самых требований
— Возможности новых технологий (согласованные с заинтересованными сторонами)
— Результаты исследований
— Опросы
— Наблюдение за работой персонала или изучение видеозаписей их работы


Подходы к управлению требованиями в REBOK

Страница разрабатывается

Описание стандарта

Свод знаний по инжинирингу требований — Requirements Engineering Body Of Knowledge (REBOK), который разрабатывается в японском университете Nanzan University группой под руководством профессора Mikio Aoyama на основе различных мировых стандартов по бизнес-анализу.

Классификация требований

APSEC: REBOK — Requirements Engineering Body Of Knowledge

3 Уровня требований:
Business/Product: Capability and Related Aspects of a Business
— Business Strategy
— Business Case
— Business Rule
— Law
— Business Environment
— Business Process
System: Including Hardware and Software
— System-In-Use
— System Goal
— Functions
— QoS/SLA
— Operating Environment
— Operating Scenario
Software: Requirements to be Realized by Software
— Software-In-Use
— Software Goal
— Screen Transition
— Software Environment
— Use Case
— Software Quality
— Functional Requirements
— Non-Functional Requirements

Методы сбора требований

Stakeholder Analysis
Goal Analysis
Scenario Analysis

Collecting User Information
— Observation
— User Profiling
— Life Log

Method to Discover Scenarios and User Stories
— Questionnaire/Interview
— Observation
— RE Workshop
— Documents Analysis

Источник для статьи — презентация REBOK


Подходы к управлению требованиями в PMBOK методологии

Страница разрабатывается

Описание методологии

Свод знаний по управлению проектами PMBoK (Project Management Body of Knowledge) представляет собой сумму профессиональных знаний по управлению проектами. Является Американским национальным стандартом.

Классификация требований

Документация по требованиям
Документация по требованиям описывает, каким образом отдельные требования соответствуют бизнес-потребности в проекте. Требования могут быть сначала описаны высокоуровнево, а затем постепенно детализироваться по мере поступления новой информации о них. До включения в базовый план требования должны стать однозначными (измеримыми и проверяемыми), отслеживаемыми, полными, непротиворечивыми и приемлемыми для ключевых заинтересованных сторон. Формат документа по требованиям может варьироваться от простого документа, перечисляющего все требования, разделенные на категории по заинтересованным сторонам и приоритетам, до более тщательно проработанных форм, содержащих резюме для руководства, подробные описания и приложения.

Компоненты документации по требованиям могут включать в себя, среди прочего:
Бизнес-требования, включая:

  • цели организации и проекта для возможности отслеживания;
  • бизнес-правила для исполняющей организации;
  • руководящие принципы организации.

Требования заинтересованных сторон, включая:

  • воздействие на другие области организации;
  • воздействие на другие субъекты внутри или за пределами исполняющей организации;
  • требования к коммуникациям и отчетности для заинтересованных сторон.

Требования к решению, включая:

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

Требования к проекту, такие как:

  • уровни обслуживания, производительности, безопасности, соответствия и т. д.;
  • критерии приемки.

Требования к переходу.
Допущения, зависимости и ограничения в отношении требований.

Методы сбора требований

Сбор требований — процесс определения, документирования и управления потребностями и требованиями заинтересованных сторон для достижения целей проекта. Ключевая выгода данного процесса состоит в том, что он предоставляет основу для определения и управления содержание проекта, включая содержание продукта.

Интервью

Фокус-группы

Семинары с участием модератора

Методы группового творчества

Мозговой штурм
Метод номинальных групп
Построение ассоциативных карт
Диаграмма сходства
Анализ решений на основе множества критериев

Методы группового принятия решений

Анкеты и опросы

Наблюдения

Прототипы

Бенчмаркинг

Контекстные диаграммы

Анализ документов