Анализ требований к программному обеспечению

Размещено на http://www.allbest.ru/

МИНИСТЕРСТВО ОБРАЗОВАНИЯ НАУКИ, МОЛОДЕЖИ И СПОРТА УКРАИНЫ

ДОНЕЦКИЙ НАЦИОНАЛЬНЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

Кафедра программного обеспечения интеллектуальных систем

КОНТРОЛЬНАЯ РАБОТА

По дисциплине «Анализ требований к программному обеспечению»

Студентки заочного факультета

Шилиной Екатерины Юрьевне

группы ПЗз-11

Руководитель:

ст. преподаватель Золотухина О.А.

Донецк 2013г.

Задание 1. Определение концепта продукта. Выявление проблем

автоматизированный секретарь документация

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

Сформулировать цели и назначение проекта.

Определить имеющиеся проблемы и описать возможные пути их решения.

Определение концепции продукта.

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

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

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

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

Анализ предметной области

Создавая автоматизированную систему секретаря ООО “ЯМЗ”, необходимо тщательно изучить заданную предметную область, поскольку конечный результат работы напрямую зависит от качества ее исследования. Основными функциями секретаря являются:

1. Прием всей входящей корреспонденции.

В соответствии с полученной корреспонденцией секретарь осуществляет анализ и дальнейшую сортировку и рассылку документации. Сортировка и рассылка информации осуществляется по следующим принципам: тематика; адресация; важность.

2. Ведение учета и планирование встреч и совещаний с участием руководителя.

3. Контроль исполнения приказов и поручений руководства.

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

Автоматизированное рабочее место секретаря ООО «ЯМЗ» должно обеспечивать выполнение следующих функций:

Сортировка входящей корреспонденции;

Создание баз данных в соответствие с тематикой;

Рассылка документации по отделам;

Архивное резервирование данных;

Оперативный поиск документов;

Регистрация переписок;

Выдача отчетных документов;

Ведение протоколов совещаний;

Контроль за выполнением приказов и распоряжений;

Ведение плана рабочего дня.

Тип проектируемой системы должен соответствовать встроенному приложению. Разрабатываемый концепт программы должен обеспечивать решение следующих задач:

Управление рабочим временем руководителя (Тайм-менеджмент);

Планирование и фиксация результатов совещаний;

Контроль исполнения решений и поручений;

Организация делопроизводства;

Контроль исполнительской дисциплины;

Ведение электронного каталога документов и работа с ним;

Работа с архивами документов прошлых периодов.

Определение проблем

Элемент	Описание
Проблема	Описание проблемы
воздействует на	Указание лиц, на которых оказывает влияние данная проблема
результатом чего является	Описание воздействия дано проблемы на заинтересованных лиц и бизнес-деятельности
Выигрыш от	Указание предлагаемого решения
может состоять в	Список основных предлагаемых решением преимуществ

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

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

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

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

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

Элемент	Описание
Проблема	Управление рабочим временем руководителя
воздействует на	Эффективность работы секретаря
результатом чего является	Отсутствие оперативности и эффективности в организации рабочего графика
Выигрыш от	Автоматизированного контроля за изменениями в рабочем графике
может состоять в	- оперативном решении поставленных задач - устранении задержек при организации рабочего времени

Элемент	Описание
Проблема	Контроль исполнения решений и поручений
воздействует на	Выполнение секретарем функциональных обязанностей
результатом чего является	Отсутствие оперативности и эффективности при контроле исполнений решений и поручений руководства
Выигрыш от	Автоматизированного контроля за исполнением поручений и решений руководителей
может состоять в	- оперативном решении поставленных задач - устранении задержек в контроле исполнительной дисциплины

Задание 2. Выявление требований

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

В соответствии с выбранной методикой разработать документацию, необходимую для выявления требований.

Провести анализ проблем, сформулированных в лабораторной работе №1 с использованием подхода «причина-следствие». Определить причины проблем.

Описать причины с использованием техники диаграмм.

