5.1 Особенности этапа «Анализ требований»

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

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

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

Список требований к АС должен включать:

• совокупность условий, при которых предполагается эксплуа­тировать будущую систему (аппаратные и программные ре­сурсы, предоставляемые системе; внешние условия ее функционирования; состав людей и работ, имеющих к ней отно­шение);

• описание выполняемых системой функций;

• ограничения в процессе разработки (директивные сроки за­вершения отдельных этапов, имеющиеся ресурсы, организа­ционные процедуры и мероприятия, обеспечивающие защиту информации).

Целью анализа является преобразование общих, неясных знаний о требованиях к будущей системе в точные (по возможности) опре­деления. Результатом этапа должна являться модель требований к системе (по другому — системный проект), определяющая:

• архитектуру системы, ее функции, внешние условия, распределение функций между аппаратной и программной частями (ПЧ);

• интерфейсы и распределение функций между человеком и системой;

• требования к программным и информационным компонентам ПЧ, необходимые аппаратные ресурсы, требования к базе данных, физические характеристики компонент ПЧ, их интерфейсы.

Модель требований должна включать:

• полную функциональную модель требований к будущей сис­теме с глубиной проработки до уровня каждой операции каж­дого должностного лица;

• спецификации операций нижнего уровня;

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

• концептуальную информационную модель требований;

• пакет отчетов и документов по информационной модели;

• архитектуру системы с привязкой к концептуальной инфор­мационной модели;

• предложения по оргштатной структуре для поддержки сис­темы.

Таким образом, модель требований содержит функциональную, информационную и, возможно, событийную (в случае если целе­вая система является системой реального времени) модели, обеспечивающие ряд преимуществ по сравнению с традиционной мо­делью:

1. Для традиционной разработки характерно осуществление на­чальных этапов кустарными неформализованными способами. В ре­зультате заказчики и пользователи впервые могут увидеть систему после того, как она уже в большей степени реализована. Естествен­но, эта система будет отличаться от того, что они ожидали увидеть. Поэтому далее последует еще несколько итераций ее разработки или модификации, что требует дополнительных (и значительных) затрат денег и времени. Ключ к решению этой проблемы и дает модель требований, позволяющая:

• описать, «увидеть» и скорректировать будущую систему до того, как она будет реализована физически;

• уменьшить затраты на разработку и внедрение системы;

• оценить разработку по времени и результатам;

• достичь взаимопонимания между всеми участниками работы (заказчиками, пользователями, разработчиками, програм­мистами и т. д.);

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

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

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

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

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

С другой стороны, рассматриваемый этап ЖЦ является наиболее трудной частью разработки. Нижеследующие проблемы, с которы­ми сталкивается системный аналитик, взаимосвязаны (и это явля­ется одной из главных причин сложности их разрешения):

• аналитик не всегда располагает исчерпывающей информаци­ей для оценки требований к системе с точки зрения заказ­чика;

• заказчик, в свою очередь, не имеет достаточной информации о проблеме обработки данных для того, чтобы судить, что выполнимо, а что нет;

• аналитик сталкивается с чрезмерным количеством подробных сведений, как о предметной области, так и о новой системе;

• традиционная (текстовая) спецификация системы из-за объема технических терминов часто непонятна заказчику;

• если такая спецификация понятна заказчику, она будет недо­статочной для проектировщиков и программистов, создаю­щих или адаптирующих систему.

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