на какие три уровня можно разделить требования

WEBURSITET.RU

Онлайн-курсы профессиональной разработки ПО

Уровни требований к программному продукту

Текстовая расшифровка второго видеоурока курса Введение в профессию аналитика.

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

Давайте для начала разберёмся с делением требований по уровням.

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

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

В области решаемой проблемы лежит первый уровень требований: потребности людей, для которых создаётся продукт. Это как непосредственные пользователи продукта, так и другие люди, в интересах которых он будет использоваться (например, владелец компании, приобретающей программу для использования своими сотрудниками).

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

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

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

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

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

2. Пользовательские требования

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

в целом соответствуют уровню проблем или потребностей, который описан у Леффингуэлла.

Пользовательские требования — это требования к тому, как люди используют систему. Это уровень взаимодействия системы с внешним миром, который представлен её пользователями. В данном случае речь идёт именно о людях, хотя у системы могут быть и другие внешние пользователи (например, другие системы).

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

Мы будем использовать терминологию, похожую на терминологию Вигерса, но всё же немного отличающуюся. Мы тоже будем выделять три уровня требований:

2. Требования пользовательского уровня.

3. Требования уровня реализации.

Требования отвечают на вопросы: зачем создаётся продукт, какие и чьи проблемы он решает, какие возможности и кому он предоставляет.

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

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

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

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

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

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

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

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

Для первого уровня есть свои методы разработки требований, их можно обобщённо назвать разработкой Концепции продукта.

Для второго уровня тоже есть свои методы разработки требований — и они, как мы уже отметили, лучше всего проработаны. Например, известный, наверное, всем аналитикам метод юзкейсов (use cases, варианты использования) относится к этому уровню. Не менее известный и очень распространенный сейчас метод описания требований с помощью User Stories (пользовательских историй) тоже был разработан, в первую очередь, для описания требований пользовательского уровня. Хотя сейчас оба этих метода декларируются как универсальные и пригодные для разработки требований всех уровней.

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

Источник

Нефункциональные требования к программному обеспечению. Часть 1

Введение

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

Нефункциональные требования: какие они бывают

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

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

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

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

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

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

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

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

Пример сценария, используемого для определения требований к производительности модуля системы, рассылающего уведомления пользователям сайта по электронной почте:

1. Система получает оповещение о событии, инициирующем рассылку уведомлений.
2. Система осуществляет рассылку оповещений по адресам из списка рассылки X, используя шаблон Y. Для рассылки сообщений используется сервис Z.
3. В случае невозможности завершения рассылки, система предпринимает повторные попытку рассылки.

Требования к времени оповещения о событии, инициирующем рассылку уведомлений: система должна получать оповещение не позднее чем через XX секунд после возникновения события.
Требования к времени отправки уведомлений: все уведомления должны быть отправлены не позднее YY минут после получения оповещения о событии
Требования к повторной отправке рассылки после неудачной попытки: число повторных попыток должно быть равным 10, с интервалом в 10 мин после каждой неудачной попытки отправки.

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

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

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

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

Атрибуты качества

Этот раздел будет посвящен характеристикам качества продукта или системы.

Характеристики качества и модель качества ПО

Определение атрибутов качества тесно связано с выбранной для вашего продукта моделью качества. Разработкой модели качества занимается группа обеспечения качества (в которую входят тестировщики и которая ими, разумеется, не ограничивается).

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

Характеристики качества с точки зрения влияния на архитектуру системы

Все атрибуты качества с точки зрения архитектуры системы можно разделить на две большие группы: первая группа (runtime) – это атрибуты, относящиеся ко времени работы приложения или системы; вторая группа (design time) определяет ключевые аспекты проектирования приложения или системы. Многие из этих атрибутов взаимозависимы.

Рассмотрим более подробно каждую из этих групп.

Группа runtime

Группа design time

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

Источник

Software Requirements. Три уровня требований.

Есть на свете очень хорошая книга, которая называется “Software Requirements”. К сожалению, этой книги в переводе на русском еще нет. А тот что есть – относится к изданию десятилетней давности. Поэтому я решил публиковать самые интересные моменты из книги в своем блоге. С одной стороны – это нужно мне, чтобы упорядочить и не растерять полезную информацию из книги. С другой стороны – эти статьи могут оказаться очень полезными для читателей блога.

Пару слов о книге. Она посвящена сбору требований для разработки программного обеспечения. Это издание книги было полностью переработано, добавлены новые примеры и советы. Так же авторы добавили описание сбора требований для agile проектов. Книга ориентирована на разработчиков, менеджеров проектов и в первую очередь на бизнес-аналитиков.

Давайте определимся, с понятием “требование”.

Требование – это описание того, что должно быть реализовано. Оно представляет собой описание того, как система должна себя вести, а так же описание ее свойств, особенностей и ограничений.

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

Уровень пользовательских требований

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

Взаимоотношения между всеми требованиями проще понять по следующей схеме:

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

Здесь под “документами” понимается не файл на компьютере (хотя и он может быть), а любые форматы хранения информации: Wiki, базы данных, набор файлов в определенной папке и т.п.

Благодарности.
Спасибо Наталье Юматовой за помощь в подготовке и написании поста.

