я его в марафон, или пытаться точно определить все детали каждого варианта использования. Обычно они рассматриваются многократно и уточняются.
Спецификация требований к ПО
Спецификация требований к ПО (software requirements specification, SRS) – согласно IEEE Std 1012:2004, структурированный набор требований к программному обеспечению и его внешним интерфейсам. В него входят функциональность, производительность, конструктивные ограничения и атрибуты.
Этот документ предназначен для определения основных положений соглашения между заказчиком и разработчиком, касающегося функционирования программного продукта. Спецификацию требований к ПО в различных компаниях называют по-разному:
• документом бизнес-требований;
• функциональной спецификацией;
• спецификацией продукта;
• просто документом о требованиях.
В спецификации требований к ПО указываются функции и возможности, которыми должно обладать ПО. Она должна содержать функциональные требования – достаточно подробное описание поведения системы при различных условиях, а также нефункциональные требования – необходимые качества системы и накладываемые на нее ограничения, такие как производительность, безопасность и удобство использования.
Спецификация требований служит основой для дальнейшего планирования, дизайна и кодирования, а также базой для тестирования пользовательской документации. Однако она не должна содержать подробностей дизайна, проектирования, тестирования и управления проектом, за исключением особенностей дизайна и реализации, которые относятся к ограничениям.
Важно понимать, что один материал требований часто не удовлетворяет потребностям всех типов заинтересованных лиц. Одним нужно знать только бизнес-цели, другие хотят получить высокоуровневую общую картину, третьих интересует лишь ви´дение с точки зрения пользователя, но есть и те, кому требуются все подробности. Вот почему рекомендуется создавать такие материалы, как документ об образе и границах проекта, документ пользовательских требований и спецификация требований к ПО. При этом не стоит ожидать, что все классы пользователей прочтут подробную спецификацию требований к ПО, а разработчики узнают все, что им нужно, из набора вариантов использования или пользовательских историй.
Спецификация требований к ПО необходима разным участникам проекта.
Если нужная функциональность отсутствует в соглашении о требованиях, то нет никаких оснований ожидать, что она появится в продукте.
Сколько спецификаций необходимо
В большинстве случаев создают одну спецификацию требований к ПО, но для больших проектов это непрактично. При проектировании крупных систем часто составляют спецификацию требований системы, к которой прилагают отдельные спецификации требований к ПО и оборудованию (ISO/IEC/ IEEE, 2011).
Например, если разрабатывается очень сложное приложение управления процессами, в котором задействовано более сотни сотрудников, то спецификация требований этого проекта может содержать около 800 высокоуровневых требований. В таком случае проект необходимо разбить на 20 подпроектов, и для каждого из них составить собственную спецификацию требований к ПО.
В простых проектах может возникать ситуация, когда разрабатывают лишь один руководящий документ и называют его просто «спецификация». Он содержит всю возможную информацию о проекте: требования, оценки, проектные планы, планы качества, планы тестирования. Управлять изменениями и версиями такого всеобъемлющего документа затруднительно. Рекомендуется разграничивать выявленные требования по уровням, приведенным в разделе «Документирование требований».
При разработке документации всегда стоит оценивать ее объем с точки зрения необходимости и достаточности. Лучшим вариантом будет хранение требований в средстве управления требованиями, которое оказывается очень кстати для решения дилеммы: создавать одну или несколько спецификаций требований в проекте, где планируется несколько выпусков продукта или итераций разработки (Wiegers, 2006). В этом случае спецификация требований к ПО для части продукта или определенной итерации – всего лишь отчет, созданный на основе запроса определенного содержимого базы данных.
Не обязательно составлять спецификацию для всего продукта еще до начала разработки, однако необходимо зафиксировать требования для каждой итерации перед ее созданием. Это удобно в тех случаях, когда в начале работы участники проекта не могут определить все требования, при этом некоторую функциональность необходимо быстро передать в руки пользователей. Отклики об использовании ранних итераций позволяют скорректировать оставшуюся часть проекта. Однако при работе над любым проектом необходимо достичь базового соглашения по каждому набору требований до начала их реализации разработчиками. Выработка базового соглашения или базовой версии требований (baselining) – это процесс преобразования реализуемых требований к ПО в информацию, которую будут изучать и одобрять специалисты. При работе с согласованным набором требований снижается вероятность недопонимания и ненужных переделок.
При разработке спецификации требований к ПО следует структурировать информацию таким образом, чтобы все заинтересованные в проекте лица смогли в ней разобраться.
1. Для структурирования необходимой информации использовать соответствующие шаблоны.
2. Придерживаться единообразия при именовании разделов, подразделов и отдельных требований.
3. Использовать последовательно и в разумных пределах средства визуального выделения: полужирное начертание, подчеркивание, курсив и различные шрифты. Цветовые выделения могут быть не видны дальтоникам или при черно-белой печати.
4. Создать оглавление, чтобы облегчить пользователям поиск необходимой информации.
5. Пронумеровать все рисунки и таблицы, озаглавить их, при упоминании их в документе использовать присвоенные номера.
6. При использовании ссылок на другие части документа применять перекрестные ссылки в редакторе, а не сложную кодировку страниц.
7. При использовании документов применять гиперссылки, чтобы можно было быстро перейти к соответствующим разделам спецификации или другим файлам.
8. При хранении требований в специализированном средстве использовать ссылки, чтобы облегчить читателю навигацию.
9. Включать графическое представление информации для облегчения понимания там, где это возможно.
10. Воспользоваться услугами опытного редактора, чтобы обеспечить последовательность документа и единообразие терминологии и структуры.
Иногда фрагмент информации логически подходит для нескольких разделов шаблона. В этом случае нужно выбрать один раздел и использовать именно его для подачи информации такого типа в своем проекте. Не стоит дублировать информацию в нескольких разделах, даже если она логически туда ложится. Для быстрого поиска в документе хорошо подойдут перекрестные ссылки и гиперссылки. При создании спецификации требований к ПО применяют приемы и средства управления версиями для того, чтобы все пользователи четко понимали, какую версию они читают в тот или иной момент времени. Также полезно вести журнал изменений, в котором фиксируется суть изменений, автор, дата и причина.
➤ 1. Введение
Введение – обзор, помогающий читателям разобраться в структуре и принципе использования спецификации требований к ПО.
➤ 1.1. Назначение
Определение продукта или приложения, требования для которого указаны в документе, в том числе редакция или номер выпуска. Если эта спецификация требований к ПО относится только к части системы, то ее необходимо идентифицировать, а также описать типы пользователей, которым адресован этот документ, например разработчикам, менеджерам проектов, маркетологам, пользователям, тестировщикам или составителям документации.
➤ 1.2. Соглашения, принятые в документах
Указание на все стандарты или типографические соглашения, включая значение стилей текста, особенности выделения или нотацию. Можно определить принятый формат на случай, если кому-нибудь позже понадобится добавить требование.
➤ 1.3. Границы проекта
Краткое описание ПО и его назначения. Описание связи продукта с пользователями или корпоративными целями, а также с бизнес-целями и стратегиями. Если есть отдельный документ о концепции и границах проекта, то не стоит повторять его содержимое, достаточно предоставить ссылку. Если спецификацию требований к ПО предполагается разрабатывать постепенно, она должна содержать собственное положение о концепции и границах продукта в качестве подраздела долгосрочной стратегической концепции. Можно предоставить высокоуровневую сводку главной функциональности выпуска или функций, которые он должен выполнять.
➤ 1.4. Ссылки
Перечисление всех документов или других ресурсов, использованных в этой спецификации, в том числе гиперссылки на них, если их местоположение не будет меняться. Это могут быть руководства по стилям пользовательского интерфейса, контракты, стандарты, спецификации к системным требованиям, спецификации интерфейса и спецификации требований к ПО связанных продуктов. Объем информации должен быть достаточным, чтобы пользователь сумел при необходимости получить доступ к каждому указанному материалу: название, имя автора, номер версии, дата, источник, место хранения или URL-адрес.
➤ 2. Общее описание
В этом разделе представлен общий обзор продукта и среды, в которой он будет применяться, описана предполагаемая пользовательская аудитория, а также известные ограничения, предположения и зависимости.
➤ 2.1. Общий взгляд на продукт
Описание контекста и происхождения продукта. Информация о том, является ли он новым членом растущего семейства продуктов, новой версией существующей системы, заменой существующего приложения или совершенно новым продуктом. Если спецификация требований определяет компонент более крупной системы, необходимо при помощи визуальных моделей, контекстной диаграммы или карты экосистемы показать взаимосвязь продукта с другими подсистемами и основные интерфейсы между ними.
➤ 2.2. Классы и характеристики пользователей
Описание различных классов пользователей, которые, как предполагается, будут работать с данным продуктом, их характеристики. Некоторые требования могут относиться только к определенным классам. Необходимо выделять привилегированные классы пользователей – подмножества заинтересованных в проекте лиц; их описание приводится в документе концепции и границ проекта. Если есть главный каталог классов пользователей, то можно включить описания классов пользователей, просто указав их в каталоге.
➤ 2.3. Операционная среда
Описание рабочей среды, в которой будет работать ПО, включая аппаратную платформу, операционные системы и их версии, а также географическое местоположение пользователей, серверов и баз данных вместе с организациями, в которых располагаются соответствующие базы данных, серверы и веб-сайты. Перечисление всех остальных компонентов ПО или приложений, с которыми система должна быть совместима. Если в связи с разработкой новой системы нужно произвести значительную работу с технической инфраструктурой, стоит подумать о создании отдельных требований к инфраструктуре, в которой необходимо детально изложить подробности этой работы.
➤ 2.4. Ограничения дизайна и реализации
Бывает, что нужно использовать вполне определенный язык программирования или библиотеку, на разработку которой уже потрачено время. В этом случае делают описание и логическое обоснование всех факторов, которые ограничат возможности, доступные разработчикам. Требования должны включать потребности, а не идеи по решению, потому что идеи накладывают на дизайн зачастую неоправданные ограничения.
➤ 2.5. Предположения и зависимости
Предположение (assumption) – это утверждение, которое предполагается верным в отсутствие знаний или доказательств иного.
Некоторые предположения можно отнести к группе рисков проекта. Разработчик может думать, что определенный набор функций написан специально для этого приложения, бизнес-аналитик – что он будет взят из предыдущего проекта, а менеджер проекта – что предполагается приобрести коммерческую библиотеку функций. Включаемые здесь предположения относятся к системной функциональности. Предположения, относящиеся к бизнесу, представлены в документе об образе и границах проекта.
Определите все зависимости проекта или создаваемой системы от внешних факторов или компонентов вне ее контроля. Например, до установки продукта может потребоваться установить Microsoft.NET Framework 4.5 или более позднюю версию – это зависимость.
➤ 3. Функции системы
Шаблон, структурированный по функциям системы, – это еще один способ систематизации функциональных требований. Другие методы классификации: по функциональным областям, рабочим потокам, вариантам использования, режимам работы, классам пользователей, стимулам и реакциям. Возможны также иерархические комбинации этих элементов, например варианты использования внутри классов пользователей. Не существует единственно правильного метода организации. Выбирайте тот, при котором пользователям будет легче понять предполагаемые возможности продукта.
➤ 3.1. Функция системы X
Наименование и описание особенностей функции, выраженное в нескольких словах, например «3.1. Проверка правописания». Аналогично называют подразделы с 3.×.1 по 3.×.3 для каждой функции системы.
➤ 3.1.1. Описание
Краткое описание функции системы и указание ее приоритета: высокий, средний или низкий. Приоритеты – динамичная характеристика, они могут изменяться в ходе проекта. При использовании средства управления требованиями определяется атрибут требований для обозначения приоритета.
➤ 3.1.2. Функциональные требования
1. Перечисление по пунктам конкретных функциональных требований, которые нужно реализовать, чтобы пользователь мог использовать сервисы этой функции или реализовать вариант использования.
2. Описание вариантов реагирования продукта на ожидаемые ошибки, неправильный ввод информации или неверные действия.
3. Присвоение каждому функциональному требованию уникального имени.
4. Создание множества атрибутов для каждого функционального требования при использовании средства управления требованиями, например, таких как основание, источник и состояние.
➤ 4. Требования к данным
Ценность информационных систем заключается в том, что они предоставляют возможность манипулировать данными. Этот раздел шаблона предназначен для описания различных аспектов данных, которые будет потреблять система в качестве входной информации, обрабатывать и возвращать в виде выходной информации.
➤ 4.1. Логическая модель данных
Модель данных – это визуальное представление объектов и наборов данных, которые будет обрабатывать система, а также отношений между ними.
Существует много видов нотаций для моделирования данных, в том числе диаграммы отношений «сущность – связь» и диаграммы классов UML. Можно включить модель данных для бизнес-операций, выполняемых системой, или логическое представление данных, с которыми будет работать система. Это не то же самое, что модель данных реализации, которая представляется в виде дизайна базы данных.
➤ 4.2. Словарь данных
Словарь данных определяет состав структур данных, а также их значение, тип, длину, формат и разрешенные значения элементов, из которых состоят эти структуры. Серийные средства моделирования данных часто включают словарь данных в качестве компонента. Во многих случаях словарь данных лучше хранить как отдельный артефакт, не внедряя его в спецификацию требований к ПО. Это облегчает возможность его повторного использования в других проектах.
➤ 4.3. Отчеты
Если приложение будет генерировать отчеты, то их перечисляют и описывают характеристики. Если отчет должен соответствовать определенному готовому макету, допускается указать это как ограничение, возможно, с примером. В противном случае делают логическое описание с указанием порядка сортировки, уровней суммирования и т. п., отложив подробный макет до этапа дизайна.
➤ 4.4. Получение, целостность, хранение и утилизация данных
Если это важно, описывают процесс получения и обслуживания данных. Например, при открытии канала номенклатуры данных может потребоваться первым делом выполнить начальный дамп всей номенклатуры данных в принимающую систему, а затем использовать каналы для передачи только изменений. Указывают все требования, относящиеся к защите целостности данных системы, и все процедуры, которые могут потребоваться, например резервное копирование, создание контрольных точек, зеркальное отображение или проверка корректности данных. Также перечисляют все политики, которые должна применять система для хранения или утилизации данных, в том числе временных данных, метаданных, остаточных данных (таких, как удаленные записи), данных в кэше, локальных копий, архивов и промежуточных архивов.
➤ 5. Требования к внешним интерфейсам
В этом разделе указывается информация, которая гарантирует, что система будет правильно взаимодействовать с пользователями и компонентами внешнего оборудования и ПО. Выработка согласия по внешнему и внутреннему интерфейсу системы признана оптимальным приемом в области разработки ПО (Brown, 1996). В сложной системе с множеством подкомпонентов следует использовать раздельные спецификации для интерфейсов или спецификацию системной архитектуры. В документацию по интерфейсу допускается включать ссылки на материалы из других документов. Например, ссылка может указывать на руководство по работе с устройством, где перечислены коды ошибок, которые устройство может отправить программе.
➤ 5.1. Пользовательские интерфейсы
Это описание логических характеристик каждого пользовательского интерфейса, который необходим системе. Особенные характеристики пользовательских интерфейсов могут упоминаться в разделе «6.1. Удобство использования». Ниже перечислены некоторые из них.
1. Ссылки на стандарты графического интерфейса пользователей или стилевые рекомендации для семейства продуктов, которые необходимо соблюдать.
2. Стандарты шрифтов, значков, названий кнопок, изображений, цветовых схем, последовательностей полей вкладок, часто используемых элементов управления, графики фирменного стиля, уведомления о зарегистрированных товарных знаках и конфиденциальности и т. п.
3. Размер и конфигурация экрана или ограничения разрешения.
4. Стандартные кнопки, функции или ссылки перемещения, одинаковые для всех экранов, например кнопка справки.
5. Сочетания клавиш.
6. Стандарты отображения и текста сообщений.
7. Стандарты проверки данных. Например, то, какие ограничения накладываются на вводимые значения и когда нужно проверять содержимое полей.
8. Стандарты конфигурации интерфейса для упрощения локализации ПО.
9. Специальные возможности для пользователей с плохим зрением, проблемами с различением цветов и другими ограничениями.
➤ 5.2. Интерфейсы ПО
1. Описание связи продукта с другими компонентами ПО, идентифицированными по имени и версии. Это могут быть другие приложения, базы данных, операционные системы, средства, библиотеки, веб-сайты и интегрированные серийные компоненты.
2. Назначение, форматы и содержимое сообщений, данных и контрольных значений, обмен которыми происходит между компонентами ПО.
3. Соответствия между входными и выходными данными между системами. Описание всех преобразований, которые должны происходить с данными при перемещении между системами.
4. Службы, необходимые внешним компонентам ПО, природа взаимодействия между компонентами.
5. Данные, которыми будут обмениваться и к которым будут иметь общий доступ компоненты ПО.
6. Нефункциональные требования, влияющие на интерфейс, такие как уровни обслуживания для времени и частоты отклика или меры и ограничения безопасности. Часть этой информации может быть определена как требования к данным в разделе 4 или как требования к взаимодействию в разделе «6. Атрибуты качества».
➤ 5.3. Интерфейсы оборудования
В этом разделе указывается описание характеристик каждого интерфейса между компонентами ПО и элементами оборудования системы. В описание могут входить типы поддерживаемых устройств, взаимодействия данных и элементов управления между ПО и оборудованием, а также протоколы взаимодействия. Здесь перечисляются входные и выходные данные, их формат, разрешенные значения или их диапазоны, а также все временные характеристики, о которых должны знать разработчики. Если такой информации слишком много, лучше создать отдельный документ спецификации интерфейса.
➤ 5.4. Коммуникационные интерфейсы
Здесь приводится описание требований для любых функций взаимодействия, которые будут использоваться продуктом, включая электронную почту, веб-браузер, сетевые протоколы и электронные формы. Определяются соответствующие форматы сообщений. Описываются особенности безопасности взаимодействия или шифрования, скорости передачи данных и механизмов согласования и синхронизации. Указываются все ограничения этих интерфейсов, например допустимость тех или иных типов вложений в сообщениях электронной почты.
➤ 6. Атрибуты качества
В этом разделе описываются нефункциональные требования, помимо ограничений, описанных в разделе 2.4, и требований к внешним интерфейсам, описанных в разделе 5. Эти характеристики должны быть точно определены, и они должны поддаваться проверке и измерению. Здесь указывают относительные приоритеты различных атрибутов, например приоритет простоты использования над легкостью изучения или приоритет безопасности над производительностью. Необходимые степени качества удается гораздо эффективнее описать с помощью подробных нотаций спецификации (например, Planguage), чем простых описательных утверждений.
➤ 6.1. Удобство использования
Требования к удобству использования подразумевают легкость изучения, простоту использования, предотвращение ошибок и восстановление, эффективность взаимодействия и специальные возможности. Указанные в этом разделе требования к удобству использования помогут дизайнеру интерфейсов создать максимально удобную для пользователя рабочую среду.
➤ 6.2. Производительность
В этом разделе указываются конкретные требования к производительности для различных системных операций. Если у различных функциональных требований или функций разные требования к производительности, то задачи, связанные с производительностью, указывают там же, в разделе соответствующих функциональных требований, а не включают их все в этот раздел.
➤ 6.3. Безопасность
В этом разделе приводятся все требования, касающиеся безопасности или конфиденциальности, которые ограничивают доступ или возможности использования продукта. Это может быть физическая безопасность, а также защита данных или ПО. Источник требований к безопасности – это обычно бизнес-правила, поэтому здесь определяют политики или положения, касающиеся защиты или конфиденциальности, которым продукт должен соответствовать. Если они задокументированы в хранилище бизнес-правил, то на них дают ссылку.
➤ 6.4. Техника безопасности
Здесь указываются требования, связанные с возможными потерями, повреждениями или ущербом, которые могут являться результатом использования продукта. В этом разделе приводятся меры безопасности или упреждающие действия, которые можно предпринять, и потенциально опасные действия, которые можно предотвратить. Указываются сертификаты по безопасности, политики или положения, которым должен соответствовать продукт.
➤ 6.5. [Другие]
Для каждого дополнительного атрибута качества продукта в спецификации требований к ПО создают отдельный раздел, чтобы описать характеристики, которые будут важны для клиентов или для разработчиков и сотрудников, ответственных за поддержку. Это может быть доступность, возможность установки, целостность, возможность модификации, переносимость, надежность, устойчивость, масштабируемость и контролируемость.
➤ 7. Требования по интернационализации и локализации
Требования по интернационализации и локализации обеспечивают возможность использовать продукт в других странах, региональных стандартах и географических районах, отличающихся от тех, в которых он был создан.
Такие требования могут быть направлены на устранение различий между валютами, в форматировании дат, чисел, адресов и телефонных номеров, языках, в том числе различных вариантах одного языка (например, американского и британского вариантов английского), используемых символах и наборах символов, личных именах и фамилиях, часовых поясах, международных нормативных актах и законах, культурных и политических традициях, размере используемой бумаги, единицах веса и меры, значениях электрического напряжения, конфигурации электрических разъемов и во многом другом. Требования по интернационализации и локализации вполне могут повторно использоваться во многих проектах.
➤ 8. Остальные требования
В этом разделе указываются все другие требования, которые еще не были описаны в спецификации требований к ПО. Например, юридические, законодательные или финансовые требования и требования стандартов, требования к установке, конфигурированию, запуску и остановке продукта, а также к регистрации данных, мониторингу и т. д.
Для различных требований следует добавить новые разделы к шаблону вашего проекта. Например, это могут быть требования к переходу, которые необходимы для миграции с предыдущей системы на новую, если они относятся к создаваемому ПО. Допустим, к программам преобразования данных. В противном случае их можно включить в план управления проектом, например если речь идет о разработке обучающих материалов или поставке.
➤ Приложение A. Словарь терминов
В этом разделе содержатся все специальные термины, которые необходимо знать пользователю для правильного понимания спецификации требований к ПО, включая сокращения и аббревиатуры. Для каждого сокращения должна приводиться расшифровка и его определение. При необходимости можно создать расширенный общекорпоративный словарь для нескольких проектов, в котором будут содержаться ссылки на все термины, относящиеся к данному проекту. В этом случае в спецификации требований к ПО будут определены только те термины, которые относятся лишь к данному проекту и не входят в общекорпоративный словарь. Определения данных находятся в словаре данных, а не терминов.
➤ Приложение Б. Модели анализа
В этом необязательном разделе упоминаются такие модели анализа, как диаграммы потоков данных, деревья функций, диаграммы переходов состояния и диаграммы «сущность – связь». Часто для большего удобства пользователей определенные модели помещают в соответствующие разделы спецификации, а не собирают все вместе в конце.
Спецификация требований в проектах гибкой разработки
В проектах agile применяют ряд способов определения требований, которые отличаются от только что описанного метода.
Во многих проектах agile в процессе выявления требований используются пользовательские истории. Каждая такая история – это формулировка потребности пользователя или функциональности, которая может быть полезной пользователю или покупателю системы. В проектах agile команда может начать создавать спецификацию, записывая достаточное количество информации по каждой пользовательской истории, чтобы заинтересованные лица получили общее представление о содержании истории и смогли определить приоритеты историй друг относительно друга. Это также позволяет команде начать планировать назначение историй на конкретные итерации. Команда может собирать связанные истории в минимально поддающуюся для продвижения на рынке функцию, которую нужно реализовать целиком к выпуску продукта, чтобы клиент мог получить от нее пользу.
Пользовательские истории накапливаются и приоритизируются в резерве продукта (product backlog), который меняется на протяжении всего проекта. Крупные истории, которые охватывают значительную функциональность и не могут быть реализованы в одной итерации, стоит разбить на более мелкие и назначить на конкретные итерации. Пользовательские истории можно записывать на чем-то простом, например на карточках каталога, а не в традиционном документе. Одни команды гибкой разработки сохраняют свои истории в средстве управления историями после реализации, а другие не делают этого.
Когда команда приступает к очередной итерации, каждая история, назначенная на эту итерацию, уточняется и наполняется деталями в процессе обсуждения между владельцем продукта, людьми, выполняющими роль бизнес-аналитиков, аналитиками, тестировщиками и пользователями. То есть спецификация подразумевает постепенное уточнение подробностей на каждом этапе проекта, что является хорошей практикой в любом проекте. Обычно эти подробности соответствуют тому, что мы называли функциональными требованиями в спецификации требований к ПО.
Однако в проектах agile эти подробности часто представляют в форме приемочных тестов, описывающих, как система должна вести себя при правильной реализации истории. Тесты истории проводят во время итерации, в которой реализуется эта история, и в будущих итерациях в рамках регрессионного тестирования. Как и в любых других тестах, в них должны выполняться исключительные условия и ожидаемое поведение. Эти приемочные тесты можно записывать на карточках или регистрировать в более постоянной форме, например в средстве тестирования. Для быстрого и полного регрессионного тестирования тесты необходимо автоматизировать. Если команда решит отказаться от исходных пользовательских историй, приемочными тестами может послужить постоянная документация требований при условии их хранения в специализированном средстве.
Нефункциональные требования также можно записывать на карточках, но не как пользовательские истории, а как ограничения (Cohn, 2004). Альтернативный вариант – указывать нефункциональные требования, относящиеся к конкретной пользовательской истории, в виде критериев приемки, чтобы продемонстрировать соответствие определенным атрибутам качества. Например, тесты безопасности могут демонстрировать, что только конкретным пользователям разрешен доступ к функциональности, описанной в соответствующей пользовательской истории, а остальным пользователям доступ закрыт. Команде гибкой разработки не возбраняется применять другие методы представления знаний о требованиях, такие как модели анализа или словарь данных. Разработчики должны выбирать метод представления, который привычен и уместен в их культуре и проекте.
Выбор надлежащих форм спецификации требований к ПО – исключительная прерогатива команды проекта. Главная цель разработки требований – собрать общее понимание требований, качество которых отвечает необходимым критериям для того, чтобы приступить к разработке следующей части продукта и продолжить работу при приемлемом уровне риска.
Надлежащий уровень формальности и подробности документа требований зависит от многих факторов, в числе которых:
• объем оперативного неформального вербального и визуального общения между клиентами и разработчиками, который необходим для получения подробностей, обязательных для правильной реализации каждого пользовательского требования;
• предел, до которого неформальные методы общения могут обеспечить эффективную синхронизацию во времени и пространстве внутри команды;
• граница, до которой необходимо сохранять знания о требованиях для будущих улучшений, реинжиниринга приложения, проверки, аудита, проверки на соответствие нормативам, сертификации продукта или в соответствии с условиями контракта;
• граница, до которой приемочные тесты могут эффективно заменять описания ожидаемых возможностей и поведения системы;
• предел, до которого человеческая память может заменить письменное представление.
Независимо от типа продукта, который создает команда, используемой методики разработки или применяемых бизнес-аналитиком приемов выявления требований, эффективная спецификация требований жизненно важна для успеха. Существует много путей достижения этой цели. Но если не определить высококачественные требования, полученный в результате продукт будет как коробка с сюрпризом: вы никогда не будете знать, что от него ожидать.