Требования к программному обеспечению и их анализ. Лекция 2.2

Содержание

Слайд 2

Темы лекции: Что такое требования? Анализ требований Почему требования важны Требования к требованиям Откуда они берутся

Темы лекции:

Что такое требования?

Анализ требований

Почему требования важны

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

Откуда они берутся

Слайд 3

Что такое требования?

Что такое требования?

Слайд 4

Требования к ПО: - Некое свойство программного обеспечения, необходимое пользователю, для

Требования к ПО:

- Некое свойство программного обеспечения, необходимое пользователю, для

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

Требования к ПО бывают: - Прямыми (Формализованными в технической документации, спецификациях,

Требования к ПО бывают:

- Прямыми
(Формализованными в технической документации, спецификациях, User

Story)
- Косвенными
(Проистекающими из прямых, либо являющиеся негласным стандартом для данной продукции или основывающиеся на опыте и здравом смысле использования продукта или продуктов подобных ему)
Слайд 6

Требования к ПО бывают: Прямые Косвенные

Требования к ПО бывают:

Прямые
Косвенные

Слайд 7

Откуда берутся требования: Бизнес аналитик Продакт менеджер Заказчик

Откуда берутся требования:

Бизнес аналитик
Продакт менеджер
Заказчик

Слайд 8

Пользовательские требования Use case User story User scenario

Пользовательские требования

Use case

User story

User scenario

Слайд 9

Пользовательские требования. User Scenario. Пример: Терминал удостоверяется, что пополнение возможно, и

Пользовательские требования. User Scenario. Пример:

Терминал удостоверяется, что пополнение возможно, и запрашивает

у Пользователя номер телефона и, если нужно, код оператора. Пользователь сообщает Терминалу запрошенные данные. Терминал удостоверяется, что данные введены корректно.
Слайд 10

Пользовательские требования. User Story. Пользовательские истории — Способ описания требований, к

Пользовательские требования.
User Story.

Пользовательские истории — Способ описания требований, к разрабатываемой

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

Пользовательские требования. User Story. Пример: Типы: Как я , Как , я ,

Пользовательские требования.
User Story. Пример:

Типы:
Как <Роль/Персона пользователя> я <Хочу что –

то получить>, <С такой – то целью>
Как <Пользователь>, я <Хочу управлять рекламными объявлениями>, <Чтобы удалять устаревшие или ошибочные объявления>
Слайд 12

Пользовательские требования. Use Case Use Case - Описание поведения системы, когда

Пользовательские требования.
Use Case

Use Case - Описание поведения системы, когда она

взаимодействует с кем – то (или чем - то) из внешней среды. Система может отвечать на внешние запросы или сама выступать инициатором взаимодействия
Слайд 13

Пользовательские требования. Use Case. Пример: Пользователь захотел разместить объявление Пользователь зашел

Пользовательские требования.
Use Case. Пример:

Пользователь захотел разместить объявление
Пользователь зашел в систему
Пользователь

авторизовался в системе
Пользователь создал объявление
Система отобразила сообщение об успешном создании объявления
Слайд 14

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

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

Слайд 15

Требования к требованиям Одно требование описывает одну и только одну вещь

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

Одно требование описывает одну и только одну вещь
Завершенность -

Требование полностью определено в одном месте и вся необходимая информация присутствует
Последовательность - Требование не противоречит другим требованиям и полностью соответствует внешней документации
Атомарность - Требование «атомарно». То есть оно не может быть разбито на ряд более детальных требований без потери завершенности.
Слайд 16

Требования к требованиям Отслеживаемость - Требование полностью или частично соответствует деловым

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

Отслеживаемость - Требование полностью или частично соответствует деловым нуждам

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

Требования к требованиям Недвусмысленность - Требование кратко определено без обращения к

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

Недвусмысленность - Требование кратко определено без обращения к техническому

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

Требования к требованиям Проверяемость - Реализованность требования может быть определена через

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

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

из четырёх возможных методов: осмотр, демонстрация, тест или анализ.
Слайд 19

Виды требований Функциональные требования Нефункциональные требования Требования к дизайну и юзабилити

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

Функциональные требования
Нефункциональные требования
Требования к дизайну и юзабилити
Требования к безопасности и

надежности
Требования к производительности
Требования к локализации
Графические (скрины, мокапы, диаграммы, схемы)
Слайд 20

Методы определения требований ● Анкетирование ● Мозговой штурм ● Наблюдение за

Методы определения требований

● Анкетирование
● Мозговой штурм
● Наблюдение за производственной деятельностью
● Анализ

нормативной документации
● Анализ моделей деятельности
● Анализ конкурентных продуктов
● Анализ статистики использования предыдущих версий системы
Слайд 21

Проверка требований ● Тестирование ● Анализ ● Демонстрация

Проверка требований

● Тестирование
● Анализ
● Демонстрация

Слайд 22

Слайд 23

Текстовая форма представления требований ● Требования бизнеса ● User Stories ● Спецификация системы

Текстовая форма
представления требований

● Требования бизнеса
● User Stories
● Спецификация системы

Слайд 24

Графическая форма представления требований ● DFD (data flow diagrams) ● UML

Графическая форма
представления требований
● DFD (data flow diagrams)
● UML (Unified Modeling

Language )
● SysML (Systems Modeling Language)
Слайд 25

UML. Пример:

UML.
Пример:

Слайд 26

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

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

для CrossFit
Слайд 27

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

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

обеспечения
Требования к приемке-сдаче проекта
Слайд 28

1. Требования к графическому дизайну сайта: При разработке сайта должны быть

1. Требования к графическому дизайну сайта:
При разработке сайта должны быть использованы

преимущественно светлые и контрастные цветовые решения(пример дизайнерского решения сайта: http://www.bleaustone.com).
Оформление должно быть разработано в достаточно консервативном ключе.
Основные разделы сайта должны быть доступны с первой страницы.
На первой странице не должно быть большого объема текстовой информации.
В дизайне сайта не должны присутствовать:
- мелькающие баннеры;
- много сливающегося текста;
- тёмные и агрессивные цветовые сочетания и графические решения.
Слайд 29

1.1 Порядок утверждения дизайн-концепции Если представленная Исполнителем дизайн-концепция удовлетворяет Заказчика, он

1.1 Порядок утверждения дизайн-концепции
Если представленная Исполнителем дизайн-концепция удовлетворяет Заказчика, он должен
утвердить

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

2. Функциональные требования 2.1 Классы пользователей 1) Гость – неавторизованный пользователь,

2. Функциональные требования
2.1 Классы пользователей
1) Гость – неавторизованный пользователь, обладает правами:

Статические разделы - просмотр
• Новости – просмотр
• Статьи – просмотр …
2) Авторизованный пользователь, обладает правами:
• Статические разделы - просмотр
• Разделы новостей – просмотр
• Новости – просмотр …
3) Правообладатель, наследует права авторизованного пользователя, и обладает:
• Статистика заказов – просмотр собственной ...
4) Администратор – пользователь, авторизованный в интерфейсе администрирования портала.
Полный доступ ко всем функциональным возможностям администрирования системы:
• Статические разделы - просмотр, добавление, редактирование, удаление
• Разделы новостей - просмотр, добавление, редактирование, удаление ...
Слайд 31

2.2 Требования к представлению сайта Требования к представлению главной страницы сайта.

2.2 Требования к представлению сайта
Требования к представлению главной страницы сайта.
Главная страница

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

2.3 Требования к структуре сайта Все названия разделов сайта, приведенные ниже,

2.3 Требования к структуре сайта
Все названия разделов сайта, приведенные ниже, являются

условными и могут корректироваться
по согласованию с Заказчиком в ходе проектирования. При помощи системы управления сайтом
(ITCMS) структура и состав разделов сайта в дальнейшем могут быть изменены и дополнены.
Первоначальная структура сайта должна иметь следующий вид:
1. Новости
Новость No2
Новость No1
История компании
2. Статьи
Вступительная статья
Классификация мышечных волокон
Слайд 33

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

2.4 Личный кабинет
Раздел, доступен для зарегистрированных пользователей.
В данном разделе авторизованному посетителю