На основе полученных данных описать профили пользователей, пользовательские среды, критерии успеха.

Содержание отчета.

Название выбранной методики выявления требований. Обоснование выбора методики.

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

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

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

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

Методика «мозгового штурма» была реализована по следующим принципам.

На первом этапе была сформулирована задача разработки АРМ секретаря.

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

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

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

Темой проведения мозгового штурма являлась «Разработка программного продукта в рамках создания АРМ секретаря»

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

По итогам проведения «мозгового штурма» были определены основные требования к программному продукту.

График проведения мозгового штурма

Дата	Тема, цели мероприятия	Результаты
28.11	Разработка программного продукта в рамках создания АРМ секретаря» Генерирование максимального количества идей	Протоколирование идей без предварительной критики и обсуждения.
29.11	Анализ и рассмотрение предложенных идей. Выбор наиболее подходящих способов решения проблем.	Группировка, оценка и отбор идей.

При проведении мозгового штурма были сформулированы следующие задачи:

Генерирование идей согласно обнаруженным проблемам.

Решение о выборе наиболее приемлемых идей, которые бы максимально решали поставленные задачи.

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

разминка, которая заключалась в разъяснении целей и задач;

этап генерирования идей;

обсуждение полученных идей;

подведение итогов.

Перечень проблем и вызывающих их причин

	Проблемы	Причины
1.	Отсутствие оперативности при сортировке входящей документации	Большой объем входящей корреспонденции; Необходимость в сортировке согласно адресанту, тематике, важности. Необходимость в занесении документов в базу данных
2.	Отсутствие оперативности при поиске документов	Отсутствие автоматизированного поиска по заданным критериям Отсутствие баз данных по отдельным критериям
3.	Необходимость в создании баз данных переписки	Большие затраты времени на создание необходимого реестра документов Хранение и доступ к требуемой информации
4.	Отсутствие оперативности в управлении рабочим временем	Необходимость в ведении учета времени в кратчайшие сроки Отсутствие автоматического контроля за изменениями в рабочем графике
5.	Низкий контроль за исполнением решений и поручений руководства	Отсутствие автоматизированного контроля за исполнением приказов Высокая трудоемкость процесса контроля за исполнением приказов и поручений

Диаграмма Ишекавы

Таблица 1 Степень воздействия негативных факторов

	Факты	Воздействие	Суммарное воздействие
Контроль за исполнением приказов	125	31%	31%
поиск документов	110	28%	59%
сортировка документов	72	18%	77%
учет времени	65	16%	94%
прочие	25	6%	100%
	397	100%

Диаграмма Парето

Описание профилей пользователей, пользовательских сред, критерии успеха

Проект продукта предполагает, что имеется два вида пользователей.

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

Характеристика	Значение/диапазон значений	На что будет влиять в интерфейсе
Психофизические характеристики
Возраст	Средний, пред пенсионный	Необходима возможность масштабирования шрифтов
Пол	Женский/мужской	Нейтральный интерфейс
Социально-демографические характеристики
Язык	Русский	Нет необходимости в переключении языков
Образование	Высшее, среднее специальное	Использование понятной лексики
Опыт работы с компьютером
Уровень пользователей	начинающий	Необходимо предоставить простой в использовании интерфейс

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

Характеристика	Значение/диапазон значений	На что будет влиять в интерфейсе
Психофизические характеристики
Возраст	25-35 лет, средний,	Необходимость масштабирования шрифтов отсутствует
Пол	Женский/мужской	Нейтральный интерфейс
Социально-демографические характеристики
Язык	Русский	Нет необходимости в переключении языков
Образование	Высшее	Работа с подпрограммами
Опыт работы с компьютером
Уровень пользователей	Высокий

Описание рабочей среды

