ba_knowledge

Что нужно знать и уметь бизнес-аналитику?

Для начала хочу описать как я понимаю профессию бизнес-аналитика. Лично я вижу специализацию бизнес-аналитика в двух плоскостях — в бизнесе и в сфере ИТ. На мой взгляд — это два принципиально разных по навыкам специалиста.

1. Бизнес-аналитик в сфере ИТ

Бизнес-аналитик — это разносторонний специалист, который должен уметь:

  • коммуницировать с различными заинтересованными сторонами (это может быть топ-менеджмент компании, либо мидл-менеджмент)
  • коммуницировать с бизнес-пользователями
  • коммуницировать с членами команды (разработчики, аналитики, менеджеры проектов)
  • использовать различные инструменты для систематизации требований (именно инструменты — почти всегда Excel)
  • знать и уметь предвидеть какие требования нужны для каждого конкретного проекта и кому задавать вопросы
  • уметь правильно формулировать вопросы и «выковыривать» информацию из людей (это очень сложный процесс, особенно когда начинается скрытое сопротивление)
  • проводить интервью по выявлению требований
  • понимать «политику игры» различных заинтересованных сторон и влияние этого процесса на исход проекта
  • видеть влиятельных людей и уметь убеждать их
  • уметь исключать мешающих членов рабочей группы из проекта (того, кто постоянно тратит время команды, либо уводит проект не в ту сторону, желательно перевести на другую деятельность внутри компании и обращаться только за отдельными консультациями)
  • уметь четко формулировать тезисы, делать четкие выводы
  • уметь проводить воркшопы для уточнения требований
  • уметь проводить общие конструктивные собрания (цель собрания, проблема, возможные решения должны описываться до собрания, чтобы исключить лишние бла-бла-бла)
  • понимать принципы построения систем, уметь трансформировать цели проекта в бизнес-требования, а бизнес-требования в функциональные и нефункциональные требования (т.е. трассировка должна быть в таком порядке)
  • быть способным генерировать новые решения
  • знать sql, принципы построения моделей данных, бизнес-процессов
  • знать и уметь использовать визуальные инструменты для представления информации

Советы по оформлению любой документации

1. Всегда пишите документацию для непосвященных людей в концепцию и внутреннее содержание системы, поэтому:

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

2. Как документировать скрипты системы:

  • В документе должно находиться общее концептуальное описание последовательности запусков тех или иных скриптов
  • Можно представить карту вызова скриптов из компонентов системы, можно сделать некую «карту» по скриптам (mindmap)
  • Сами скрипты в документе описывать не надо. Скрипты должны быть самодокументируемыми, т.е. в коде должны быть комментарии, которые заполняются разработчиками (в том числе для разъяснения бизнес-смысла скрипта)

3. Всегда стремитесь к балансу между картинками и текстом. Отсутствие или избыток картинок — не самые лучшие варианты оформления документации

Отношения с подчиненными

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

Как устроиться работать бизнес-аналитиком

1. Открываем HeadHunter;
2. Находим 20 вакансий по бизнес-анализу;
3. Выписываем из них главные пункты, которых ожидают от бизнес-аналитиков;
4. Составляем список 7 наиболее важных (общих для всех вакансий), которыми Вы не владеете;
5. Изучаем быстро за неделю;
6. Идем на собеседование (получаем обратную связь);
7. Учим дальше;
8. Повторяем цикл пунктов 6-7-6-7-… до тех пор, пока не устроитесь;
9. Сначала идите на совеседование в те компании, устроиться в которые Вы не хотите (чтобы не потерять шанс устроиться в хорошие компании при плохом исходе собеседования).


workshop