доступны информация о пользователе портала,
либо свои личные данные. Редактирование раздела любого пользователя доступно членам группы
«Администраторы».
Изменение информации данного раздела производится путём заполнения данных формы,
состоящей из полей:
• Фамилия * – текстовое поле
• Имя * – текстовое поле
• Отчество * – текстовое поле
• Дата рождения * – поле дата/время
• Адрес – текстовое поле
• Пол – селектор (муж, жен)
• E-mail адрес – текстовое поле
• Псевдоним – текстовое поле
Слайд 34

2.5 Авторизация Пользователи могут авторизоваться на любой странице портала с помощью

2.5 Авторизация
Пользователи могут авторизоваться на любой странице портала с помощью специальной
формы

авторизации.
Форма содержит:
• Текстовое поле для ввода логина пользователя
• Кнопку отправки формы.
Данные для доступа (авторизации):
• Логин – адрес электронной почты пользователя
• Пароль – строка содержащая от 8 символов, состоящая из A-z, 0-9.
Ниже формы располагаются ссылка:
• Забыли пароль
Форма «Забыли пароль» содержит поля:
• Email адрес пользователя, указанный при регистрации
Слайд 35

2.6 Списки рассылок и уведомления Авторизованные пользователи могут управлять своими списками

2.6 Списки рассылок и уведомления
Авторизованные пользователи могут управлять своими списками рассылок,

а также
просматривать полученные уведомления.
Функциональные требования:
Администратор
• Добавить рассылку
• Удаление рассылку
• Редактирование рассылку
Авторизованный пользователь
• Просмотреть список рассылок
• Подписаться на список рассылок
• Отписаться от списка рассылок
• Просмотреть уведомления
Слайд 36

2.7 Общие требования к административной части Главная страница административной части должна

2.7 Общие требования к административной части
Главная страница административной части должна содержать

следующие пункты меню:
Страницы сайта (в соответствии с первым уровнем структуры сайта):
- Новости
- Статьи
- Тренажеры
- Упражнения
- Обратная связь
- О нас
- Полезная информация
- Новинки
Слайд 37

3. Требования к видам обеспечения 3.1 Требования к информационному обеспечению Требования

3. Требования к видам обеспечения
3.1 Требования к информационному обеспечению
Требования к хранению

данных - единая БД
Требования к языкам программирования - JavaScript, PHP
Требования к организации гиперссылок - все относительные ссылки
Требования к иллюстрациям - в формате gif или jpg
Требования к объему одной страницы - в среднем не должен превышать 170 kb.
Слайд 38

3.2 Требования к программному обеспечению Серверная часть: • Операционная система семейства

3.2 Требования к программному обеспечению
Серверная часть:
• Операционная система семейства Unix (Linux,

FreeBSD и пр.)
• Веб-сервер Apache 1.3.18 и выше
• Nginx, модуль mod_accel для Apache
• Набор библиотек и утилит ffmpeg
• PHP 4.2.0 и выше (должен быть собран как модуль Apache)
• СУБД MySQL 4.1.14 и выше (предпочтительно: поддержка формата InnoDB).
• Модули PHP: Mcrypt, FTP, ffmpeg-php
• Библиотеки PHP: Smarty, GeoIP
• Возможность доступа к localhost по FTP протоколу
• 2 пользователя БД
• Желательно, чтобы PHP не был запущен в SafeMode.
Клиентская часть:
Любой из перечисленный ниже браузеров (указана минимальная версия) с включенным
интерпретатором JavaScript:
• Internet Explorer 6
• Mozilla 1.6 (Firefox 1.0)
• Opera 9
Adobe Flash Player версии 9 и выше. Сайт должен быть работоспособен (информация,
расположенная на нем, должна быть доступна) при отключении в браузере поддержки flash и
JavaScript.
Слайд 39

3.3 Требования к техническому обеспечению Серверная часть: • Компьютер с процессором

3.3 Требования к техническому обеспечению
Серверная часть:
• Компьютер с процессором Pentium IV

2 ГГц (рекомендуется от 3 ГГц)
• Оперативная память 1 Гб (рекомендуется от 2 Гб)
• Место на жестком диске от 1 Гб
Точные технические характеристики сервера будут уточнены после завершения системы и
обширного тестирования всех модулей портала.
Клиентская часть:
• Компьютер с процессором Pentium IV 1ГГц (рекомендуется от 1.5ГГц)
• Оперативная память 256 Мб (рекомендуется от 512 Мб)
Слайд 40

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

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

