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

Что такое требование? За долгие годы уже появилось множество определений требований к программ­ному обеспечению, вполне приемлемым является следующее определение, предложен­ное специалистами в области разработки требований Дорфманом (Dorfman) и Тэйером (Thayer).

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

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

Многие наиболее часто встречающиеся серьезные проблемы при разработке программного обеспечения связаны именно с требованиями. Результат опроса орга­низации ESPITI (European Software Process Improvement Training Initiative— Европей­ская инициатива по обучению совершенствованию процесса программирования) показал, что двумя самыми главными проблемами, упоминавшимися почти в половине ответов, оказались следующие:

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

· управление требованиями клиента

К тому же наиболее дорогостоящим является исправление ошибок, допущенных на этапе формирования требований.

 

Проблемы сбора требований

 

Процесс сбора требований весьма сложен по следующим причинам:

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

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

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

Методы сбора требований

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

Для этого используются:

· Интервьюирование и анкетирование

· Мозговой штурм и отбор идей

· Сценарии (прецеденты)

· Прототипирование

· Обыгрывание ролей

Выбор конкретного метода будет зависеть от типа ИС, опыта и уровня под­готовки команды разработчиков, заказчика, масштаба проблемы, используемой технологии и уникальности ИС.

Интервьюирование и анкетирование

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

1) Обычные клиенты банка, пользующихся услугами банкоматов.

2) Представители других банков, имеющих взаимные соглашения с данным банком о со­вместном использовании банкоматов.

3) Руководители филиалов банка, получающих информацию из системы управления бан­коматами.

4) Сотрудники филиалов банка, вовлеченные в повседневную работу системы банкома­тов, обрабатывающие рекламации клиентов и т.д.

5) Администраторы баз данных, ответственные за связь банкоматов с базой данных клиентов.

6) Руководители службы безопасности банка, обеспечивающей защиту системы банкоматов.

7) Отдел маркетинга банка, использующий систему банкоматов как средство маркетинга.

8) Разработчики аппаратных и программных средств, ответственные за сопровождение и модернизацию аппаратных и программных средств.

Сценарии

Сценарии описывают последовательность работы пользователя с системой.

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

1. Описание состояния системы в начале сценария.

2. Описание нормального протекания событий.

3. Описание исключительных ситуаций и способов их обработки.

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

5. Описание состояния системы после завершения сценария.

Пример сценария событий

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

Рис. 3 Сценарий обработки банкоматом PIN- кода.

Прототипирование

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

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