Автор работы: Пользователь скрыл имя, 20 Февраля 2012 в 19:10, контрольная работа
После согласования «Документа Бизнес-Требований», необходимо представить бизнес-требования в виде, понятном для команды разработчиков. С этой целью создается «Спецификация Требований к ПО» или ее упрощенный аналог – «Функциональная Спецификация». Основная задача этих спецификаций – представить требования к системе с точки зрения функционала, который система должна реализовать.
Лабораторная работа №1 (4 час).
Тестирование программного обеспечения.
Описание тестируемой системы и ее окружения.
После согласования «Документа Бизнес-Требований», необходимо представить бизнес-требования в виде, понятном для команды разработчиков. С этой целью создается «Спецификация Требований к ПО» или ее упрощенный аналог – «Функциональная Спецификация». Основная задача этих спецификаций – представить требования к системе с точки зрения функционала, который система должна реализовать. «Техническая Спецификация» создается на основании «Функциональной Спецификации» и ее основная задача – определить и задокументировать архитектуру разрабатываемой системы. «Техническая Спецификация» спецификация служит основанием для начала непосредственной разработки системы.
«Документ Бизнес-Требований» представляет требования к системе с точки зрения бизнеса. На основании «Документа Бизнес-Требований» аналитик должен сформировать «Спецификацию Требований к ПО» или ее упрощенный вариант «Функциональную Спецификацию».
«Спецификация Требований к ПО» описывает поведение системы и ее функционал используя функциональные требования. Помимо этого Спецификация содержит нефункциональные требования, или требования к качеству сервиса.
Функциональные требования определяют, какие функции система должна реализовывать и предоставлять пользователям или внешним системам. Функциональные требования также называются сценариями использования (use cases). Они могут определять требования как к внешнему функционалу (видимому пользователям и внешним системам), так и к внутреннему функционалу (внутренние сервисы системы, например, аудит изменений, журнал событий и т.п.).
Нефункциональные требования, или требования к качеству сервисов, определяют ограничения, накладываемые на функциональные требования к системе, или условия, в которых система должна будет функционировать. Примеры нефункциональных требований: пропускная способность сети, производительность системы, доступность, условия лицензирования и т.п.
Структура Спецификации может быть следующей:
1. Название документа и его версия;
2. Название проекта и код;
3. История Изменения Документа: дата, автор, краткое описание изменения, измененные разделы;
4. Список Согласования: ФИО, роль в проекте, подпись, дата (в случае использования системы электронного документооборота и системы электронной подписи последние два атрибута могут быть опущены);
5. Оглавление;
6. Перечень Рисунков;
7. Перечень Таблиц;
8. Введение: краткое описание целей создания документа и его содержания. Необходимо дать ссылку на «Документ Бизнес-Требований» и его версию, который использовался при создании Спецификации;
9. Функциональные Требования:
1) Код и название требования;
2) Описание;
3) Входные/Выходные Данные;
4) Интерфейс Пользователя: описание требований к интерфейсу пользователя с макетами экранов;
5) Системный Интерфейс: описание требований к интерфейсу системы, который будет использоваться внешними системами;
6) Зависимости: ссылки на функциональные требования, которые зависят от данного требования. Можно создать «Матрицу Трассировки Функциональных Требований», подобную описанной в статье «Управление Требованиями». В этом случае данную секцию можно опустить;
10. Нефункциональные Требования:
1) Код и название требования;
2) Описание;
11. Предположения и Ограничения: результаты уточнения деталей реализации требований, которые по явным причинам не были покрыты в «Документе Бизнес-Требований», должны быть указаны в этом разделе;
12. Открытые Вопросы: все открытые вопросы, возникающие в процессе формирования документа, должны быть перечислены в этом разделе с указанием разделов, где они покрыты;
13. Ссылки на дополнительные материалы (функциональные модели, модели данных и т.п.).
«Функциональная Спецификация» отличается от «Спецификации Требований к ПО» тем, что она не содержит нефункциональных требований. В силу этого, структура «Функциональной Спецификации» может быть следующей:
1. Название документа и его версия;
2. Название проекта и код;
3. История Изменения Документа: дата, автор, краткое описание изменения, измененные разделы;
4. Список Согласования: ФИО, роль в проекте, подпись, дата (в случае использования системы электронного документооборота и системы электронной подписи последние два атрибута могут быть опущены);
5. Оглавление;
6. Перечень Рисунков;
7. Перечень Таблиц;
8. Введение: краткое описание целей создания документа и его содержания. Необходимо дать ссылку на «Документ Бизнес-Требований» и его версию, который использовался при создании Спецификации;
9. Функциональные Требования:
1) Код и название требования;
2) Описание;
3) Входные/Выходные Данные;
4) Интерфейс Пользователя: описание требований к интерфейсу пользователя с макетами экранов;
5) Системный Интерфейс: описание требований к интерфейсу системы, который будет использоваться внешними системами;
6) Зависимости: ссылки на функциональные требования, которые зависят от данного требования. Можно создать «Матрицу Трассировки Функциональных Требований»;
10. Предположения и Ограничения: результаты уточнения деталей реализации требований, которые по явным причинам не были покрыты в «Документе Бизнес-Требований», должны быть указаны в этом разделе;
11. Открытые Вопросы: все открытые вопросы, возникающие в процессе формирования документа, должны быть перечислены в этом разделе с указанием разделов, где они покрыты;
12. Ссылки на дополнительные материалы (функциональные модели, модели данных и т.п.).
«Техническая Спецификация» содержит описание архитектуры разрабатываемой системы. Это технический документ, который создается на основании «Функциональной Спецификации» архитектором системы. «Техническая Спецификация» служит основанием для начала разработки системы. Структура Спецификации может быть следующей:
1. Название документа и его версия;
2. Название проекта и код;
3. История Изменения Документа: дата, автор, краткое описание изменения, измененные разделы;
4. Список Согласования: ФИО, роль в проекте, подпись, дата (в случае использования системы электронного документооборота и системы электронной подписи последние два атрибута могут быть опущены);
5. Оглавление;
6. Перечень Рисунков;
7. Перечень Таблиц;
8. Введение: краткое описание целей создания документа и его содержания. Необходимо дать ссылку на «Функциональную Спецификацию» и ее версию, которая использовался при создании «Технической Спецификации»;
9. Архитектура Системы: техническое описание архитектуры системы;
10. Системные Интерфейсы:
1) Используемые Интерфейсы: описание интерфейсов с внешними системами, используемых разрабатываемой системой;
2) Предоставляемые Интерфейсы: описание интерфейсов, предоставляемых внешним системам;
11. Схема Базы Данных;
12. Предположения и Ограничения: результаты уточнения деталей реализации требований, которые по явным причинам не были покрыты в «Функциональной Спецификации», должны быть указаны в этом разделе;
13. Открытые Вопросы: все открытые вопросы, возникающие в процессе формирования документа, должны быть перечислены в этом разделе с указанием разделов, где они покрыты;
14. Ссылки на дополнительные материалы (внешние файлы моделей, описание интерфейсов и т.п.).
Отчет должен содержать:
1. Постановку задачи, согласно индивидуальному варианту.
2. Технические требования (FS), оформленные по образцу приведенному в лабораторной работе.
ОБРАЗЕЦ
Документ-концепция разработки версии 2.1 системы MyProject
Версия 2.13
История изменений
Дата | Версия | Описание | Автор |
28 мая 2008 г. | 1.0 | Документ создан в первой редакции | Иванов |
29 мая 2008 г. | 1.0 | Детализировано большинство требований на основе дополнительной информации | Иванов |
9 июня 2008 г. | 1.1 | Добавлены общие требования по переносу телефонов в текст объявления | Иванов |
11 июня 2008 г. | 1.2 | Добавлено требование по учету существующих платежей системы при разноске оплаты (Кавер И.) | Иванов |
17 июня 2008 г. | 1.3 | Модифицированы и детализированы требования после обсуждения с заинтересованным лицом | Иванов |
18 июня 2008 г. | 1.4 | Внесены поправки к требованиям верстки и создания счета | Иванов |
26 июня 2008 г. | 1.5 | Добавлены требования по маркировке объявлений от рекламодателя, справке | Иванов |
10 июля 2008 г. | 1.6 | Изменены требования по задаче авторубрик | Иванов
|
23 июля 2008 г. | 1.7 | Добавлены требования по разработке функций, аналогичных функциям CompareMeaningful и Upper2,внедрению новой версии Stimulsoft Reports .NET, исправлению существующих ошибок, поддержке версий для шаблонов, внесению изменений в механизм аутентификации пользователей, дизайнеру формы ввода объявлений | Гальперин А. |
8 августа 2008 г. | 1.8 | Внесена поправка в задачу замены функций CompareMeaningful и Upper2 по реализации средствами СУБД | Иванов |
18 августа 2008 г. | 1.9 | Добавлено требование по конфигурированию прокси сервера и строки соединения с сервером | Иванов |
22 августа 2008 г. | 1.10 | Изменены требования по импорту объявлений. Предполагается, что в счете всегда есть карта стоимости разных видов объявлений | Иванов |
8 сентября 2008 г. | 2.0 | Изменены версия и название проекта. Проект – подсистема версии 2.1.
Добавлены и описаны итерации 2.1: - Интеграция АРМ: выгрузка данных - Автоматическое обновление клиента - Автоматическое обновление сайта - Поддержка фона объявлений - Импорт модульных объявлений - Поддержка импорта/экспорта MySQL - Оптимизация nconvert - Оптимизация упреждающего чтения | Иванов |
25 сентября 2008 г. | 2.1 | Добавлены задачи 5.41 и 5.42, добавлено требование проверки даты при проверки совпадений номеров заявок при импорте | Иванов |
29 сентября 2008 г. | 2.2 | Внесены дополнения к требованиям по поддержке операций ручной разноски на основе сведений заказчика | Иванов |
1 октября 2008 г. | 2.3 | Добавлены требования по выбору главного регионального департамента при удаленной работе серверов | Иванов |
1 октября 2008 г. | 2.4 | Модифицированы требования по хранению настроек соединения программы в задаче 5.32 | Иванов |
6 октября 2008 г. | 2.5 | Детализированы требования по импорту базы данных MySQL Ярославль | Иванов |
13 октября 2008 г. | 2.6 | Внесены изменения и дополнения в требования привязки счета к объявлениям (5.7), в требования к верстке и настройке шаблонов системе верстки (5.41) | Иванов |
16 октября 2008 г. | 2.7 | Дополнены требования по импорту объявлений 5.36 и 5.38 | Иванов |
17октября 2008 г. | 2.8 | Дополнены требования по поддержке типа объявления в конкретном выпуске объявлений 5.36 и 5.38 | Иванов |
20 октября 2008 г. | 2.9 | Добавлена задача 5.49 по оптимизации поиска объявлений по телефону | Иванов |
21 октября 2008 г. | 2.10 | Модифицированы требования к задаче авторубрик (5.10) | Иванов |
29 октября 2008 г. | 2.11 | Модифицированы требования к задаче автоматической генерации номеров счетов и заявок (5.44) | Иванов |
6 ноября 2008 г. | 2.12 | По причине конфликта требований к поддержке введенных вручную платежных документов при разноске и повторной разноски фиктивных документов, задача замены фиктивных платежных документов удалена из 5.45. | Иванов |
7 ноября 2008 г. | 2.13 | Учтены замечания по задаче 5.45 «Связывание счета на оплату с платежным документом и поддержка карты стоимости». Изменены требования по задаче. | Иванов |
Содержание
1 Вступление
1.1 Назначение
1.2 Обзор проекта
2 Пользовательская среда
3 Основные потребности пользователя
4 Обзор проекта
4.1 Обзор возможностей системы и их атрибутов
4.1.1 Атрибуты функций системы
4.1.2 Функции системы
5 Задачи проекта
5.1 Настройки
5.2 Формы поиска
5.2.1 Общие модификации
5.2.2 Новые формы
5.4 Ввод единым текстом
5.8 Импорт объявлений из файла импорта
5.22 Исправление существующих ошибок
5.25 Дизайнер формы ввода объявлений.
5.49 Оптимизация поиска объявлений по телефону
6 Другие требования
6.1 Требования по производительности
6.2 Требования к инсталляции и развертыванию
Данный документ освещает набор требований верхнего уровня для расширения системы MyProject и ее оптимизации с точки зрения ввода объявлений. Оптимизация включает в себя разработку новых режимов ввода объявлений, более детальную настройку работы операторов, кэширование данных. К расширениям относятся модификации по разработке зависимых справочников, новых подвидов объявлений, специальных рубрик изданий, отчетов и функций импорта объявлений. Данная итерация проекта также включает в себя работы по разработке возможности верстки в новых системах и поддержке новых версий 1С.
Данный документ предназначен для определения основных требований к проекту на уровне пользователя и заказчика. Документ-концепция не освещает технических деталей реализации и кодирования функций системы.
Данный документ включает описание новых функций, которые необходимо добавить к существующей информационной системе MyProject, в ходе проекта.
В рамках проекта необходимо осуществить следующий набор изменений в системе MyProject:
- Новые настройки для ускоренного ввода
- Формы быстрого ввода объявлений
- Ввод единым текстом
- Зависимые справочники для шаблонов ввода объявлений
- Вечные бесплатные объявления
- Контроль/проверка строчных объявлений перед публикацией
- Привязка счета на оплату к объявлению
- Импорт объявлений из файла импорта программы SM Realty и сайта job-box.ru