Характеристики	Значение/диапазон значений	На что будет влиять в интерфейсе
Физическая сторона рабочей среды	-освещение -шум -рабочее пространство -температура -наличие компьютеров, телефонов -количество персонала	Рабочая среда референта подразумевает низкую концентрацию и постоянное реагирование на внешние раздражители (телефонные звонки, посетители, сотрудники)
Место работы пользователя и степень его мобильности	- приемная - стационарно	На режим работы программного продукта
Вопросы эргономики и условий труда	-работа ведется сидя - режим работы с 8.00 до 17.00	Время работы с программным продуктов ограничено режимом работы пользователя

Критерии успеха

4. Требования к системе

4.1. Требования к системе в целом

4.1.1. Требования к структуре и функционированию системы

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

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

В Системе предлагается выделить следующие функциональные подсистемы:

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

- подсистема хранения данных, которая предназначена для хранения данных в структурах, нацеленных на принятие решений;

- подсистема формирования и визуализации отчетности, которая предназначена для формирования бизнес-ориентированных витрин данных и отчетности.

Указываются требования к способам и средствам информационного обмена между компонентами системы.

В качестве протокола взаимодействия между компонентами Системы на транспортно-сетевом уровне необходимо использовать протокол TCP/IP.

Для организации информационного обмена между компонентами Системы должны использоваться специальные протоколы прикладного уровня, такие как: NFS, HTTP и его расширение HTTPS, NetBios/SMB, Oracle TNS.

Для организации доступа пользователей к отчетности должен использоваться протокол презентационного уровня HTTP и его расширение HTTPS.

Приводятся требования к характеристикам взаимосвязей со смежными системами.

Смежными системами для КХД являются:

- информационные системы оперативной обработки данных Заказчика;

- информационные системы планирования;

- ...

Источниками данных для Системы должны быть:

- Информационная система управления предприятием (СУБД MS SQL).

- Информационно-справочная система (СУБД MS SQL).

- Информационная система обеспечения бюджетного процесса (СУБД Oracle).

- ...

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

- Информационная система управления предприятием - с использованием промежуточной базы данных (ПБД).

- Информационно-справочная система - обмен файлами ОС определенного формата.

- Информационная система обеспечения бюджетного процесса - интеграция «точка - точка».

- ...

Определяются требования к режимам функционирования системы.

Например:

Система должна поддерживать следующие режимы функционирования:

- Основной режим, в котором подсистемы КХД выполняют все свои основные функции.

- Профилактический режим, в котором одна или все подсистемы КХД не выполняют своих функций.

В основном режиме функционирования Система КХД должна обеспечивать:

- работу пользователей режиме - 24 часов в день, 7 дней в неделю (24х7);

- выполнение своих функций - сбор, обработка и загрузка данных; хранение данных, предоставление отчетности.

В профилактическом режиме Система КХД должна обеспечивать возможность проведения следующих работ:

- техническое обслуживание;

- модернизацию аппаратно-программного комплекса;

- устранение аварийных ситуаций.

Общее время проведения профилактических работ не должно превышать X% от общего времени работы системы в основном режиме (Y часов в месяц).

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

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

Диагностирование Системы должно осуществляться следующими штатными средствами, входящими в комплект поставки программного обеспечения:

- СУБД - <указывается ПО администратора позволяющее проводить мониторинг>;

- ETL-средство - ..

- средство визуализации - ...

Обязательно ведение журналов инцидентов в электронной форме, а также графиков и журналов проведения ППР.

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

Для каждой проблемы привести список вызывающих ее причин. Проранжировать проблемы и причины проблем по степени важности.

Составить общую диаграмму Парето и диаграмму Ишекавы. Выявить главные проблемы и составить для них диаграммы Парето и диаграммы Ишекавы.

Привести описание профилей пользователей, пользовательских сред, критерии успеха Критерии успеха сформулировать как количественные показатели.

Задание 3. Спецификация требований

На основе анализа первичной информации составить глоссарий системы.

Изучить шаблоны спецификации требований. Провести анализ характеристик проекта. Выбрать соответствующий характеристикам проекта шаблон спецификаций. Выбор обосновать.

Составить список всех выявленных требований. Проранжировать требования (методику ранжирования выбрать самостоятельно, рекомендуемая методика MoSCoW). Описать характеристики требований.