Воркшоп (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.


ТРИЗ (Теория решения изобретательских задач)

ТРИЗ — Теория решения изобретательских задач

Что такое ТРИЗ?

Теория решения изобретательских задач, или ТРИЗ — область знаний о механизмах развития технических систем и методах решения изобретательских задач. ТРИЗ не является строгой научной теорией, а представляет собой обобщённый опыт изобретательства и изучения законов развития науки и техники. В результате своего развития ТРИЗ вышла за рамки решения изобретательских задач в технической области, и сегодня используется также в нетехнических областях (бизнес, искусство, литература, педагогика, политика и др.).
YouTube Трейлер

  1. Перевыставить задачу (найти суть задачи)
  2. Выставление эталона
    • Подбор примеров (как это уже сделано?)
    • Как бы задача была решена если бы была волшебная палочка?
    • Как решить задачу ничего не делая?
  3. Преодоление технического противоречия

Структура и функции ТРИЗ

Цель ТРИЗ — выявление и использование законов, закономерностей и тенденций развития технических систем.

Основные функции ТРИЗ

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

Вспомогательные функции ТРИЗ

  • Решение научных и исследовательских задач.
  • Выявление проблем, трудностей и задач при работе с техническими системами и при их развитии.
  • Выявление причин брака и аварийных ситуаций.
  • Максимально эффективное использование ресурсов природы и техники для решения многих проблем.
  • Объективная оценка решений.
  • Систематизирование знаний любых областей деятельности, позволяющее значительно эффективнее использовать эти знания и на принципиально новой основе развивать конкретные науки.
  • Развитие творческого воображения и мышления.
  • Развитие творческих коллективов.

Структура ТРИЗ

  • Законы развития технических систем (ТС)
  • Информационный фонд ТРИЗ
  • Вепольный анализ (структурный вещественно-полевой анализ) технических систем
  • Алгоритм решения изобретательских задач — АРИЗ
  • Методы развития творческого воображения

Список приемов устранения технических противоречий

1. Принцип дробления:
а) разделить объект на независимые части;
б) выполнить объект разборным;
в) увеличить степень дробления объекта.

2. Принцип вынесения:
отделить от объекта “мешающую” часть (“мешающее” свойство) или, наоборот, выделить единственно нужную часть (нужное свойство).

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

4. Принцип асимметрии:
а) перейти от симметричной формы объекта к асимметричной;
б) если объект асимметричен, увеличить степень асимметрии.

5. Принцип объединения:
а) соединить однородные или предназначенные для смежных операций объекты;
б) объединить во времени однородные или смежные операции.

6. Принцип универсальности:
объект выполняет несколько разных функций, благодаря чему отпадает необходимость в других объектах.

7. Принцип “матрешки”:
а) один объект размещен внутри другого, который, в свою очередь, находится внутри третьего и т. д.;
б) один объект проходит сквозь полости в другом объекте.

8. Принцип антивеса:
а) компенсировать вес объекта соединением с другим, обладающим подъемной силой;
б) компенсировать вес объекта взаимодействием со средой (за счет аэро- и гидродинамических сил).

9. Принцип предварительного антидействия:
а) заранее придать объекту напряжения, противоположные недопустимым или нежелательным рабочим напряжениям;
б) если по условиям задачи необходимо совершить какое-то действие, надо заранее совершить антидействие.

10. Принцип предварительного действия:
а) заранее выполнить требуемое действие (полностью или хотя бы частично);
б) заранее расставить объекты так, чтобы они могли вступить в действие без затраты времени на доставку и с наиболее удобного места.

11. Принцип “заранее подложенной подушки”:
компенсировать относительно невысокую надежность объекта заранее подготовленными аварийными средствами.

12. Принцип эквипотенциальности:
изменить условия работы так, чтобы не приходилось поднимать или опускать объект.

13. Принцип “наоборот”:
а) вместо действия, диктуемого условиями задачи, осуществить обратное действие;
б) сделать движущуюся часть объекта или внешней среды неподвижной, а неподвижную — движущейся;
в) перевернуть объект “вверх ногами”, вывернуть его.

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

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

16. Принцип частичного или избыточного действия:
если трудно получить 100% требуемого эффекта, надо получить “чуть меньше” или “чуть больше” — задача при этом существенно упростится.

17. Принцип перехода в другое измерение:
а) трудности, связанные с движением (или размещением) объекта по линии, устраняются, если объект приобретает возможность перемещаться в двух измерениях (т. е. на плоскости). Соответственно задачи, связанные с движением (или размещением) объектов в одной плоскости, устраняются при переходе к пространству в трех измерениях;
б) использовать многоэтажную компоновку объектов вместо одноэтажной;
в) наклонить объект или положить его “на бок”;
г) использовать обратную сторону данной площади;
д) использовать оптические потоки, падающие на соседнюю площадь или обратную сторону имеющейся площади.

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

