Интернет магазин китайских планшетных компьютеров

Компьютеры - Анализ требований - Спецификация требований

Списки требований

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

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

Преимущества

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

Недостатки

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

Альтернативы спискам требования

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

Измеримые цели

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

Прототипы

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

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

• Менеджерам, как только они видят опытный образец, сложно понять, что окончательный проект не будет разработан ещё некоторое время.
• Проектировщики часто чувствуют себя вынужденными использовать опытный образец в реальной системе, потому что они боятся «напрасно тратить время», начиная всё сначала.
• Опытные образцы преимущественно помогают с проектными решениями и дизайном пользовательского интерфейса. Однако, они не могут сказать Вам, какими были первоначальные требования.
• Проектировщики и конечные пользователи могут слишком сильно сосредоточиться на дизайне пользовательского интерфейса и слишком мало на производстве системы, которая служит бизнес-процессу.
• Прототипы отлично подходят для пользовательских интерфейсов, но мало полезны для сложной обработки данных или асинхронных процессов, которые могут вовлечь сложные обновления базы данных и/или вычисления.

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

Сценарии использования

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

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

Спецификация требований программного обеспечения

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

Рекомендуемые подходы для спецификации требований программного обеспечения описаны стандартом IEEE 830—1998. Этот стандарт описывает возможные структуры, желательное содержание, и качества спецификации требований программного обеспечения.