Разработать спецификации требований, относящихся к категории Must.

Описать нефункциональные требования системы.

Описать показатели качества.

Содержание отчета.

Глоссарий.

Характеристики проекта (размеры, важность, критичность).

Обоснование выбора шаблона спецификации требований.

Проранжированный список требований с указанием их атрибутов.

Характеристики проекта (размеры, важность, критичность).

Спецификация требований данного проекта будет соответствовать стандартам IEEE.

Соответственно, в описании будут приведены следующие пункты:

1. Введение

Введение содержит следующие подразделы:

Цели;

Область применения;

Определения, аббревиатуры и сокращения;

Список литературы;

Обзор.

1.1 Цели

В этом разделе нужно:

Описать сами цели;

Указать целевую аудиторию.

1.2 Область применения

В этом подразделе нужно:

Определить название программного продукта;

Объяснить, что программный продукт будет делать;

Опиcать использование программного обеспечения, разъясняя его преимущества;

1.3 Определения, аббревиатуры и сокращения

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

1.4 Список литературы

В этом подразделе нужно:

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

Идентифицировать каждый документ по названию, номеру документа (если применимо), дате и издателю;

Указать источники, из которых могут быть получены справки.

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

1.5 Обзор

В этом подразделе нужно:

Описать, что содержит остальная часть спецификации требований;

Объяснить, каким образом организована спецификация требований.

2 Общее описание

Этот раздел должен описывать общие факторы, которые влияют на продукт и его требования, и состоит из 6 подразделов: В этом разделе обычно состоит из шести подразделов, а именно:

Перспективы продукта;

Функции продукта;

Пользовательские характеристики;

Ограничения;

Предположения и зависимости;

Распределение требований.

2.1 Перспективы продукта

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

Системные интерфейсы;

Пользовательские интерфейсы;

Аппаратные интерфейсы;

Программные интерфейсы;

Интерфейсы связи;

Память.

2.1.1 Системные интерфейсы

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

2.1.2 Пользовательский интерфейс

логика взаимодействия пользователя и программы;

требования к юзабилити программы (например, "Сообщения об ошибках должны быть короткими")

2.1.3 Аппаратные интерфейсы

То, что должно уметь делать устройство (например, "необходима поддержка полноэкранного режима").

2.1.4 Интерфейсы программного обеспечения

Использование других необходимых программных продуктов (например, системы управления данными, операционные системы или математические пакеты), а также взаимодействие с другими прикладными системами.

2.1.5 Интерфейсы связи

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

2.1.6 Память

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

2.2 Функции продукта

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

2.3 Пользовательские характеристики

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

2.4 Ограничения

Аппаратные ограничения (например, требования сигналов времени);

Интерфейсы взаимодействия с другими приложениями;

Параллельная работа;

Требования к языкам программирования;

Требования к надежности;

Безопасность.

2.6 Распределение требований

Требования, которые могут быть отложены до будущих версий системы.

3 Спецификация требований

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

Спецификация требований должна быть сформулирована в соответствии со всеми характеристиками, описанными в п. 4.3.

В спецификации требований должны быть перекрестные ссылки на более ранние документы, которые имеют к ней отношение.

Все требования должны быть однозначно идентифицированы (нумерация подойдет).

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

3.2 Функции

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

Действие проверки на входе

Точная последовательность операций

Ответы на нештатные ситуации, в том числе:

Переполнение

Обработка ошибок и восстановление

Влияние параметров

Отношение выходов к входам, в том числе

входные/выходные последовательности

Формулы для преобразования входящей информации в выходную

Может быть целесообразно разделить функциональных требований на подфункции или подпроцессы. Это не означает, что разработка ПО тоже будет разделена таким образом.

3.3 Требования к рабочим характеристикам

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

Количество терминалов в поддержке;

Количество одновременных пользователей в поддержке;

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