19. Принцип периодического действия:
а) перейти от непрерывного действия к периодическому (импульсному) ;
б) если действие уже осуществляется периодически, изменить периодичность;
в) использовать паузы между импульсами для другого действия.

20. Принцип непрерывности полезного действия:
а) вести работу непрерывно (все части объекта должны все время работать с полной нагрузкой);
б) устранить холостые и промежуточные ходы.

21. Принцип проскока:
вести процесс или отдельные его этапы (например, вредные или опасные) на большой скорости.

22. Принцип “обратить вред в пользу”:
а) использовать вредные факторы (в частности, вредное воздействие среды) для получения положительного эффекта;
б) устранить вредный фактор за счет сложения с другими вредными факторами;
в) усилить вредный фактор до такой степени, чтобы он перестал быть вредным.

23. Принцип обратной связи:
а) ввести обратную связь;
б) если обратная связь есть, изменить ее.

24. Принцип “посредника”:
а) использовать промежуточный объект, переносящий или передающий действие;
б) на время присоединить к объекту другой (легкоудаляемый) объект.

25. Принцип самообслуживания:
а) объект должен сам себя обслуживать, выполняя вспомогательные и ремонтные операции;
б) использовать отходы (энергии, вещества).

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

27. Принцип дешевой недолговечности взамен долговечности:
заменить дорогой объект набором дешевых объектов, поступившись при этом некоторыми качествами (например, долговечностью).

28. Принцип замены механической схемы:
а) заменить механическую схему оптической, акустической или “запаховой”;
б) использовать электрические, магнитные и электромагнитные поля для взаимодействия с объектом;
в) перейти от неподвижных полей к движущимся, от фиксированных — к меняющимся во времени, от неструктурных — к имеющим определенную структуру;
г) использовать поля в сочетании с ферромагнитными частицами.

29. Принцип использования пневмо- и гидроконструкций:
вместо твердых частей объекта использовать газообразные и жидкие: надувные и гидронаполняемые, воздушную подушку, гидростатические и гидрореактивные.

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

31. Принцип применения пористых материалов:
а) выполнить объект пористым или использовать дополнительные пористые элементы (вставки, покрытия и т. д.);
б) если объект уже выполнен пористым, предварительно заполнить поры каким-то веществом.

32. Принцип изменения окраски:
а) изменить окраску объекта или внешней среды;
б) изменить степень прозрачности объекта или внешний среды.

33. Принцип однородности:
объекты, взаимодействующие с данным объектом, должны быть сделаны из того же материала (или близкого ему по свойствам).

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

35. Принцип изменения физико-химических параметров объекта:
а) изменить агрегатное состояние объекта;
б) изменить концентрацию или консистенцию;
в) изменить степень гибкости;
г) изменить температуру.

36. Принцип применения фазовых переходов:
использовать явления, возникающие при фазовых переходах, например, изменение объема, выделение или поглощение тепла и т. д.

37. Принцип применения теплового расширения:
а) использовать тепловое расширение (или сжатие) материалов;
б) использовать несколько материалов с разными коэффициентами теплового расширения.

38. Принцип применения сильных окислителей:
а) заменить обычный воздух обогащенным;
б) заменить обогащенный воздух кислородом;
в) воздействовать на воздух и кислород ионизирующим излучением;
г) использовать озонированный кислород;
д) заменить озонированный кислород (или ионизированный) озоном.

39. Принцип применения инертной среды:
а) заменить обычную среду инертной;
б) вести процесс в вакууме.

40. Принцип применения композиционных материалов:
перейти от однородных материалов к композиционным.

Использование ТРИЗ в IT-технологиях

ТРИЗ начинает активно использоваться в IT-технологиях, особенно используются такие инструменты ТРИЗ, как «устранение технических противоречий», понятие «идеальной системы» и «идеальной программы». ТРИЗ критериями качественной разработки являются увеличение функциональности при одновременном сокращении программного кода; возможность сопровождения разработанной программы специалистом с меньшей квалификации, чем ее разработчик.


