Интернет магазин китайских планшетных компьютеров |
|
Компьютеры - Анализ требований - Спецификация требований23 января 2011Оглавление: 1. Анализ требований 2. Фазы 3. Спецификация требований 4. Типы требований 5. Проблемы анализа требований Списки требованийОдним традиционным способом документировать требования было создание списков требований. В сложной системе такие списки требований могут занимать сотни страниц. Соответствующей метафорой может быть чрезвычайно длинный список покупок в магазине. Такие списки крайне не эффективны в современном анализе, хотя используются и по сей день. Преимущества
Недостатки
Альтернативы спискам требованияАльтернативами большим, предопределённым спискам требований могут служить пользовательские истории которые определяют требования обычным языком. Измеримые целиЛучшие методы рассматривают составленный список требований просто как подсказки и постоянно спрашивают «почему?» пока не будут выявлены истинные деловые цели. После этого заинтересованные лица и разработчики могут разработать тесты измеряющие, какой уровень каждой цели был достигнут. Такие цели изменяются медленнее чем длинный список определённых но неизмеримых требований. Как только маленький набор критических, измеримых целей установлен, быстрое прототипирование и короткие этапы разработки могут дать заинтересованным лицам реальную ценность ещё до окончания проекта. ПрототипыВ середине 1980-х прототипирование рассматривалось как решение проблемы анализа требований. Прототипы макеты системы. Макеты дают возможность пользователям представить систему, которая ещё не построена. Опытные образцы помогают пользователям представить на что будет похожа система, и облегчают пользователям принятие проектных решений, не дожидаясь окончания постройки системы. Наибольшие улучшения во взаимопонимании между пользователями и разработчиками часто замечались с введением опытных образцов. Ранние обзоры системы приводят к меньшему количеству изменений на поздних стадиях разработки и следовательно значительно уменьшают затраты. Однако, за следующее десятилетие, прототипирование хоть и было признано эффективной техникой, однако не решило проблему анализа требований:
Опытные образцы могут быть плоскими диаграммами или рабочими программами, использующими синтетические функциональные возможности. Каркасы могут быть представлены графическими документами. В случаях, где законченное программное обеспечение должно иметь графическое оформление, из каркаса удаляют цвет. Это помогает предотвратить недоразумения по поводу окончательного вида программы. Сценарии использованияСценарий использования техника для документации потенциальных требований для создания новой системы или изменения существующей. Каждый сценарий описывает один или несколько вариантов взаимодействия системы с конечным пользователем или другой системой, для достижения определённой деловой цели. Сценарии использования обычно избегают технического жаргона, предпочитая вместо этого язык конечного пользователя или эксперта в данной области. Они часто создаются совместно специалистами по сбору требований и заинтересованными лицами. Сценарии использования простые инструменты для того, чтобы описать поведение программного обеспечения или систем. Они содержат текстовое описание всех способов, которыми пользователи могут работать с программным обеспечением или системой. Сценарии не описывают ни внутренней работы системы, ни способа создания системы. Они просто показывают шаги, которым пользователь следует, чтобы выполнить задачу. Все способы, по которым пользователи взаимодействуют с системой, могут быть описаны в этой манере. Спецификация требований программного обеспеченияСпецификация требований программного обеспечения является полным описанием поведения системы, которая будет создана. Она включает ряд сценариев использования, которые описывают все виды взаимодействия пользователей с программным обеспечением. Сценарии использования также известны как функциональные требования. В дополнении к сценариям использования, спецификация программного обеспечения также содержат нефункциональные требования. Нефункциональные требования требования, которые налагают дополнительные ограничения на систему. Рекомендуемые подходы для спецификации требований программного обеспечения описаны стандартом IEEE 830—1998. Этот стандарт описывает возможные структуры, желательное содержание, и качества спецификации требований программного обеспечения. Просмотров: 5538
|