Динамические численные требования могут включать, например, число задач и объем данных, подлежащих обработке в течение определенного времени в условиях нормальной и пиковой нагрузки. Все эти требования должны быть указаны в измеримых величинах. Хороший пример: 95% запросов, должны быть обработаны менее чем за 1 сек. Плохой пример: оператору не придется ждать завершения транзакции.

3.4 Логические требования к базе данных

Виды информации, используемые различными функциями;

Частота использования;

Доступ к возможностям;

Лица и их взаимоотношения;

Ограничения целостности;

Требования к хранению данных.

Обоснование выбора шаблона спецификации требований

В качестве шаблона спецификации требований был выбран подход CRC (Class-Responsibility-Collaborators -- класс-ответственность-“сотрудники”).

Данный поход подразумевает проведение «мозгового штурма» с использованием специально подготовленных карточек, которые состоят из трех отделений: имя класса записывается в верхнем отделении, “обязанности” класса перечислены в левом отделении, а “сотрудники” перечислены в правом отделении.

Обязанности -- это операции, которые класс готов выполнить в интересах других классов.

Для выполнения многих обязанностей необходимо участие (обслуживание) со стороны других классов. Такие классы перечисляются как “сотрудники”.

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

Подход CRC был предпочтен другим шаблонам, поскольку при его использовании выделение классов является результатом анализа сообщений, передаваемых между объектами для выполнения задач обработки информации. Акцент делается на унифицированном методе распределения “интеллекта” в системе, и некоторые классы когут быть скорее получены, исходя из подобной технической потребности, чем выявленыв качестве “бизнес объектов” как таковых. В этом смысле метод CRC может быть более приемлемым для проверки правильности выбора классов уже выявленных с помощью других методов. Подход CRC также полезен при установлении свойств клас сов (которые логически следуют из “обязанностей” и типов “сотрудников” класса).

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

Классы

Руководитель
Обязанности класса «руководитель»	Сотрудники (другие классы)
просмотр Расписания (на день, неделю, месяц); Планировать совещания; Контроль исполнения решений и поручений; Просмотр Протокола совещания, и его историю; Просмотр переписки. Формирование Поручений и Указаний.

АРМ "Руководитель"

Удобный просмотр Расписания (на день, неделю, месяц);

Планировать совещания;

Контроль исполнения решений и поручений;

Просмотр Протокола любого совещания, и его историю (карточку в которой отражены участники, вопросы, докладчики);

Просмотр переписки.

Формирование Поручений и Указаний.

АРМ «Секретарь-референт» (с правами администратора БД)

Отслеживать ход исполнений поручений;

Формировать и поддерживать в актуальном состоянии Расписание руководителя;

Назначать совещания. Формировать повестку совещания, назначать участников и докладчиков. При этом, программа автоматически высылает приглашение участникам и напоминания.

Вести протокол совещания и отслеживать результат исполнения решений.

Назначать поручения исполнителям и отслеживать ход их исполнения;

Вести учет собственных задач.

АРМ "Исполнитель"

Получение уведомлений о поступлении на его имя корреспонденции или поручения, участия в совещании;

Просмотр своей корреспонденции и поручений;

Заполнение карточки Поручение (заполнение полей результат исполнения, дата исполнения…)

Формирование отчетов по своим документам;

Использование справочника «Сотрудники» как телефонного справочника и справочника Ф.И.О, должности и электронных адресов сотрудников предприятия;

Использование типовых бланков из раздела «Шаблоны и СТП» ;

