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

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

Форест Гамп прекрасно выразил эту идею, когда сказал: «Если вы не знаете куда идете, то вы вряд ли туда дойдете».

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

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

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

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

Несовершенство способов «неформального» сбора информации о предполагаемой функциональности

Масса проблем с ПО возникает из-за несовершенства способов, которые люди применяют для сбора, документирования, согласования и модификации требований к ПО.

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

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

Заинтересованные лица (stakeholders)

Нигде более, как на стадии сбора требований, так тесно не связаны интересы всех заинтересованных в проекте лиц с успехом проекта.

К заинтересованным в проекте лицам относятся:

• заказчики, которые финансируют проект или приобретают продукт для решения каких-то бизнес-задач;

• пользователи, которые взаимодействуют напрямую или не напрямую с приложением (подкласс заказчиков);

• аналитики требований, которые пишут требования и передают их разработчикам;

• разработчики, которые создают, разворачивают и поддерживают продукт;

• тестеры, которые определяют соответствие поведения ПО желаемому;

• технические писатели, которые отвечают за создание руководства пользователей, тренировочные материалы и справочную систему;

• менеджер по проекту, который планирует процесс и руководит командой разработчиков вплоть до успешного выпуска продукта;

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

• производственники, которые должны построить продукт, содержащий данное ПО;

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

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

Основной закон: требования должны быть документированы. Не является редким случай, когда в проекте меняется состав исполнителей. Когда в очередной раз к заказчику приходит еще один аналитик требований и говорит: «Мы должны поговорить о том, что же вам нужно», заказчик впадает в неистовство: «Я уже излагал свои требования. А теперь постройте мне систему!» Дело в том, что никто не документировал собранную информацию, поэтому каждому новому аналитику приходилось начинать с набросков. Полный бред объявлять о готовности требований, если на самом деле у вас есть куча электронных писем, голосовых сообщений, записок, протоколов совещаний и неясных воспоминаний о беседах в коридоре.

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

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

Типы требований

Разработка требований и управление ими — трудный процесс! Здесь нет быстрых или волшебных решений.

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

Требования - это:

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

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

3. документированное представление условий или возможностей для пунктов 1 и 2.

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

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

Термином системные требования (system requirements) обозначают высокоуровневые требования к продукту, которые содержат многие подсистемы, то есть система. Говоря о системе, мы подразумеваем программное обеспечение или подсистемы ПО и оборудования. Люди — часть системы, поэтому определенные функции системы могут распространяться и на людей.

Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы. Спецификация требований к ПО используется при разработке, тестировании, гарантии качества продукта, управлении проектом и связанных с проектом функциях.

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

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

Отсутствие выявления и спецификации требований как фактор разрушения и провала проекта

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

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

Итерации при кодировании стоят гораздо дороже, чем при разработке концепций.

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

Основное следствие проблем с требованиями — переделка того, что, как предполагается, уже готово. На это расходуется от 30 до 50% общего бюджета разработки, а ошибки в требованиях стоят от 70 до 85% стоимости переделки.

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

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

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

Выявление и спецификация требований – основа успешного проекта

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

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

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

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

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

Невозможно количественно оценить все преимущества, однако они реальны:

• меньше дефектов в требованиях;

• меньше переделок;

• меньше ненужных функций;

• ниже стоимость модификации;

• быстрее разработка

• меньше беспорядка в проекте;

• точнее оценки тестирования;

• выше удовлетворение заказчиков и разработчиков.

Требования к спецификации требований

Характеристики отдельных положений спецификации требований

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

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

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

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

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

• Недвусмысленность.
  Все читатели требований должны интерпретировать их одинаково, но естественный язык зачастую грешит многозначностью. «Ясность»— цель качества требований, связанная с точностью: читатели должны четко понимать каждое положение. Все специальные и запутанные термины необходимо определять и заносить в словарь (глоссарий).

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

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

• Полнота.
  Никакие требования или необходимые данные не должны быть пропущены.

• Согласованность.
  Согласованные требования не конфликтуют с другими требованиями такого же типа или с высокоуровневыми пользовательскими, системными или бизнес-требованиями.

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

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