2.5.Вопросы для самоконтроля

1. Каковы основные цели анализа предметной области?

2. Как используется методика «будет – не будет» при определении области действия проекта?

3. Кто выполняет анализ предметной области?

4. Для каких программных систем должен проводиться анализ осуществимости?

5. Что определяют бизнес-требования и бизнес-правила?

6. Почему пользовательские и функциональные требования должны соответствовать бизнес-требованиям?

7. Что определяет образ продукта и границы проекта?

8. Перечислите основные разделы документа, описывающего образ продукта и границы проекта?

3.Выявление требований

3.1.Определение способа сбора и анализа требований

3.1.1.Источники возникновения требований

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

• требования, определяемые предметной областью;

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

Под требованиями, определяемыми предметной областью здесь понимаются ограничения, накладываемые на программную систему законами природы и, которые поэтому нельзя изменить. Источниками остальных требований являются люди. Чем меньше объективных ограничений имеет проблема, тем большее количество ее ограничений должно быть получено от людей. Для большинства распространенных («офисных») приложений этот источник поставляет более 80% требований.

3.1.2.Заинтересованные в проекте лица

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

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

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

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

Заинтересованные лица – активно участвующие в проекте лица, группы или организации, которых затрагивает полученный результат и которые сами могут влиять на этот результат [4].

Пользователь – юридическое или физическое лицо, применяющее программное средство или участвующее в деятельности, прямо или косвенно зависящей от функционирования данного программного средства [10].

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

Рассмотрим наиболее часто используемые методы выявления требований.