Доступ к актуальным документам (Инструкциям и Положениям

Составить список всех выявленных требований. Проранжировать требования (методику ранжирования выбрать самостоятельно, рекомендуемая методика MoSCoW). Описать характеристики требований.

Разработать спецификации требований, относящихся к категории Must.

Описать нефункциональные требования системы.

Описать показатели качества.

Техника MoSCoW(Must, Should, Could, Would)

Атрибуты требований

Спецификации выбранных требований.

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

Показатели качества при реализации требований.

Задание 4. Документирование требований

Ставить техническое задание на разработку проекта используя положения ГОСТ 34.602-89.

Глоссарий

Термин	Описание
Программа	Данные, предназначенные для управления конкретными компонентами системы обработки информации в целях реализации определенного алгоритма
Программное обеспечение	Совокупность программ системы обработки информации и программных документов, необходимых для эксплуатации этих программ
Сеанс работы	Интервал времени, в течение которого пользователю выделены ресурсы системы обработки информации для выполнения его работ и связи с ним в интерактивном режиме
Сообщение системы	Сообщение любой из системных программ, входящих в операционную систему
Команда оператора	Обращение оператора системы обработки информации к управляющей программе, переданное посредством консоли, для оказания воздействия на ход обработки данных
Процесс системного ввода	Системный процесс, предназначенный для автоматического ввода в систему обработки информации пакета заданий через назначенное этому процессу устройство ввода-вывода Примечание. Процесс системного ввода в некоторых системах обработки информации интерпретирует предложения языка управления заданиями
Поле (поле БД, поле формы)	Структурный элемент, содержащий однотипную информацию, например, текст, дату, числовые значения и т.п.
Флаг	Особое поле данных, могущее содержать только одно из двух допустимых значений. Позволяет указать на наличие или отсутствие какого-либо события или свойства объекта
Справочник	Вспомогательная структура данных, содержащая список допустимых значений для какого-либо поля основных форм или БД. Справочники подразделяются на фиксированные (неизменяемые и поставляемые Исполнителем вместе с готовым сайтом) и редактируемые (состав которых может изменяться администратором)
Администратор (менеджер, редактор) сайта	Лицо, осуществляющее работу с программным продуктом
Дизайн-шаблон страниц	Файл, содержащий элементы внешнего оформления HTML страниц сайта, а также набор специальных тегов, используемых системой публикации сайта для вывода информации при создании окончательных HTML страниц
Процесс вывода	Системный процесс, предназначенный для автоматического вывода определенной части результатов выполнения заданий наряду с сообщениями управляющей программы через назначенное этому процессу устройство ввода-вывода
Информационные материалы	Информация о деятельности. Может включать графические, текстовые, аудио или видео материалы. Предоставляется Заказчиком
Процесс обработки данных	Система действий, реализующая определенную функцию в системе обработки информации и оформленная так, что управляющая программа данной системы может перераспределять ресурсы этой системы в целях обеспечения мультипрограммирования. Примечания: 1. Процесс характеризуется состояниями, которые определяются наличием тех или иных ресурсов в распоряжении процесса и, следовательно, возможностью фактически выполнять действия, относящиеся к процессу. 2. Перераспределение ресурсов, выполняемое управляющей программой, влияет на продолжительность процесса обработки данных, но не на его конечный результат. 3. Процесс оформляют с помощью специальных структур управляющих данных, которыми манипулирует управляющий механизм. 4. В конкретных системах обработки информации встречаются разновидности процессов, которые различаются способом оформления и составом ресурсов, назначаемых процессу и отнимаемых от него, и допускается вводить специальные названия для таких разновидностей, например, задача в операционной системе ОС ЕС ЭВМ
Дамп	Совокупность объектов базы данных, представленная в виде файлов, позволяющая восстановить точную копию структуры исходной базы данных в аналогичной системе управления базами данных
Шаблона раздела	Особым образом размеченный ASCII-файл, определяющий как графическое оформление страниц раздела, так и их макет (раскладку) - взаимное расположение блоков с наполнением раздела
Сообщение системы	Сообщение любой из системных программ, входящих в операционную систему
Роль	Класс пользователей системы, обладающих определенным набором прав доступа
Сеанс работы	Интервал времени, в течение которого пользователю выделены ресурсы системы обработки информации для выполнения его работ и связи с ним в интерактивном режиме
Команда оператора	Обращение оператора системы обработки информации к управляющей программе, переданное посредством консоли, для оказания воздействия на ход обработки данных

Размещено на Allbest.ru

...