Ссылки.
[1] Davis, Alan M. 2005. Just Enough Requirements Management: Where Software Development Meets Marketing. New York: Dorset House Publishing.

Источник

Требования к ПО на пальцах

Пост про основы разработки требований — без сложных схем, терминов и таблиц, зато с гифками.

Если коротко, то основные этапы разработки требований — это:

Если после выполнения просьбы получилось что-то не то — это либо накосячил исполнитель,
либо вы некорректно поставили задачу.

Как известно, неверная задача может обойтись довольно дорого. Например, если полгода команда из 5 программистов разрабатывала систему, которая никому не была нужна.

В наш беспокойный век Agile разработкой требований часто пренебрегают. Но гибкие методологии не всегда спасают от больших потерь. Поэтому, даже если у вас нет аналитика на проекте, даже если вы вообще не IT — не забывайте про здравый смысл и берите из лучших практик то, что нужно в данный момент.

Так что же такое требования и почему важно уметь их разрабатывать?

Итак, обратимся к истокам:

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

С чего же начать разработку требований? В определении спрятана подсказка: начинать нужно с цели — для чего вообще нам что-то делать.

1. Зачем?

Как бы “ASAP. ” не требовалось что-то сделать — важно найти время и силы выяснить, зачем же это нужно.

Потому что часто, после выяснения цели, меняется или вовсе устраняется задача.

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

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

Можно воспользоваться методом “Пяти почему” или любым другим. Но обычно люди не сопротивляются: если проявить интерес к их работе — разгадка становится доступной.

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

Процесс заказа материалов считается автоматизированным, если >90% компаний-партнеров делают заказы через систему.

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

И да, не забывайте согласовывать эту красоту с заказчиками. Вообще не забывайте согласовывать требования со всеми заинтересованными сторонами.

2. Что?

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

Чтобы сократить процесс согласования счетов, мы можем:

А. Перераспределить задачи между согласующими. В результате несколько человек могут быть исключены из процесса. Суммарное время процесса сократится за счет периодов передачи данных/ожидания/коммуникации при передаче.

Б. Перейти на электронный документооборот — достоверность счетов и данных в них будет подтверждена оператором ЭДО, подтверждение человеком не потребуется.

В. Автоматически распознавать сканы счетов и сравнивать данные с цифрами из системы закупок. Ручная проверка и согласование не потребуются.

Чтобы продумать все варианты, надо разобраться — а что же происходит сейчас? Как устроен процесс без вашей системы, как работают пользователи и заказчики? Даже если процесса еще нет, подробная информация про текущее состояние очень важна. Так мы поймем, какое решение устранит проблему, а не создаст еще одну.

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

3. Как?

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

Этот этап — дело техники. И если вы успешно прошли предыдущие два — будет гораздо проще.
Хоть техника и зависит от контекста, полезно двигаться по “чек-листу” Вигерса и других умных людей. Если для вас какой-то тип требований сейчас не актуален — окей, не описываем. Но важно не забыть и проверять себя.

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

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

4. Когда?

В “лесу” ваших требований скорее всего найдется сколько-нибудь взаимоисключающих и сколько-нибудь повторяющихся. Поэтому полезно всю эту красоту документировать и представлять в виде таблиц и диаграмм.

Тут есть много инструментов: например, BPMN для описания бизнес-процессов и UML для создания схем взаимодействий сервисов и компонентов.

Если у вас получается объяснять всем, что и как вы хотите сделать с системой, при помощи салфетки и 3х пятен от кофе — значит вы Джон Уик от аналитики и это потрясающе.

Однако, как правило, «пятенный» уровень детализации не позволяет увидеть подводные камни и продумать все возможные сценарии. Ведь вроде и так все понятно, а нарисовал схемку — и вот тебе и бесконечный вызов, и забытая ветка процесса, и кратчайший путь к золоту.
Поэтому полезно знать, какие есть инструменты для обращения хаоса в порядок.

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

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

Конечно, проблемы будут всегда. Будут переделки, сгоревшие дедлайны и баги. Не всегда будет возможность пройти все этапы и сделать нормальную аналитику, договориться или даже просто поговорить с заказчиком, задокументировать и протрассировать требования. Но в любой ситуации понимание “как должно быть” помогает сделать продукт лучше. Даже если в данный момент вы делаете “как получается” — вы осознаете, что упускаете, и знаете риски. А если вы знаете риски — значит вы можете ими управлять.

Подробнее про требования рекомендую почитать в книге Вигерса и Битти: “Разработка требований к программному обеспечению”. Хоть книга не всегда простая, но очень полезная. Большинство других материалов по теме — пересказ этих истин с той или иной степенью вольности.

Спасибо за внимание и удачного проектирования.

Источник

Пример написания функциональных требований к 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
Заголовок: Скорректировать объект и/или операцию.
Данная задача необходима в случае изменений требований. Текст задачи содержит описание изменений или ссылку на страницу сравнения версий требований.

Инструмент для написания и управления требованиями

В конце хочу выразить благодарность Вадиму Лободе и Артему Каратееву за ценные советы и тщательное рецензирование данной статьи.

Источник