В процессе сбора требований важно принимать во внимание возможные противоречия требований различных заинтересованных лиц, таких как заказчики, разработчики или пользователи.
Полнота и качество анализа требований играют ключевую роль в успехе всего проекта. Требования к ПО должны быть документируемые, выполнимые, тестируемые, с уровнем детализации, достаточным для проектирования системы. Требования могут быть функциональными и нефункциональными.
Анализ требований включает три типа деятельности:
Сбор требований — общение с клиентами и пользователями, чтобы определить, каковы их требования; анализ предметной области.
Анализ требований — определение, являются ли собранные требования неясными, неполными, неоднозначными или противоречащими; решение этих проблем; выявление взаимосвязи требований.
Документирование требований — требования могут быть задокументированы в различных формах, таких как простое описание, сценарии использования, пользовательские истории, или спецификации процессов.
Анализ требований может быть длинным и трудным процессом, в который вовлечены много тонких психологических навыков. Новые системы изменяют окружающую среду и отношения между людьми, поэтому важно определить всех заинтересованных лиц, принять во внимание все их потребности и гарантировать, что они понимают значение внедрения новых систем. Аналитики могут использовать несколько методов, чтобы выявить требования от клиента: проведение интервью, использование фокус-групп или создание списков требований. Более современные методы включают создание прототипов и сценариев использования. Где необходимо, аналитик будет использовать комбинацию этих методов, чтобы выявить точные требования заинтересованных лиц так, чтобы была создана система, которая удовлетворяет деловые потребности.
Стейкхолдер — физическое лицо или организация, имеющая права, долю, требования или интересы относительно системы или её свойств, удовлетворяющих их потребностям и ожиданиям (ISO/IEC 15288:2008, ISO/IEC 29148:2011).
Опрос стейкхолдеров
Опрос стейкхолдеров является широко используемой техникой при сборе требований. Эти опросы могут выявлять требования, не попавшие в рамки проекта либо противоречащие ранее собранным. Однако каждый стейкхолдер будет иметь собственные требования, ожидания и видение системы.
Сеансы совместного развития требований (СРТ)
Требования часто имеют сложное пересекающееся функциональное назначение, не известное отдельным стейкхолдерам. Такие требования часто упускаются или не полностью определяются во время их опросов. Такие требования могут быть выявлены при проведении сеансов СРТ. Такие сеансы проводятся под надзором подготовленного специалиста. Стейкхолдеры участвуют в обсуждениях, чтобы определить требования, проанализировать их детали и выявить скрытые пересекающиеся взаимосвязи между требованиями.
Традиционный способ документировать требования — это создание списков требований. В сложной системе такие списки требований могут занимать сотни страниц.
Преимущества
Обеспечивает контрольный список требований.
Обеспечивает договор между заказчиками и разработчиками.
Для большой системы может обеспечить описание высокого уровня.
Недостатки
Такие списки могут занимать сотни страниц. Фактически невозможно прочитать такие документы в целом и получить чёткое понимание системы.
Такие списки требований перечисляют отдельные требования абстрактно, оторванно друг от друга и от контекста использования
Эта абстракция лишает возможности видеть, как требования связываются между собой или работают вместе.
Эта абстракция мешает верно расположить требования по приоритетам; в то время как список действительно облегчает приоритизацию отдельных пунктов, удаление одного пункта из контекста может сделать весь сценарий использования или деловое требование бесполезным.
Эта абстракция увеличивает вероятность неверного трактования требований, поскольку чем большее число людей будет их читать, тем большее будет число (различных) интерпретаций системы.
Эта абстракция означает, что чрезвычайно трудно убедиться, что у вас есть все необходимые требования.
Эти списки создают ложное чувство взаимопонимания между заинтересованными лицами и разработчиками.
Эти списки дают заинтересованным лицам ложное чувство защищённости, что разработчики должны достигнуть определённых вещей. Однако, из-за природы этих списков, они неизбежно упускают важные требования, которые будут выявлены позже в процессе. Разработчики могут использовать новые требования для пересмотра сроков и условий в свою пользу.
Альтернативы спискам требований
Альтернативами большим, предопределенным спискам требований могут служить пользовательские истории, которые определяют требования обычным языком.
Измеримые цели
Лучшие методы рассматривают составленный список требований просто как подсказки и постоянно спрашивают «почему?», пока не будут выявлены истинные деловые цели. После этого заинтересованные лица и разработчики могут разработать тесты, измеряющие, какой уровень каждой цели был достигнут. Такие цели изменяются медленнее, чем длинный список определённых, но неизмеримых требований. Как только маленький набор критических, измеримых целей установлен, быстрое прототипирование и короткие этапы разработки могут дать заинтересованным лицам реальную ценность ещё до окончания проекта.
Прототипы (опытные образцы)
В середине 1980-х прототипирование (англ.prototyping) рассматривалось как решение проблемы анализа требований. Прототипы — макеты системы. Макеты дают возможность пользователям представить систему, которая ещё не построена. Опытные образцы помогают пользователям представить, на что будет похожа система, и облегчают пользователям принятие проектных решений, не дожидаясь окончания постройки системы. Наибольшие улучшения во взаимопонимании между пользователями и разработчиками часто замечались с введением опытных образцов. Ранние обзоры системы приводят к меньшему количеству изменений на поздних стадиях разработки и, следовательно, значительно уменьшают затраты.
Однако за следующее десятилетие прототипирование хоть и было признано эффективной техникой, но не решило проблему анализа требований:
Менеджерам, как только они видят опытный образец, сложно понять, что окончательный проект не будет разработан ещё некоторое время.
Проектировщики часто чувствуют себя вынужденными использовать опытный образец в реальной системе, потому что они боятся «напрасно тратить время», начиная всё сначала.
Опытные образцы преимущественно помогают с проектными решениями и дизайном пользовательского интерфейса. Однако они не могут сказать вам, какими были первоначальные требования.
Проектировщики и конечные пользователи могут слишком сильно сосредоточиться на дизайне пользовательского интерфейса и слишком мало на производстве системы, которая служит бизнес-процессу.
Прототипы отлично подходят для пользовательских интерфейсов, но мало полезны для сложной обработки данных или асинхронных процессов, которые могут вовлечь сложные обновления базы данных и/или вычисления.
Опытные образцы могут быть плоскими диаграммами (часто называемые каркасами) или рабочими программами, использующими синтетические функциональные возможности. Каркасы могут быть представлены графическими документами. В случаях, где законченное программное обеспечение должно иметь графическое оформление, из каркаса удаляют цвет (то есть используют серую палитру цветов). Это помогает предотвратить недоразумения по поводу окончательного вида программы.
Сценарии использования
Вариант использования (англ.Use Case) — техника для документации потенциальных требований для создания новой системы или изменения существующей. Каждый вариант описывает один или несколько способов взаимодействия системы с конечным пользователем или другой системой, для достижения определённой цели. Варианты использования обычно избегают технического жаргона, предпочитая вместо этого язык конечного пользователя или эксперта в данной области. Они часто создаются совместно специалистами по сбору требований и заинтересованными лицами.
Варианты использования — наиболее важный инструмент для моделирования требований с целью спецификации функциональных возможностей разрабатываемого программного обеспечения или системы в целом. Они могут содержать дополнительное текстовое описание всех способов, которыми пользователи могут работать с программным обеспечением или системой. Такое текстовое описание называется сценарием. Как правило, варианты использования отвечают на вопрос «Что должна выполнить система для конкретного актора (англ.Actor)?», не отвечая на вопрос «Каким образом система должна это реализовать?» Текст сценария в этом случае дополняет графическое представление вариантов использования в форме описания последовательности шагов или действий, следуя которым пользователь может достичь желаемой цели при взаимодействии с системой. Полнота функциональных требований к разрабатываемой системе достигается спецификацией всех вариантов использования с соответствующими сценариями, отражающими все пожелания и потребности пользователей к разрабатываемой системе.
Спецификация требований программного обеспечения
Спецификация требований программного обеспечения (англ.Software Requirements Specification, SRS) является полным описанием поведения системы, которая будет создана. Она включает ряд сценариев использования, которые описывают все виды взаимодействия пользователей с программным обеспечением. Сценарии использования также известны как функциональные требования. В дополнение к сценариям использования, спецификация программного обеспечения также содержит нефункциональные (или дополнительные) требования. Нефункциональные требования — требования, которые налагают дополнительные ограничения на систему (такие как требования эффективности работы, стандарты качества, или проектные ограничения).
Рекомендуемые подходы для спецификации требований программного обеспечения описаны стандартом IEEE 830—1998. Этот стандарт описывает возможные структуры, желательное содержание, и качества спецификации требований программного обеспечения.
Требования систематизируются несколькими способами. Ниже представлены общие классификации требований, которые касаются технического управления.
Требования клиентов
Клиенты - это те, кто выполняет основные функции системного проектирования, со специальным акцентом на пользователе системы как ключевом клиенте. Пользовательские требования определят главную цель системы и, как минимум, ответят на следующие вопросы:
Требования эксплуатации или развёртывания: Где система будет использоваться?
Профиль миссии или сценарий: Как система достигнет целей миссии?
Требования производительности: Какие параметры системы являются критическими для достижения миссии?
Сценарии использования: Как различные компоненты системы должны использоваться?
Требования эффективности: Насколько эффективной должна быть система для выполнения миссии?
Эксплуатационный жизненный цикл: Как долго система будет использоваться?
Окружающая среда: Каким окружением система должна будет эффективно управлять?
Функциональные требования
Функциональные требования объясняют, что должно быть сделано. Они идентифицируют задачи или действия, которые должны быть выполнены. Функциональные требования определяют действия, которые система должна быть способной выполнить, связь входа/выхода в поведении системы.
Нефункциональные требования
Нефункциональные требования — требования, определяющие свойства, которые система должна демонстрировать, или ограничения, которые она должна соблюдать, не относящиеся к поведению системы. Например, производительность, удобство сопровождения, расширяемость, надежность, факторы эксплуатации.
Производные требования
Требования, которые подразумеваются или преобразованы из высокоуровневого требования. Например, требование для большего радиуса действия или высокой скорости может привести к требованию низкого веса.
Известные модели классификации требований включают FURPS и FURPS+, разработанные в Hewlett-Packard.
Стив Макконнелл, в его книге «Быстрая разработка»[2], подробно описывает, как пользователи могут препятствовать сбору требований:
пользователи не понимают то, что они хотят, или у пользователей нет ясного представления об их требованиях;
пользователи не соглашаются с ранее записанными требованиями;
пользователи настаивают на новых требованиях после того, как стоимость и график работ были установлены;
коммуникация с пользователями является медленной;
пользователи часто не участвуют в обзорах требований или неспособны в них участвовать;
пользователи технически не подготовлены;
пользователи не понимают процесса разработки ПО.
Это может привести к ситуации, где пользовательские требования продолжают изменяться, даже когда система или разработка новой продукции были начаты.
Проблемы инженеров / разработчиков
Возможные проблемы, вызванные инженерами и разработчиками во время анализа требований:
У технического персонала и конечных пользователей могут быть различные мнения. Следовательно, они могут неправильно полагать, что они находятся во взаимопонимании, пока готовое изделие не будет отправлено.
Инженеры и разработчики могут попытаться подкорректировать требования, чтобы они соответствовали существующей системе или модели, вместо того, чтобы разработать систему, соответствующую потребностям клиента.
Решения проблем
Одно из решений проблемы общения состояло в том, чтобы нанять специалистов в деловом или системном анализе.