requirements_gathering

10 правил для успешного сбора требований

Elicitation (Выявление) — это деятельность по вытягиванию информации из заинтересованных сторон и других источников.

Requirements gathering (Сбор требований) является неотъемлемой частью любого проекта. Понимание того, какую ценность должен поставить проект — критическая составляющая успеха проекта. Сбор требований звучит как здравый смысл, но этой области отводится слишком мало внимания.

10 правил для успешного сбора требований:
— Не предполагайте, что Вы знаете, что хочет клиент — всегда спрашивайте;
— Привлекайте пользователей с самого начала;
— Сформулируйте и согласуйте рамки (объем) проекта;
— Убедитесь что требования удовлетворяют технике SMART — Конкретные, измеримые, согласованные, реалистичные и имеют временные границы;
— Проясняйте любые сомнения (через общение);
— Создайте четкий, краткий и исчерпывающий перечень документов и поделитесь им с заказчиком;
— Подтвердите Ваше понимание требований компании (воспроизведите их);
— Избегайте разговоров о технологиях или решениях до тех пор, пока требования не будут полностью поняты;
— Получите требования, согласованные с заинтересованными сторонами до начала проекта;
— Создайте прототип, если необходимо подтвердить или уточнить требования заказчика.


requirements

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


Бизнес-анализ — это структурированное изучение проблемы, имеющей отношение к бизнесу. Бизнес-анализ проводится, чтобы лучше понять проблему, а затем оценить, что требуется для ее устранения.
Бизнес-кейс/коммерческое предложение. Коммерческая цель или выгода является причиной выполнения проекта и может официально фиксироваться в документе, называющемся бизнес-кейсом, или коммерческим предложением. Этот документ обычно включает финансовые показатели (например, прирост выручки, снижение издержек и т.п.) или другие параметры (например, повышение уровня обслуживания потребителей, повышение мотивированности персонала и т.д.).

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

Прежде чем начинать проект, обязательно нужно знать, какой результат (продукт) вы хотите получить. И порой этот продукт необходимо описать самым тщательным образом. Иными словами, нужно знать, какие требования заказчик предъявляет к продукту. Полный набор этих требований называют каталогом требований, или спецификацией.
Крупные и сложные проекты обычно насчитывают тысячи требований. Бизнес-анализ как раз и позволяет выявлять проблемы и определять, что требуется для их преодоления. В крупных проектах, таких, как разработка программного обеспечения, сбор требований является одним из важнейших этапов жизненного цикла проекта, котоорыый может занять несколько недель/месяцев.
Для выявления требований проводится серия структурированных интервью с заказчиками, которые позволяют точно определить их пожелания к готовому продукту. Попытка напрямую узнать у заказчика, какие результаты ему нужны, может закончится крахом: заказчик станет выдвигать все новые и новые требования, так что вы просто будете не в силах их удовлетворить. Помните, любое требование влияет на продолжительность и стоимость проекта. Соответственно, получая подробный список требований, вам нужно знать, являются ли они:

  • обязательными, т.е. без них проект будет считаться незавершенным, а заказчик останется неудовлетворенным. Если готовый продукт не соответствует всем обязательным требованиям, это — провал;
  • желательными. Эти требования не обязательны, но важны для заказчика, поэтому их стараются соблюдать, за исключением тех случаев, когда они влекут за собой неприемлемое увеличение стоимости или продолжительности проекта;
  • необязательными — это те требования, без которых заказчик вполне может обойтись и которые удовлетворяются только по возможности.

Выжимка по процессу формирования требований

Функциональные требования — это требования к системе.
Бизнес-требования — эквивалентно бизнес-целям.
Между ними — Пользовательские требования, User Requirements.
Пользовательские требования формулируются в терминах предметной области, а функциональные требования — в терминах системы.

Бизнес-процессы — самое начало работы.
Например, можно рассмотреть процессы RUP/MSF (упрощенная последовательность):
1. Бизнес-моделирование
2. Выявление требований
3. RUP: Анализ и проектирование, MSF: концептуальный, логический и физический дизайн
4. Реализация
5. Тестирование
6. Опытно-промышленная эксплуатация
7. Support и развитие системы

