Что такое бизнес требования
Пример написания функциональных требований к Enterprise-системе
Недавно мой друг, программист, рассказал, что он не читает требования, а вместо этого приглашает аналитика на чашку чая, они вместе садятся, и аналитик рассказывает, что должно быть реализовано. Мой друг — умный человек и хороший программист, и причина, почему он получает знания о требованиях именно так, не в том, что ему лень читать документацию, а в том, что, даже прочитав ее, он до конца не разберется, что же надо сделать. В данной статье я хочу рассказать, как можно написать требования к программному продукту так, что программисты не просто используют требования, но и участвуют в их написании; на основе собственно опыта я хочу показать, каким образом можно описать требования, чтобы эти описания были достаточными для реализации системы.
Целью нашей разработки было создание с нуля учетной системы для одной из крупных российских компаний. Система была призвана заменить текущую, написанную в конце 90-х. В результате были реализованы платформа и один из бизнес-модулей. В реализованной части было порядка 120 объектов, 180 таблиц, около 30 печатных форм.
Хочу оговориться, что подход, описанный ниже, не универсален для написания любого ПО. Он подходит для систем уровня предприятия, которые строятся на основе объектно-ориентированного подхода: учетных, CRM-, ERP-систем, систем документооборота и т.п.
Бизнес-требования описывали то, что необходимо бизнес-пользователям. Например, им вовсе не нужен объект системы Пользователь, но зато им нужно иметь возможность поменять стоимость товара в счете и распечатать его. Бизнес-требования состояли из общих сценариев, сценариев использования (use cases) и описания алгоритмов обработки данных. Подробно о разработке подобного рода требований можно узнать из книги Карла И. Вигерса и Джоя Битти Разработка требований к программному обеспечению.
Системные требования описывали свойства и методы всех объектов системы.
Нефункциональных требований в данной статье мы касаться не будем. Могу лишь отослать вас к отличной книге Architecting Enterprise Solutions авторов Paul Dyson, Andrew Longshaw.
Требования к интеграции описывали низкоуровневый интерфейс взаимодействия новой системы с несколькими другими системами компании. Здесь мы их рассматривать не будем.
Требования к пользовательскому интерфейсу – отдельная большая тема, возможно, для другой статьи.
Также здесь я не буду касаться других разделов документации, которые относятся к реализации, тестированию, руководствам и управлению.
Давайте рассмотрим подробнее, что такое список терминов и зачем он нужен.
Список терминов и определений
Очень часто при обсуждении функциональности системы разговор заходит в тупик. Еще хуже, если стороны расходятся, думая, что обо всем договорились, но в результате имеют разное понимание того, что надо сделать. Это происходит не в последней степени из-за того, что изначально участники проекта не смогли договориться о том, что значат те или иные термины. Бывает, что даже самые простые слова вызывают проблемы: что такое пользователь, чем отличается группа от роли, кто является клиентом. Поэтому в отличие от описания бизнес-ролей для терминов необходимо давать как можно более точные определения.
Поясню это на примере термина Пользователь. Википедия дает такое определение:
Пользователь — лицо или организация, которое использует действующую систему для выполнения конкретной функции.
Но нас оно не устраивало по нескольким причинам. Во-первых, в систему может зайти только человек, но не организация. Во-вторых, для нашей системы некорректно настоящее время глагола «использует» — система хранит данные о неактивных или удаленных пользователях, т.е. о тех, которые использовали систему ранее, но не могут в настоящее время. И наконец, у нас есть данные о потенциальных пользователях. Например, мы регистрируем сотрудника компании-клиента, который в дальнейшем может получить (а может и не получить) доступ в систему. Наше определение:
Пользователь — человек, который имеет, имел, или, возможно, будет иметь доступ в систему для совершения операций.
Теперь программист, прочитав определение, сразу поймет, почему свойство Логин в объекте Пользователь не обязательное.
Термины связаны друг с другом. В термине Пользователь используется «операция», поэтому приведу и ее определение:
Операция — совокупность действий, составляющих содержание одного акта бизнес-деятельности. Операция должна соответствовать требованиям ACID (Atomicity, Consistency, Isolation, Durability). Совокупность операций одного модуля представляет интерфейс взаимодействия клиент-сервер этого модуля.
Как видите, это определение очень важно для всей системы – оно не только связывает пользователя и его бизнес-действия с тем, что должно быть реализовано, но и накладывает требования на то, КАК должна быть реализована система (это КАК было определено ранее при разработке архитектуры) – бизнес-действия внутри операции должны быть внутри транзакции.
Работа над списком терминов происходила постоянно. Мы поддерживали его полноту, т.е. старались, чтобы в документации не было термина, который бы не был определен в этом списке. Кроме того, были случаи, когда мы меняли термины. Например, по прошествии нескольких месяцев с начала написания требований мы решили заменить Контрагент на Компания. Причина была проста: оказалось, что никто не в состоянии в речи, при разговоре, использовать слово «контрагент». А если так, то он должен был быть заменен на что-то более благозвучное.
Часто бывали случаи, когда приходилось прерывать обсуждение и лезть в требования, чтобы понять, подходит ли обсуждаемая функциональность под существующие определения. И для того, чтобы поддержать непротиворечивость требований, мы в итоге должны были или изменять реализацию, или корректировать описания терминов.
В итоге в списке у нас оказалось порядка 200 бизнес- и системных определений, которые мы использовали не только во всей документации, включая, например, и технический дизайн, разрабатываемый программистами, но и в разговоре, при устном обсуждении функциональности системы.
Второй частью, на которую опиралась вся документация, было описание бизнес-ролей.
Описание бизнес-ролей
Все знают, что используют систему пользователи. Но даже в небольшой системе они обладают разными правами и/или ролями. Наверное, самое простое деление – это администратор и рядовой пользователь. В большой системе ролей может быть несколько десятков и аналитику необходимо заранее об этом подумать и указывать роли при описании общих сценариев (смотри ниже) и в заголовках сценариев использования. Список бизнес-ролей используется для реализации групп и ролей пользователей, назначения им функциональных прав, он необходим тестировщикам, чтобы тестировать сценарии под нужными ролями.
Бизнес-роли пользователей нам не пришлось выдумывать, поскольку в компании были устоявшиеся отделы, роли, функции. Описание ролей было дано на качественном уровне на основе анализа основных функций сотрудников. Окончательное наделение ролей конкретными правами происходило ближе к концу разработки, когда набор функциональных прав стал устойчивым.
Пара примеров: 
Уровни требований
Одной из важных концепций, которую мы применяли при разработке требований, было разделение их на уровни. Алистер Коберн в книге Современные методы описания функциональных требований к системам выделяет 5 уровней. Мы использовали 4 – три уровня бизнес-требований плюс системные требования:
Кроме того наши требования представляли из себя дерево (с циклами). Т.е. общие сценарии уточнялись сценариями использования, которые, в свою очередь, имели ссылки на проверки и алгоритмы. Поскольку мы использовали wiki, физическая реализация такой структуры не представляла проблем. Сценарии использования, алгоритмы и проверки использовали объекты, их свойства и методы, описанные на системном уровне.
Такая методология позволяла нам с одной стороны описывать текущий сценарий настолько подробно, насколько нужно на данном уровне, вынося детали на нижний уровень. С другой стороны, находясь на любом уровне можно было подняться выше, чтобы понять контекст его выполнения. Это так же обеспечивалось функциональностью wiki: сценарии и алгоритмы были написаны на отдельных страницах, а wiki позволяла посмотреть, какие страницы ссылаются на текущую. Если алгоритм использовался в нескольких сценариях, то он в обязательном порядке выносился на отдельную страницу. Такие фрагменты программисты обычно реализовывали в виде отдельных методов.
На картинке ниже представлена часть нашей иерархии (о содержании речь пойдет дальше).
Важно отметить, что если системный уровень описывал все без исключения объекты системы, то сценарии были написаны далеко не для всех случаев поведения пользователя. Ведь многие объекты, по сути, являлись справочниками, и требования к ним более-менее очевидны и похожи. Таким образом мы экономили время аналитика.
Интересен вопрос, кому в проектной команде какой из уровней нужен. Будущие пользователи могут читать общие сценарии. Но уже сценарии использования для них сложны, поэтому аналитик обычно обсуждает сценарии с пользователями, но не отдает их им для самостоятельного изучения. Программистам обычно нужны алгоритмы, проверки и системные требования. Вы однозначно можете уважать программиста, который читает сценарии использования. Тестировщикам (как и аналитикам) нужны все уровни требований, поскольку им приходится проверять систему на всех уровнях.
Использование wiki позволяло работать над требованиями параллельно всем членам проектной команды. Замечу, что в один и тот же момент разные части требований находились в разных состояниях: от находящихся в работе до уже реализованных.
Бизнес-требования
Общие сценарии
Корневая страница нашего дерева требований состояла из общих сценариев, каждый из которых описывал один из 24 бизнес-процессов, подлежащих реализации в данном модуле. Сценарии на странице располагались в той последовательности, в которой они осуществлялись в компании: от создания объекта с проданными товарами, до передачи их клиенту. Некоторые специфические или вспомогательные сценарии помещались в конце в отдельном разделе.
Общий сценарий – это последовательность шагов пользователя и системы для достижения определенной цели. Описания общих сценариев были значительно менее формальны по сравнению со сценариями использования, поскольку они не предназначались для реализации. Основная цель общего сценария – это обобщить сценарии использования, подняться над системой и увидеть, что же в конечном итоге хочет сделать пользователь, и как система ему в этом помогает. Хочу заметить, что общие сценарии также содержали шаги, которые пользователь осуществлял вне системы, поскольку надо было отразить его работу во всей полноте, со всеми этапами, необходимыми для достижения бизнес-цели. На этом уровне хорошо видна роль системы в работе сотрудника компании, видно какая часть этой работы автоматизирована, а какая нет. Именно здесь становилось ясно, что некоторая последовательность действий, которую мы предлагали выполнить пользователю в системе, избыточна, что часть шагов можно сократить.
Как видите, только половина шагов автоматизирована, да и те описаны как можно более кратко. Также из первого шага видно, что ручной перевод задания на печать в статус ‘В работе’ в принципе лишний, можно упростить работу пользователя и автоматически переводить задание в этот статус при печати.
Ссылка «Задание на печать», указывающая на описание объекта в системных требованиях, лишняя, поскольку никому не требуется перепрыгнуть на него из общего сценария. А вот ссылка «пакетная печать документов на груз» важна – она ведет на сценарий использования, формально описывающий действия пользователя и системы.
Сценарии использования
Сценарий использования содержал пронумерованные шаги, которые в 99% случаев очевидным образом начинались со слов Пользователь или Система. Нумерация важна, поскольку позволяла в вопросах и комментариях сослаться на нужный пункт. Каждый шаг – это обычно простое предложение в настоящем времени. Проверки и алгоритмы выносились на следующий уровень и часто на отдельные страницы, чтобы упростить восприятие сценария, а также для повторного использования.
Приведу сценарий использования, на который ссылается общий сценарий выше.
Часто аналитики рисуют пользовательский интерфейс и на его основе пишут сценарии, объясняя это тем, что так нагляднее. Доля истины в этом есть, но мы придерживались позиции, что интерфейс – это дело проектировщика интерфейса. Сначала аналитик описывает, что должно происходить, а затем проектировщик интерфейса рисует эскиз web-страницы или диалога. При этом бывало так, что сценарий приходилось менять. В этом нет ничего страшного, ведь наша цель — спроектировать все части системы так, чтобы было удобно пользователю. При этом каждый участник проектной команды, будь то аналитик или проектировщик интерфейса, обладая специфическими знаниями и внося свой вклад в общее дело, оказывает влияние на работу других членов команды проекта. Только вместе, объединив усилия, можно получить отличный результат.
Алгоритмы и проверки
Например, рассмотрим простой алгоритм ниже.
В алгоритме указана всего одна проверка, но очевидно, что при написании кода метода программист должен реализовать проверки на входные параметры; выбросить исключение, если текущий пользователь не определен и т.д. Также программист может объединить данный алгоритм с алгоритмами переходов в другие статусы и написать единый непубличный метод. На уровне API останутся те же операции, но вызывать они будут единый метод с параметрами. Выбрать лучшую реализацию алгоритмов – это как раз компетенция программиста.
Системные требования
Как известно, программирование – это разработка и реализация структур данных и алгоритмов. Таким образом, по большому счету, все, что надо знать программисту – это структуры данных, необходимые для реализации системы, и алгоритмы, которые ими манипулируют.
При разработке системы мы использовали объектно-ориентированный подход, а поскольку в основе ООП лежат понятия класса и объекта, то наши структуры данных – это описания классов. Термин «класс» специфичен для программирования, поэтому мы использовали «объект». Т.о. объект в требованиях равен классу в объектно-ориентированном языке программирования (в скобках замечу, что в паре разделов требований пришлось изгаляться, чтобы в тексте разделить объект-класс и объект-экземпляр этого класса).
Первая таблица каждого объекта описывала признаки его свойств, необходимые для того, чтобы программист смог создать структуры данных в БД и реализовать объект на сервере приложения:
Название
Названием свойства оперирует как пользователь (например, «я изменил номер счета», Номер – свойство объекта Счет), так и проектная команда. Повсеместно в документации использовались ссылки на свойства в виде простой нотации Объект.Свойство, очевидной для любого участника проекта.
Тип
Мы использовали Datetime, Date, Time, GUID, String, Enum, Int, Money, BLOB, Array(), Float, Timezone, TimeSpan. Тип имел отражение на всех уровнях приложения: на уровне БД, сервера приложения, в пользовательском интерфейсе в виде кода и графического представления. Каждому типу было дано определение, чтобы их реализация не вызывала вопросов у программистов. Например, было дано такое определение типу Money: содержит вещественное число с точностью до 4-го знака после запятой, число может быть отрицательным и положительным; одновременно со значением система хранит валюту; валюта по умолчанию — российский рубль.
Признак редактируемости
Да или Нет в зависимости от того, позволяет ли система пользователям менять значение этого свойства в операции редактирования. В нашей системе это ограничение реализовывалось на сервере приложения и в пользовательском интерфейсе.
Признак наличия нуля
Да или Нет в зависимости от того, может ли поле не содержать значения. Например, поле типа Bool должно содержать одно из возможных значений, а поле типа String обычно может быть пустым (NULL). Это ограничение реализовывалось на уровне БД и на сервере приложения.
Признак уникальности
Да или Нет в зависимости от того, является ли это поле уникальным. Часто уникальность определяется на группе полей, в этом случае у всех полей в группе стояло Да+. Это ограничение реализовывалось на уровне БД (индекс) и на сервере приложения.
Комментарий
Описание поля: что означает, для чего нужно, как используется. Если значение свойства вычисляемое, то это указывается явно с описанием алгоритма расчета этого значения.
Хочу еще раз обратить внимание, что в написании требований принимали участие программисты. Это важно по многим причинам. Во-первых, таким образом программисты лучше осознавали требования, более того, требования становились «ближе к телу», а не просто неким куском бумаги, написанным каким-то аналитиком. Во-вторых, автоматически формировалась документация для API. В-третьих, поддерживалась трассируемость (traceability) требований, т.е. всегда было понятно, реализовано ли то или иное свойство, что особенно становилось важным при модификации требований. Безусловно, такая методология требовала большей дисциплины от программистов, что на самом деле являлось положительным фактором.
Кроме того благодаря этим колонкам, программистам, работающим над разными уровнями приложения, всегда можно было найти общий язык, т.е. понять соответствие между свойством объекта в требованиях, полем в базе данных и свойство в API.
Как я уже писал, табличный вид очень удобен для расширения. Например, для описания начальной миграции у нас была колонка с именем свойства старой системы или алгоритмом преобразования данных. Также мы использовали специальные значки для описания того, как выглядит объект в пользовательском интерфейсе. Одно время у нас была колонка для имени индекса в БД, чтобы программисты не забывали их создавать для уникальных полей. При необходимости вы можете добавить колонку с размерностью типов данных для каждого свойства.
Вот типичное описание свойств нашего объекта.
Вторая таблица объекта содержала описание его операций и их прав. Каждая операция в системе имела уникальное название (колонка Операция), но в пользовательском интерфейсе (в меню) операции отображались под краткими названиями (Краткое название). Для выполнения любой операции надо было обладать определенным правом (Право). Колонка Комментарий для сложных методов содержала описание алгоритма или ссылку на него или на более общий сценарий использования. CRUD операции над всеми типами объектами у нас были стандартизированы, поэтому для них алгоритмы обычно не требовались.
Колонка Название в коде опять заполнялась программистом что, как и при описании объекта, было нужно для документирования API, повышения вовлеченности программистов в написание требований и трассируемости. Ниже – пример описания операций объекта:
В этом разделе были также таблицы, описывающие переход по статусам.
В ячейках стоит краткое название операции, которая переводит исходный статус в целевой. Для более сложных случаев приходилось рисовать полноценные диаграммы.
После инсталляции системы в ней должны присутствовать определенные данные. Например, пользователь с администраторскими правами или список стран согласно общероссийскому классификатору стран мира. Эти данные описывались в разделе Данные.
Все, что не уложилось в стандартные разделы выше, шло в раздел Дополнительная информация. Например, у нас это была информация по связям данного объекта со старой системой.
Подытоживая, можно сказать, что системные требования для объекта содержали всю необходимую информацию для его реализации программистом: структуру данных в БД, описание доменного объекта, ограничения на данные и методы, алгоритмы реализации методов, данные, которые должны быть при инсталляции системы. Структура описания проста для понимания и расширяема.
Многие скажут, что такая детализация требований отнимает много времени и не нужна. На что я возражу – а как программист догадается, что конкретно необходимо реализовать? Разве фразы «Необходимо реализовать объект Пользователь» достаточно, чтобы через некоторое время получить работающий код? Сколько надо выпить чая с аналитиком, чтобы вытащить из него данные по 40 (столько было у нас) свойствам пользователя? Кто, как не аналитик или проектировщик, должен приложить усилия и описать все объекты?
Постановка задач программистам
После описания того, как выглядят требования, рассмотрим интересный вопрос: как должны быть сформулированы задачи для программистов (ограничимся серверной частью многозвенного приложения)? Оказывается, большинство задач (не дефектов) сводится к трем вариантам:
Типовая задача 2
Заголовок: Реализовать такую-то операцию такого-то объекта и права на нее
Текст задачи — ссылка на страницу с системными требованиями к объекту.
Программист находит на странице название операции и права, а по ссылке в колонке Комментарий – алгоритмы, проверки, сценарий использования.
Типовая задача 3
Заголовок: Скорректировать объект и/или операцию.
Данная задача необходима в случае изменений требований. Текст задачи содержит описание изменений или ссылку на страницу сравнения версий требований.
Инструмент для написания и управления требованиями
В конце хочу выразить благодарность Вадиму Лободе и Артему Каратееву за ценные советы и тщательное рецензирование данной статьи.
Что такое бизнес-требования и пользовательские требования
Часто у начинающих дизайнеров возникают вопросы относительно понимания фундаментальных понятий, на которых держится процесс проектирования успешных продуктов.
Бизнес-цели и требования — это одно и тоже? Как их отличать?
Ответ: цель бизнеса, в основном, что-то продать (товар, услугу), он продает некую ценность; требование — это то, что по мнению бизнеса должно присутствовать в продукте и обеспечить продажу.
Возникли проблемы с пониманием бизнес-требований и пользовательских требований, они могут быть одинаковыми?
Ответ: бизнес продает решение некой проблемы пользователя, то есть бизнес предлагает ценность, цель бизнеса — получить прибыль; у пользователя есть некая проблема которую он хочет решить, или потребность которую он хочет удовлетворить минимальными усилиями — это его цель.
Пример
Петя кондитер, он продает торты, это его товар. Петя хочет продавать как можно больше тортов и заработать на этом — это цель бизнеса.
Чтобы продавать торты Пете нужны магазины с витринами, продавцами, кассами и прочее — это бизнес-требования.
Юля любит сладкое, любит разнообразие, любит пробовать что-то новое, она хочет сделать свою жизнь приятнее —это цель пользователя.
Юля хочет знать где находится ближайший магазин со сладостями, когда завезли что-то новенькое, прийдя в магазин она хочет знать цену товара, из чего он сделан и когда его изготовили — это требования пользователя.
Этот материал является частью онлайн-курса ДИЗАЙНЕР ЦИФРОВЫХ ПРОДУКТОВ
Я разработал курс, который дает методику проектирования сайтов, веб-сервисов и мобильных приложений, и будет полезен тем, кто уже работает как WEB Designer или UX/UI Designer, или ещё только учится, и хочет лучше разобраться в процессе и перейти на новый уровень.
Формирование требований и классификация требований
Прежде чем начинать проект, обязательно нужно знать, какой результат (продукт) вы хотите получить. И порой этот продукт необходимо описать самым тщательным образом. Иными словами, нужно знать, какие требования заказчик предъявляет к продукту. Полный набор этих требований называют каталогом требований, или спецификацией.
Крупные и сложные проекты обычно насчитывают тысячи требований. Бизнес-анализ как раз и позволяет выявлять проблемы и определять, что требуется для их преодоления. В крупных проектах, таких, как разработка программного обеспечения, сбор требований является одним из важнейших этапов жизненного цикла проекта, котоорыый может занять несколько недель/месяцев.
Для выявления требований проводится серия структурированных интервью с заказчиками, которые позволяют точно определить их пожелания к готовому продукту. Попытка напрямую узнать у заказчика, какие результаты ему нужны, может закончится крахом: заказчик станет выдвигать все новые и новые требования, так что вы просто будете не в силах их удовлетворить. Помните, любое требование влияет на продолжительность и стоимость проекта. Соответственно, получая подробный список требований, вам нужно знать, являются ли они:
Выжимка по процессу формирования требований
Функциональные требования — это требования к системе.
Бизнес-требования — эквивалентно бизнес-целям.
Между ними — Пользовательские требования, 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) для этого есть так называемые «матрицы трассировки», на которых графически стрелками показываются зависимости между требованиями.
Важно сохранять пользовательские требования для хранения их в первоначальном виде, отслеживания источника их возникновения (вплоть до конкретного лица), расстановки их приоритетов (с точки зрения пользователя) и т.д.
Схема процесса разработки с уровнями требований
Формирование и анализ требований
Анализ предметной области. Аналитики должны изучить предметную область, где будет эксплуатироваться система.
Сбор требований. Это процесс взаимодействия с лицами, формирующими требования. Во время этого процесса продолжается анализ предметной области.
Классификация требований. На этом этапе бесформенный набор требований преобразуется в логически связанные группы требований.
Разрешение противоречий. Без сомнения, требования многочисленных лиц, занятых в процессе формирования требований, будут противоречивыми. На этом этапе определяются и разрешаются противоречия такого рода.
Назначение приоритетов. В любом наборе требований одни из них будут более важны, чем другие. На этом этапе совместно с лицами, формирующими требования, определяются наиболее важные требования.
Проверка требований. На этом этапе определяется их полнота, последовательность и непротиворечивость.
Аттестация требований
Аттестация должна продемонстрировать, что требования действительно определяют ту систему, которую хочет иметь заказчик. Проверка требований важна, так как ошибка в спецификации требований могут привести к переделке системы и большим затратам, если будут обнаружены во время процесса разработки системы или после введения её в эксплуатацию. Стоимость внесения в систему изменений, необходимых для устранения ошибок в требованиях, намного выше, чем исправление ошибок проектирования или кодирования. Причина в том, что изменение требований обычно влечёт за собой значительные изменения в системе, после внесения которых она должна пройти повторное тестирование.
Подготовка к интервью по сбору требований у заказчика
Классификация и описание требований на пути от бизнеса к технической реализации
Компания — Бизнес-требования
Источники: Топ-менеджмент компании
Документ: Бизнес-требования (обоснование потребностей инициативы)
Ответственный: Менеджер проекта
Состав бизнес-требований может отличаться на практике. Обычно включаются следующие пункты:
Контекст — это то, что стало причиной создания системы, какая ситуация была в компании, какая проблема и как пришли к тому, что систему надо делать.
Заказчик — Документ требований заинтересованных лиц
Этот документ описывает рекомендуемое содержание документа требований заинтересованных лиц:
Пользователь — Требования пользователя
Пользовательские требования — описание на естественном языке (плюс поясняющие диаграммы) функций, выполняемых системой, и ограничений, накладываемых на неё.
Источники: Пользователь
Документ: Пользовательские требования/Требования к ПО
Ответственный: Системный аналитик
Эти требования должны определять только внешнее поведение системы, избегая по возможности определения структурных характеристик системы. Пользовательские требования должны быть написаны естественным языком с использованием простых таблиц, а также наглядных и понятных диаграмм.
Проблемы при формировании пользовательских требований
Отсутствие чёткости изложения. Иногда нелегко изложить какую-либо мысль естественным языком чётко и недвусмысленно, не сделав при этом текст многословным и трудно читаемым.
Смешение требований. В пользовательских требованиях отсутствует чёткое разделение на функциональные требования, на системные цели и проектную информацию.
Объединение требований. Несколько различных требований к системе могут описываться как единое пользовательское требование.
Системные требования
Системные требования описывают свойства и методы всех объектов системы. Программирование – это разработка и реализация структур данных и алгоритмов. Для разработки системы программисту необходимо знать структуры данных, необходимые для реализации системы, и алгоритмы (бизнес-правила/процедуры/пакеты обработки данных), которые ими манипулируют. Системные требования — детализированное описание системных функций и ограничений, которое иногда называют функциональной спецификацией. Она служит основой для заключения контракта между покупателем системы и разработчиками ПО.
Системные требования — это более детализированное описание пользовательских требований.
Они обычно служат основой для заключения контракта на разработку программной системы и поэтому должны представлять максимально полную спецификацию системы в целом. Системные требования также используются в качестве отправной точки на этапе проектирования системы. Спецификация требований может строиться на основе различных системных моделей, таких, как объектная модель или модель потоков данных.
Функциональные требования
Функциональные требования — это перечень сервисов, которые должна выполнять система, причём должно быть указано, как система реагирует на те или иные входные данные, как она ведёт себя в определённых ситуациях и т.д. В некоторых случаях указывается, что система не должна делать.
Стандартные формы для специфицирования функциональных требований:
Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
Нефункциональных требований
Нефункциональные требования — Описывают характеристики системы и её окружения, а не поведение системы. Здесь также может быть приведён перечень ограничений, накладываемых на действия и функции, выполняемые системой.
Они включают временные ограничения, ограничения на процесс разработки системы, стандарты и т.д.
Нефункциональные требования не связаны непосредственно с функциями, выполняемыми системой. Они связаны с такими интеграционными свойствами системы, как надёжность, время ответа или размер системы. Кроме того, нефункциональные требования могут определять ограничения на систему, например на пропускную способность устройств ввода-вывода, или форматы данных, используемых в системном интерфейсе.
Нефункциональные требования отображают пользовательские требования:
Нефункциональные требования основываются на бюджетных ограничениях, учитывают организационные возможности компании-разработчика, возможность взаимодействия разрабатываемой системы с другими программными и вычислительными системами, а также такие внешние факторы, как правила техники безопасности, законодательство о защите интеллектуальной собственности и т.п.
Нефункциональные требования описывают цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:
Требования предметной области
Требования предметной области характеризуют ту предметную область, где будет эксплуатироваться система. Эти требования могут быть функциональными и не функциональными. Эти требования отображают условия, в которых будет эксплуатироваться программная система. Они могут быть представлены в виде новых функциональных требований или в виде ограничений на уже сформулированные функциональные требования или в виде указаний, как система должна выполнять вычисления. Невыполнение требований предметной области может привести к выходу системы из строя.
Требования к продукту
Требования к продукту описывают эксплуатационные свойства программного продукта. Это требования к производительности системы, объёму необходимой памяти, надёжности (определяет частоту возможных сбоев в системе), переносимости системы на разные компьютерные платформы и удобству эксплуатации.
Организационные требования
Организационные требования отображают политику и организационные процедуры заказчика и разработчика ПО. Включают стандарты разработки программного продукта, требования к реализации ПО (т.е. к языку программирования и методам проектирования), выходные требования, которые определяют сроки изготовления программного продукта, и сопутствующую документацию.
Требования к интеграции
Требования к интеграции описывают низкоуровневый интерфейс взаимодействия новой системы с несколькими другими системами компании. Цель данного документа обосновать и формализовать выбор метода интеграции. Документ содержит в себе описание методов и способов интеграции с внешними системами, сервисами.
Интеграция приложений – это технологические процессы, используемые для организации обмена данными между различными информационными системами с помощью средств интеграции, предоставляемыми приложениями. К средствам интеграции, предоставляемыми приложениями относятся 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).
Любой процесс определяют выполняемые действия и получаемые результаты; документы процесса помогают команде выполнять процессы последовательно и эффективно. Эти документы позволяют участникам проекта понять, какие шаги им следует предпринять и каких результатов от них ждут.