Документация и требования

Требования

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

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

1. Единичность — требование описывает одну и только одну вещь.
2. Завершенность — требование полностью определено в одном месте и вся необходимая информация присутствует.
3. Последовательность — требование не противоречит другим требованиям и полностью соответствует документации.
4. Атомарность — требование нельзя разделить на более мелкие.
5. Отслеживаемость — требование полностью или частично соответствует деловым нуждам как заявлено заинтересованными лицами и задокументировано.
6. Актуальность — требование не стало устаревшим с течением времени.
7. Выполнимость — требование может быть реализовано в рамках проекта.
8. Недвусмысленность — требование определено без обращения к техническому жаргону, акронимам и другим скрытым формулировкам. Оно выражает объекты и факты, а не субъективные мнения. Возможна одна и только одна его интерпретация. Определение не содержит нечетких фраз, использование отрицательных и составных утверждений запрещено.
9. Обязательность — требование представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятия требования.
10. Проверяемость — реализованность требования может быть проверена.

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

1. Что ПО должно делать. Пример — Позволять клиенту оформить заказы и обеспечить их доставку;
2. Насколько оно должно быть надежно. Пример — Работать 7 дней в неделю и 24 часа в сутки;
3. Насколько им должно быть удобно пользоваться. Пример — Покупатель должен легко находить нужный ему товар;
4. Насколько оно должно быть эффективно. Пример — Поддерживать обслуживание до 10000 запросов в секунду;
5. Насколько удобно должно быть его сопровождение. Пример — Добавление в систему нового вида запросов не должно требовать более 3 человеко-дней;
6. Насколько оно должно быть переносимо и заменяемо. Пример — ПО должно работать на операционных системах Linux, Windows XP и Mc OS X;

Уровни требований (по К.Вигерсу)

Обычно выделяют три уровня требований:
1. На верхнем уровне представлены так называемые бизнес-требования (business requirements). Примеры бизнес-требования: система должна сократить срок оборачиваемости обрабатываемых на предприятии заказов в три раза. Бизнес-требования обычно формулируются топ-менеджерами, либо акционерами предприятия.
2. Следующий уровень – уровень требований пользователей (user requirements). Пример требования пользователя: система должна представлять диалоговые средства для ввода исчерпывающей информации о заказе, последующей фиксации информации в базе данных и маршрутизации информации о заказе к сотруднику, отвечающему за его планирование и исполнение. Требования пользователей часто бывают плохо структурированными, дублирующимися, противоречивыми. Поэтому для создания системы важен третий уровень, в котором осуществляется формализация требований.
3. Третий уровень – функциональный (functional requirements). Пример функциональных требований (или просто функций) по работе с электронным заказом: заказ может быть создан, отредактирован, удалён и перемещён с участка на участок.

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

1. Функциональные требования описывают, что делает система, это требования к первой составляющей качества — функциональности. Эти требования обычно ориентированы на действия (Когда пользователь нажимает кнопку «Обработать заказ», система сохраняет данные заказа в БД и определяет его статус как «В очереди на обработку»).
При определении функциональных требований следует искать золотую середину между слишком конкретизированной формулировкой требования и слишком общей и неоднозначной. Требования должны оставаться понятными заказчикам и стать более понятны разработчикам.
К функциональным требованиям относят:
1.1. Бизнес-требования. Что система должна делать с точки зрения бизнеса. Слово «бизнес» в данном контексте ближе к слову «заказчик». Пример бизнес-требования: промо-сайт, привлекающий внимание определенной аудитории к определенной продукции компании.
1.2. Пользовательские требования – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования. Иначе говоря, пользовательские требования — это что может сделать пользователь: зарегистрироваться, посмотреть определенную информацию, пересчитать данные по определенному алгоритму и прочее.
1.3. Функциональные требования – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований. Другими словами, что будут делать разработчики, чтобы выполнить пользовательские требования.
1.4. В группу функциональных требований относят и Системные требования. Эти характеристики могут описывать требования как к аппаратному обеспечению (тип и частота процессора, объём оперативной памяти, объём жесткого диска), так и к программному окружению (операционная система, наличие установленных системных компонентов и сервисов и т. п.). Обычно такие требования составляются производителем или автором ПО. Например, для игры это могут быть требования такого типа: видеокарта — объём памяти от 64 Мб, совместимость сDirectX 9.0b и новейшие драйвера. Для сайта: ОС — Windows не ниже XP, браузеры IE не ниже 7.0 и так далее.

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