Совсем упрощенно:
1. От заказчика поступает начальная концепция системы (в нескольких предложениях что они хотят, что это позволит достигнуть и т.д.) — по сути это и есть бизнес-требования.
2. Приступаем к моделированию бизнес-процессов, которые хотим автоматизировать (тут в помощь нам ARIS, IDEF0/IDEF3, UML), возможно, строим дополнительную модель (оптимизированную), в которой будут прописаны бизнес-процессы после автоматизации.
3. Вытрясаем из заказчика требования к разрабатываемой системе (это будут пользовательские требования).
4. На основе пользовательских требований формулируем функциональные требования к системе (пользовательские требования — не единственный источник функциональных требований).

Типовая структура требований выглядит как «Система должна … /утверждение о необходимом функциональном поведении системы/» или «система должна позволять … /утверждение о возможности, предоставляемой пользователю или внешней системе/.

Например:
«Система должна вести журнал всех действий пользователя» или «Система должна позволять создавать новые Проекты».

Пример различий между пользовательскими и функциональными требованиями:
Пользовательское: «Система должна выводить отчеты на печать»
Функциональное: «Система должна обеспечивать вывод отчетов на печать, обеспечивать возможность выбора и настройки локального или сетевого принтера, выбора ориентации бумаги».

Пользовательские и функциональные требования как правило связаны между собой. Это необходимо для отслеживания зависимостей требований друг от друга. В системах управления требованиями (например, Borland CaliberRM, TelelogicDoors, Rational RequisitePro) для этого есть так называемые «матрицы трассировки», на которых графически стрелками показываются зависимости между требованиями.

Важно сохранять пользовательские требования для хранения их в первоначальном виде, отслеживания источника их возникновения (вплоть до конкретного лица), расстановки их приоритетов (с точки зрения пользователя) и т.д.

Схема процесса разработки с уровнями требований

requirement_management

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

Анализ предметной области. Аналитики должны изучить предметную область, где будет эксплуатироваться система.
Сбор требований. Это процесс взаимодействия с лицами, формирующими требования. Во время этого процесса продолжается анализ предметной области.
Классификация требований. На этом этапе бесформенный набор требований преобразуется в логически связанные группы требований.
Разрешение противоречий. Без сомнения, требования многочисленных лиц, занятых в процессе формирования требований, будут противоречивыми. На этом этапе определяются и разрешаются противоречия такого рода.
Назначение приоритетов. В любом наборе требований одни из них будут более важны, чем другие. На этом этапе совместно с лицами, формирующими требования, определяются наиболее важные требования.
Проверка требований. На этом этапе определяется их полнота, последовательность и непротиворечивость.

Аттестация требований

Аттестация должна продемонстрировать, что требования действительно определяют ту систему, которую хочет иметь заказчик. Проверка требований важна, так как ошибка в спецификации требований могут привести к переделке системы и большим затратам, если будут обнаружены во время процесса разработки системы или после введения её в эксплуатацию. Стоимость внесения в систему изменений, необходимых для устранения ошибок в требованиях, намного выше, чем исправление ошибок проектирования или кодирования. Причина в том, что изменение требований обычно влечёт за собой значительные изменения в системе, после внесения которых она должна пройти повторное тестирование.

Подготовка к интервью по сбору требований у заказчика

interview_requirements

Классификация и описание требований на пути от бизнеса к технической реализации

Компания — Бизнес-требования

Источники: Топ-менеджмент компании
Документ: Бизнес-требования (обоснование потребностей инициативы)
Ответственный: Менеджер проекта

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

  1. Описание контекста и списка ключевых заинтересованных лиц
  2. Описание целей создания системы и критериев достижения
  3. Ключевые бизнес-требования к решению и их приоритеты
  4. Существующие и возможные ограничения на решение

Контекст — это то, что стало причиной создания системы, какая ситуация была в компании, какая проблема и как пришли к тому, что систему надо делать.

Заказчик — Документ требований заинтересованных лиц