Слайд 41

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

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

просмотра при разрешении 1024*768, 1280*1024 без горизонтальной полосы прокрутки и без пустых (белых) полей для основных типов разрешения.
Элементы управления должны быть сгруппированы однотипно – горизонтально либо вертикально – на всех страницах.
На каждой странице должны отображаться логотип компании и контактная информация.
Слайд 42

4. Требования к приемке-сдаче проекта 4.1 Требования к верстке страниц Требования

4. Требования к приемке-сдаче проекта
4.1 Требования к верстке страниц
Требования к верстке

страниц
html-документ должен соответствовать стандарту w3c в xHTML Strict, и быть сверстан с
применением CSS.
html- документ сайта должен иметь блочную верстку (верстку div'ами), вложенные блоки следует
отмечать отступами, для отступов использовать табуляцию.
html-код сайта должен быть удобен для понимания и структурирован, сложные и неоднозначные
моменты прокомментированы.
Слайд 43

4.2 Порядок предоставления информационного наполнения Заказчик предоставляет материалы в электронной форме

4.2 Порядок предоставления информационного наполнения
Заказчик предоставляет материалы в электронной форме в

zip-архиве, содержащем дерево
директорий, соответствующих структуре сайта.
В каждой директории размещается набор документов в формате MS Word – по одному документу
на каждый информационный модуль, информационные блоки которого опубликованы в
соответствующем разделе. Не допускается размещение текста в виде графических изображений
или иных нетекстовых элементов.
Слайд 44

4.3 Требования к документации В момент сдачи проекта заказчику предоставляется следующий

4.3 Требования к документации
В момент сдачи проекта заказчику предоставляется следующий набор

документов:
• Краткое руководство по переносу системы на другую хостинг - площадку.
• Техническое задание.
• Документация по стандартным модулям системы управления сайтом ITCMS.
• Краткое руководство (справочная информация) пользователя в административной части
сайта.
• Предусматривается обучение 1-2 представителей заказчика в течении 3 часов.
Слайд 45

4.3 Порядок предоставления дистрибутива По окончании разработки Исполнитель должен предоставить Заказчику

4.3 Порядок предоставления дистрибутива
По окончании разработки Исполнитель должен предоставить Заказчику дистрибутив

системы в
составе:
- архив с исходными кодами всех программных модулей и разделов сайта;
- дамп проектной базы данных с актуальной информацией.
Дистрибутив предоставляется на CD-диске в виде файлового архива.
Слайд 46

4.4 Дополнительные требования Требования к производительности Работа любого скрипта не должна

4.4 Дополнительные требования
Требования к производительности
Работа любого скрипта не должна превышать 60

секунд. При условии нагрузки на сервер не более
500.000 обращений к страницам портала в сутки.
Требования к безопасности
Требуется защитить исходный код общей части сайта. Не должно быть возможности считать php-
код скриптов. Требуется разграничение доступа. Пароли пользователей хранятся в
зашифрованном виде. Перехват данных на уровне протокола tcp возможен.
На уровне СУБД должно быть реализовано разграничение доступа к данным в БД.
Требования к надежности
Система может быть недоступна не более чем 24 часа в год. Резервирование данных осуществляет
хостинг-провайдер. У администратора сайта должна быть возможность выгрузить и загрузить
копию сайта.
Слайд 47

Итого: 1. Требования к графическому дизайну сайта 1.1 Требования к дизайну

Итого:
1. Требования к графическому дизайну сайта
1.1 Требования к дизайну сайта
1.2 Порядок

утверждения дизайн-концепции
2. Функциональные требования
2.1 Классы пользователей
2.2 Требования к представлению сайта
2.3 Требования к системе управления сайтом
2.4 Требования к разделению доступа
3. Требования к видам обеспечения
3.1 Требования к информационному обеспечению
3.2 Требования к программному обеспечению
3.3 Требования к техническому обеспечению
3.4 Требования к лингвистическому обеспечению
3.5 Требования к эргономике и технической эстетике
4. Требования к приемке-сдаче проекта
4.1 Требования к наполнению информацией
4.2 Требования к персоналу
4.3 Порядок предоставления дистрибутива
4.4 Порядок переноса сайта на технические средства заказчика