2. Нефункциональные требования, соответственно, регламентируют внутренние и внешние условия или атрибуты функционирования системы. К. Вигерс [2] выделяет следующие основные группы нефункциональных требований:
2.1. Бизнес-правила. Они определяют почему система работать должна именно так, как написано. Это могут быть ссылки на законодательство, внутренние правила заказчика и прочие причины. Часто упускают этот раздел и получается, что некоторые системные решения выглядят нетипичным и совсем неочевидными. Например, многие табачные компании и компании, производящие алкоголь требуют постоянного доказательства того, что промо-сайтами пользуются люди, достигшие определенного возраста. Это бизнес-правило (подтверждение возраста) возникает по требованию этических комитетов заказчика, хотя и несколько противоречит маркетинговым целям и требованиям по usability.
2.2. Внешние интерфейсы. Это не только интерфейсы пользователя, но и протоколы взаимодействия с другими системами. Например, часто сайты связаны с CRM системами. Особенности протокола взаимодействия «сайт-CRM» также относятся к нефункциональным требованиям.
2.3. Атрибуты качества. Атрибуты касаются вопросов прозрачности взаимодействия с другими системами, целостности, устойчивости и т.п. К таким характеристикам относятся:
— легкость и простота использования (usability)
— производительность (performance)
— удобство эксплуатации и технического обслуживания (maintainability)
— надежность и устойчивость к сбоям (reliability)
— взаимодействия системы с внешним миром (interfaces)
— расширяемость (scalability)
— требования к пользовательским и программным интерфейсам (user and software interface).
2.4. Ограничения – формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных и т.д.). Ограничения часто основываются на бизнес-правилах.

Выявление требований

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

Стадию выявления и представления требований условно можно разделить на 4 этапа:
1. Выявление требований сбор информации.
2. Первичный анализ требований.
3. Документация требований.
4. Проверка требований.

Данные этапы будут выполняться, чередуясь и периодически повторяясь. Этот итерационный процесс и есть процедура выявления требований.

Источники требований

1. Заинтересованные лица – как правило, являются первым и основным источником требований.Заинтересованные лица – как правило, являются первым и основным источником требований;
2. Документация – все документы, присутствующие в компании или относящиеся к правовой системе страны\бизнеса, являются источником требований, который чаще всего определяет те или иные ограничения проекта;
3. Сегмент рынка\бизнеса – конкурентные системы будущего продукта являются незаменимым источником требований. Благодаря изучению систем-аналогов можно существенно уменьшить время на выявление требований. Также незаменимым источником являются различные маркетинговые материалы;
4. Бизнес заказчика – специфика бизнеса заказчика, наблюдение за работой будущих пользователей, бизнес-процессы организации – все так или иначе создает образ будущей системы и позволяет точнее определить потребности заказчика, а также проблемы, которая будущая система призвана решить.

Способы выявления требований

1. Опрос – подразумевает опрос существующих и потенциальных пользователей продукта (например, интервью, анкеты);
2. Наблюдение – подразумевается наблюдение за работой пользователей;
3. Изучение правил работы пользователей по существующим регламентам/законодательству, а также изучение существующих документов, описывающих бизнес клиента или существующего продукта;
4. Анализ истории использования продукта по его техническим журналам;
5. Изучение существующих продуктов конкурентов на рынке;
6. Обсуждения и мозговые штурмы с пользователями и экспертами;
7. Маркетинговые исследования;
8. Моделирование – может включать в себя как моделирование существующих бизнес-процессов, так и верхнеуровневое моделирование будущей системы.

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

Стандарты

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

Функции стандартов

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

Уровни стандартов

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

• Международная стандартизация. Органом по стандартизации является ИСО (ISO). Нормативным документом ИСО являются стандарты ИСО.
• Межгосударственная стандартизация. Охватывает ряд независимых государств (СНГ, ЕЭС и др.). Нормативным документом стран СНГ является межгосударственный стандарт.
• Национальная стандартизация — это стандартизация в пределах одного государства (к примеру стандарты ДСТУ или ГОСТы).
• Правила, нормы и рекомендации в определенной области — действуют в границах определенных сфер деятельности (к примеру IEEE)
• Стандарты организаций — сюда входят стандарты предприятий, стандарты обществ и т. п.

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

Продуктная документация (product documentation)

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

• План продукта (Product Management Plan)
• Документ бизнес-требований (Business Requirements Document)
• Маркетинговая документация (Market Requirements Document)
• Документ требований к программному продукту (Product Requirements Document) или спецификация требований (Software Requirements Specification);
• Спецификация функциональных требований (Functional Specifications Document);
• Техническое задание (Terms of Reference TOR);
• Mind Maps, Макеты, Прототипы;
• Use Cases и User Story;
• Дизайн (Graphic Design, Web Design, Game design).

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

Проектная документация

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

• План проекта (Project Management Plan)
• Пользовательская и сопроводительная документация (User and Accompanying Documentation)