Этот документ описывает рекомендуемое содержание документа требований заинтересованных лиц:

  • Бизнес-назначение
  • Бизнес-рамки
  • Обзор бизнеса
  • Заинтересованные лица
  • Организационная среда
  • Цели и результаты
  • Бизнес-модель
  • Информационная среда
  • Бизнес-процессы
  • Политики и правила
  • Ограничения деятельности
  • Организационная структура
  • Концепция использования системы
  • Сценарии эксплуатации
  • Проектные ограничения

Пользователь — Требования пользователя

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

Эти требования должны определять только внешнее поведение системы, избегая по возможности определения структурных характеристик системы. Пользовательские требования должны быть написаны естественным языком с использованием простых таблиц, а также наглядных и понятных диаграмм.

Проблемы при формировании пользовательских требований

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

Системные требования

Системные требования описывают свойства и методы всех объектов системы. Программирование – это разработка и реализация структур данных и алгоритмов. Для разработки системы программисту необходимо знать структуры данных, необходимые для реализации системы, и алгоритмы (бизнес-правила/процедуры/пакеты обработки данных), которые ими манипулируют. Системные требования — детализированное описание системных функций и ограничений, которое иногда называют функциональной спецификацией. Она служит основой для заключения контракта между покупателем системы и разработчиками ПО.
Системные требования — это более детализированное описание пользовательских требований.
Они обычно служат основой для заключения контракта на разработку программной системы и поэтому должны представлять максимально полную спецификацию системы в целом. Системные требования также используются в качестве отправной точки на этапе проектирования системы. Спецификация требований может строиться на основе различных системных моделей, таких, как объектная модель или модель потоков данных.

Функциональные требования

Функциональные требования — это перечень сервисов, которые должна выполнять система, причём должно быть указано, как система реагирует на те или иные входные данные, как она ведёт себя в определённых ситуациях и т.д. В некоторых случаях указывается, что система не должна делать.

Стандартные формы для специфицирования функциональных требований:

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

Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».

Нефункциональных требований

Нефункциональные требования — Описывают характеристики системы и её окружения, а не поведение системы. Здесь также может быть приведён перечень ограничений, накладываемых на действия и функции, выполняемые системой.
Они включают временные ограничения, ограничения на процесс разработки системы, стандарты и т.д.
Нефункциональные требования не связаны непосредственно с функциями, выполняемыми системой. Они связаны с такими интеграционными свойствами системы, как надёжность, время ответа или размер системы. Кроме того, нефункциональные требования могут определять ограничения на систему, например на пропускную способность устройств ввода-вывода, или форматы данных, используемых в системном интерфейсе.

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

Нефункциональные требования описывают цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:

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

Требования предметной области

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

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

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

Организационные требования

Организационные требования отображают политику и организационные процедуры заказчика и разработчика ПО. Включают стандарты разработки программного продукта, требования к реализации ПО (т.е. к языку программирования и методам проектирования), выходные требования, которые определяют сроки изготовления программного продукта, и сопутствующую документацию.

Требования к интеграции

Требования к интеграции описывают низкоуровневый интерфейс взаимодействия новой системы с несколькими другими системами компании. Цель данного документа обосновать и формализовать выбор метода интеграции. Документ содержит в себе описание методов и способов интеграции с внешними системами, сервисами.

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

Интеграция через ESB

Интеграция через ESB (Enterprise Service Bus, «Сервисная шина предприятия») применяется для обеспечения информационных систем возможностями для взаимодействия с сервисами. Использование этого метода интеграции приложений обеспечивает слабую связанность между информационными системами, так как системы взаимодействуют не напрямую, а через сервисы, размещенные на сервисной шине предприятия.
Основными функциями ESB являются:

  • Физическое размещение сервисов.
  • Размещение адаптеров к информационным системам.
  • Предоставление канала для взаимодействия информационных систем.
  • Обеспечение независимости от адресов, протоколов и интерфейсов при взаимодействии систем.
  • Трансформация данных при взаимодействии.
  • Маршрутизация сообщений.
  • Обеспечение инфраструктурной функциональности, включая мониторинг, логирование, безопасность, и т. д.

Интеграция точка-точка

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

Интеграция данных

Интеграция данных – это процессы пакетного обмена данных между информационными системами, с помощью средств баз данных этих систем или экспорта-импорта файлов.

Задачи интеграции данных:

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

Интеграция ETL
Интеграция ETL характеризуется следующим сценарием:
На платформе ETL пишется процесс, который
1) С помощью средств доступа к БД 1ой системы забирает из таблиц 1ой системы данные
2) С помощью средств и ресурсов БД 1ой или 2й системы или своих собственных механизмов осуществляет преобразование к структурам таблиц 2й системы
3) Загружает данные в таблицы БД 2й системы.

Файловый обмен
Файловый обмен характеризуется следующим сценарием:
1) Приложение, которому требуется передать данные другому приложению, сохра¬няет их в файле.
2) Разрабатывается интеграционное решение, которое преобразует формат файла в формат, требуемый другим приложением. (В частном случае для этого дорабатывается одна из интегрируемых систем)
3) Приложение которому нужны данные, загружает подготовленный файл.

Требования к пользовательскому интерфейсу

Пользовательский интерфейс — часть программной системы. Требования к пользовательскому интерфейсу могут быть разбиты на две группы:

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

К первой группе можно отнести следующие типы требований:

  • Требования к размещению элементов управления на экранных формах
  • Требования к содержанию и оформлению выводимых сообщений
  • Требования к форматам ввода

Ко второй группе относятся следующие типы требований:

  • Требования к реакции системы на ввод пользователя
  • Требования к времени отклика на команды пользователя

Управление требованиями

Управление требованиями — это процесс управления изменениями системных требований. Процесс управления требованиями выполняется совместно с другими процессами разработки требований. Начало этого процесса планируется на то же время, когда начинается процесс первоначального формирования требований, непосредственно процесс управления требованиями должен начаться сразу после того, как черновая версия спецификации требований будет готова.

С точки зрения разработки требования можно разделить на два класса.
Постоянные требования. Это относительно стабильные требования, которые исходят из основной деятельности организации и касаются непосредственно предметной области, где будет эксплуатироваться система.
Изменяемые требования. Эти требования отображают изменения, сделанные во время разработки системы или после ввода её в эксплуатацию.

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

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

Процесс управления изменениями

Анализ проблем изменения спецификации. Процесс начинается с определения проблем в требованиях или с прямого предложения внесения изменений. На этой стадии проблема или предложенные изменения анализируются для проверки их обоснованности. Затем могут быть сделаны более определённые предложения относительно изменений в требованиях.
Анализ осуществимости и расчёт их стоимости. Эффект от внесения предложенного изменения оценивается с использованием оперативного контроля. Стоимость изменений оценивается двумя показателями: стоимостью внесения изменения в спецификацию и стоимостью внесения изменений в структуру системы и непосредственно в программный код. По окончании этого этапа принимается решение, продолжать или нет внесение изменений в систему.
Реализация изменений. Реализация изменений в системной спецификации, структуре системы и программном коде.

Кто читает документацию

Заказчики системы. Определяют требования, проверяют специфицированные требования на соответствие требованиям заказываемой системы. Они могут вносить изменения в спецификацию.
Руководство компании-разработчика. Использую спецификацию для расчёта цены системы и для планирования процесса разработки системы.
Разработчики системы. Используют спецификацию в процессе разработки системы.
Инженеры, тестирующие систему. Используют спецификацию при разработке тестов, необходимых для аттестации системы.
Инженеры поддержки системы. Спецификация помогает разобраться в системе и понять, как взаимодействуют её отдельные компоненты.

Как правильно сформулировать и контролировать цель проекта?

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

При определении целей по совершенствованию процессов нужно иметь в виду два обстоятельства.

  • Во-первых, надо помнить, что совершенствование процесса ради самого совершенствования бессмысленно. Поэтому спросите себя, действительно ли достижение цели даст искомый рост бизнес-ценности.
  • Во-вторых, не стоит разочаровывать членов команды, ставя цели, которые нереально достичь, поэтому нужно хорошенько подумать, достижима ли поставленная цель в вашей среде. Чтобы цель улучшения была разумной, ответ на оба вопроса должен быть положительным.

Если вы выбрали реалистичные KPI для своих целей, но не видите признаков прогресса по истечении разумного времени, нужно провести расследование:

  • Правильно ли были проанализированы проблемы и выявлены их первопричины?
  • Выбрали ли вы действия по улучшению, непосредственно направленные на эти первопричины?
  • Был ли реалистичным план реализации этих действий по улучшению? Был ли план реализован, как планировалось?
  • Изменилось ли что-то со времени исходного анализа, что должно было заставить переориентировать действия команды по улучшению?
  • Действительно ли члены команды приняли новые приемы работы и прошли период обучения, чтобы начать активно применять их на практике?
  • Были ли поставлены реалистичные цели, которые команда была в состоянии достичь?

Документы процесса разработки и управления требованиями (по Вигерсу)

Высокопроизводительные проекты отличаются эффективными процессами на всех этапах создания требований: выявления, анализа, спецификации, проверки и управления. Для облегчения выполнения этих процессов каждой организации необходим набор документов процесса (process assets).
Любой процесс определяют выполняемые действия и получаемые результаты; документы процесса помогают команде выполнять процессы последовательно и эффективно. Эти документы позволяют участникам проекта понять, какие шаги им следует предпринять и каких результатов от них ждут.requirements_management_process_documents

Документы процесса разработки требований

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

Документы процесса управления требованиями

  • Процесс управления требованиями описывает действия работающей над проектом команды для различения версий требований, определения базовых версий, работой с изменениями требований, различными версиями документации по требованиям, учетом и отчетностью о состоянии требований и накоплением информации по отслеживанию.
  • Процедура отслеживания состояния требований подразумевает мониторинг состояния каждого функционального требования и отчетность по нему.
  • Процесс управления изменениями определяет пути предложения, передачи, оценки и разрешения нового требования или его модификации.
  • Шаблон устава совета по управлению изменениями. Устав совета по управлению изменениями описывает состав, функции и рабочие процедуры этого совета.
  • Контрольный список анализа последствий изменений в требованиях. Анализ последствий помогает вам рассмотреть задачи, побочные эффекты и риски, связанные с реализацией каждого изменения в требованиях, а также оценить объем работы по задачам.
  • Процедура отслеживаемости требований определяет, кто предоставляет данные по отслеживаемости, которые позволяют отслеживать связи требований с другими артефактами проекта, кто их собирает и управляет ими и где они хранятся.

Пример дорожной карты совершенствования процессов работы с требованиями

roadmap_process_improvement_work_requirements

Документ по управлению требованиями


Stakeholders

Аспекты работы бизнес-аналитика: заинтересованные лица

Кто такие стейкхолдеры (заинтересованные лица) на проекте? Как определять заинтересованных лиц?

Автор: Анна Рохас,MBA, M.Ed, тренер и коуч по бизнес-анализу,Sr. Business Analyst, USA. Организатор Группы ВКонтакте — «Business Analysts/Бизнес-аналитик», где Вы можете найти полезную информацию о том, как стать бизнес-аналитиком.


Очень часто, когда бизнес-аналитик начинает работу в новой компании или на новом проекте он сталкивается с проблемой определения заинтересованных лиц. Конечно, можно начать работать как «с корабля на бал», сразу же начиная работать с требованиями и  проектной документацией, и пропустить работу по определению всех важных стейкхолдеров. Но это может привести к плачевным последствиям.

Как например, вы собрали требования только у представителей отдела продаж клиента, и совсем забыли про отдел маркетинга, таким образом программное обеспечение заказчик не принял, так как важных фич, нужных отделу маркетинга в продукте не наблюдалось. И не важно, что вам никто не сказал, что маркетинг-отдел был очень даже заинтересованным лицом в этом проекте, – продукт запорот по вашей вине. Это только один из примеров.

Ваша задача — четко понимать, кто является главными и второстепенными стейкхолдерами на вашем проекте!

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

Бывают внутренние и внешние стейкхолдеры.

Заинтересованными лицами могут быть:

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

Так с чего же начинать анализ стейкхолдеров на проекте?

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

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

Надеюсь эти советы помогут вам провести анализ стейкхолдеров и подготовиться к работе над сбором требований. А какие у вас были казусы с определением заинтересованных лиц? Пишите в комментариях.