Lecture 04 11/9/2011 12:12:00 PM Functional specification

Lecture 04
5/2/2016 6:47:00 PM
Functional specification & requirements, Black Box – Equivalence partitioning, Boundary value analysis, State
transition testing, use case testing
КАКИЕ БЫВАЮТ ТРЕБОВАНИЯ?
Требования к ПО состоят из трех уровней — бизнес-требования, требования пользователей и
функциональные требования. Вдобавок каждая система имеет свои нефункциональные требования. Модель
на
рис.
ниже
иллюстрирует
способ
представления
этих
типов
требований.
Бизнес-требования (business requirements) содержат высокоуровневые цели организации или заказчиков
системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных
пользователей, отдел маркетинга. В этом документе объясняется, почему организации нужна такая система,
то есть описаны цели, которые организация намерена достичь с ее помощью.
Требования пользователей (user requirements) описывают цели и задачи, которые пользователям даст
система. К отличным способам представления этого вида требований относятся варианты использования,
сценарии и таблицы «событие — отклик». Таким образом, в этом документе указано, что клиенты смогут
делать с помощью системы.
Функциональные требования (functional requirements) определяют функциональность ПО, которую
разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнестребований. Иногда они называются требованиями поведения (behavioral requirements), они содержат
положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять
пользователю
подтверждение
о
заказе».
Функциональные требования документируются в спецификации требований к ПО (software requirements
specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы.
Системные требования (system requirements) - это высокоуровневые требования к продукту, которые
содержат многие подсистемы. Говоря о системе, мы подразумеваем программное обеспечение или
подсистемы ПО и оборудования. Люди — часть системы, поэтому определенные функции системы могут
распространяться и на людей.
Бизнес-правила (business rules) включают корпоративные политики, правительственные постановления,
промышленные стандарты и вычислительные алгоритмы. Бизнес-правила не являются требованиями к ПО,
потому что они находятся снаружи границ любой системы ПО. Однако они часто налагают ограничения,
определяя, кто может выполнять конкретные ВИ, или диктовать, какими функциями должна обладать
система, подчиняющаяся соответствующим правилам. Иногда бизнес-правила становятся источником
атрибутов качества, которые реализуются в функциональности. Следовательно, вы можете отследить
происхождение конкретных функциональных требований вплоть до соответствующих им бизнес-правил.
Нефункциональные требования описывают цели и атрибуты качества. Атрибуты качества (quality
attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его
характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:
* легкость и простота использования
* легкость перемещения
* целостность
* эффективность и устойчивость к сбоям
* внешние взаимодействия между системой и внешним миром
* ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки
внешнего вида и структуры продукта
1
Lecture 04
5/2/2016 6:47:00 PM
Характеристика продукта (feature) — это набор логически связанных функциональных требований,
которые обеспечивают возможности пользователя и удовлетворяют бизнес-цели. В области коммерческого
ПО характеристика представляет собой узнаваемую всеми заинтересованными лицами группу требований,
которые важны при принятии решения о покупке — элемент маркированного списка в описании продукта.
Функциональная спецификация в разработке программного обеспечения — это документ, описывающий
требуемые характеристики системы. Документация описывает необходимые для пользователя системы
входные и выходные параметры.
Функциональная спецификация не определяет операции, происходящие внутри данной системы и каким
образом будет реализована её функция. Другими словами, спецификация детально описывает, что продукт
будет делать, как с продуктом будет взаимодействовать пользователь, как будет продукт выглядеть.
2
Lecture 04
5/2/2016 6:47:00 PM
Спецификация представляет собой подробное, с точки зрения пользователя и заказчика, описание решения и
порядка его функционирования. Функциональная спецификация служит следующим целям:
 Инструкции для разработчиков.
 Основа для оценки работ.
 Договоренность с заказчиком о том, что должно быть разработано.
 Точка синхронизации для всей группы.
На основе функциональной спецификации разрабатываются основной план и основной график проекта.
Для чего писать спецификации?
Девелопер работающий по спецификация в идеале может найти ответы на все свои вопросы о программе в
спецификациях. И так как спецификация была одобрена клиентом программист создаёт программу именно
такой какой её ожидает увидеть клиент. Ничего не нужно домысливать или угадывать.
Requirements (требования)
 Требования – описывают то, что клиенту нужно
 Спецификации – описывают то, какая функциональность нужна для удовлетворения нужд описанных в
требованиях
Функциональные и нефункциональные требования:
Функциональные требования - определяют что система или компонент должны быть способны сделать.
Нефункциональные требования – описание того какой система должна быть
<<<<PRACTICE: Cтуденты самостоятельно распредляют приведёные ниже утверждения по группам
«функциональные» и «не функциональные requirements»:>>>>>













System must be easy to use (non-functional)
System must support Win 98, Mac OS Leopard and Windows Vista operating systems (non-functional Portability)
System’s response time must not exceed 20 ms per transaction (non-functional - Efficiency)
System must provide the ability to register online (functional)
System must not fail if it operates 20% beyond the normal load level (non-functional - Performance)
System must provide the ability to synchronize information with MS Access (functional)
System must allow user to provide input data both via UI and file import (functional)
System must support communication via SSL (Secure Socket Layer) (non-functional – Integrity, Security)
System must be fast (non-functional)
System must provide the ability to save documents and operation should not take more than 10 seconds
(functional/non-functional)
System must be able to support 20 articles opened simultaneously (non-functional)
System must support all documents created in all versions of MS Access (non-functional)
System must provide the ability to review users activities (functional)
Статическое тестирование
В этой лекции мы рассмотрим важную область тестирования – «технику статического тестирования».
Статическое тестирование подразумивает тестирование без исполнения кода/запуска приложения.
Несмотря на то что программа не проверяется в привычном нам понимании через проверку
функциональности на рабочем компоненте/продукте Статическое тестирование очень важно, потому что
позволяет выявить ошибки до выполнения кода, в более раних стадиях проекта делая исправление ошибок
проще и дешевле, чем если бы ошибка была выявлена во время тестирования самой программы.
3
Lecture 04
5/2/2016 6:47:00 PM
Статическое тестирование нацелено на тестирование requirements и specifications, на проверку кода без его
запуска.
Проверка requirements и specifications называется Review (ревью).
Проверка кода без его запуска – Static analysis (статический анализ).

КАКАЯ ЦЕЛЬ ПРОВЕДЕНИЯ REVIEW (ДОКУМЕНТОВ И КОДА) ДО НЕПОСРЕДСТВЕНО ТЕСТИРОВАНИЯ?
Review
Review – это систематическое изучение документов одним или большим колчеством людей с основной целью выявить и устранить ошибки.
Review может быть применено к любому документу - requirements и specifications, описание дизайна системы,
код, тест планы или тест кейсы.
Review – первое тестирование, которому подвергается продукт и оно может проходить ещё до стадии
разработки программы, т.к. документация как правило анализируется задолго до того как пишется первый
код.
Подход по анализу specifications и requirements на первом этапе разработки позволяет выявить ошибки до
того как они станут частью исполняемого кода. Если баг выявленый на стадии Review был бы обнаружен на
стадии разработки/тестирования, то это привело бы к дополнительным денежным и временым затратам по
выявлению бага, поиску первопричин, анализу кода и т.п.
Помимо анализа спецификаций проводится просмотр кода на соотвествие принятым стандартам, что также
может привести к сокращению ошибок появляющихся во время тестирования.

КАКОВЫ ПОЛОЖИТЕЛЬНЫЕ СЛЕДСТВИЯ REVIEW ДОКУМЕНТАЦИИ?
Помимо самых очевидных приемуществ просмотра документации - сокращение расходов и количества
ошибок в продукте – есть другие приемущества Review:
 Скорость разработки кода может быть улучшена благодаря выявлению ошибок на уровне
документации. Review позволяет убедиться, что спецификации понятны и чётки, что в свою очередь
позволяет девелоперу быстрее выполнять непосредствено разработку/написание кода.
 Затраты на тестирование могут бы сокращены благодаря сокращению вероятности появления blocking
bugs, в случае которых тестер вынужден ждать исправления со стороны разработчика прежде чем
продолжить работу.
 Во время ревью осуществляется разбор документов, что улучшает понимание содержимого ещё до
начала разработки.
Более



всего во время Review выявляются ошибки следующего плана:
Отклонение от стандартов определённых в команде или принятых в компании
Ошибки в requirements. Например, не описаны какие-то элементы программы.
Выявление ошибок в архитектуре продукта. Например, интерфейс принимающего и отправляющего
компонента программы не совпадает.
Каждое Review нацелено на выявление ошибок в документах, но надо понимать, что разные подход к ревью
выявляет специфичные для подхода ошибки.
Процесс Review
Процесс Review может широко отличаться в зависимости от уровня формальности, где под формальностью
подразумивается уровень документированости процесса и подход к организации процесса.
Одни типы review абсолютно «неформальны», другие же наоборот очень. На примерах будет яснее.
Базовый процесс review
Оба типа ревью – неформальный и формальный – включают в себя следующие базовые элементы:
 Документ изучается участниками процесса
 Участники выявляют ошибки или проблемы и объясняют их автору документа в устной форме или в
виде документа (например, пометки в рассмариваемом документе или занесение багов)
4
5/2/2016 6:47:00 PM
Lecture 04

Автор принимает решение об обновлении/исправлении документа, основываясь на полученых
репортах (устных или письменных)
Формальное ревью
Kick-off
Planning
Individual
preparation
Follow-up
Review
meeting
Rework
Planning (планирование)
 Выбор персонала (selecting personnel) – то есть определение людей, полезных для процесса. Нет
смысла выбирать людей, которые будут согласны с каждым пунктом в рассматриваемом документе.
Как правило в ревью вовлекаются люди из разных отделов организации. Соотвествено один и тот же
документ будет рассмотрен под разными углами.
 Назначение ролей (allocating roles) – каждому участнику даётся определённая роль, чтобы обозначить
угол под которым будет рассмотрен документ. Тестер может подходить к ревью с точки зрения
возможностей тестирования, другой участник может анализировать документ в свете простоты
использования.
 Определение входного и выходного критерия процесса ревью.
 Определение частей документов необходимых для ревью. Зависит от размера документа.
Kick-off (начало)
На этой стадии выдаются документы, предназначеные для ревью, объясняются цели, процесс. Kick-off
может быть проведен ввиде митинга или через простую рассылку информации по почте – метод будет
зависить от временых рамок и объёма информации, которую необходимо передать.
5
Lecture 04
5/2/2016 6:47:00 PM
Individual preparation (индивидуальная подготовка)
Работа с документом проделываемая каждым участником самостоятельно. Необходимо прочтение
документа, выявление потенциальных ошибок, вопросов и комментариев.
Review meeting
На этом шаге проводиться обсуждение выявленых ошибок и документирование их. Также
обсуждаются рекомендации по исправлению ошибок. Подход (то есть детальное документирование ошибок
или ограничение письмеными замечаниями) определяется исходя из
 Доступного времени
 Требованиямий автора документа
Rework
После review митинга у автора документа будет ряд ошибок для исправления. Rework – исправление
выявленых ошибок.
Follow-up
Производится замер количества выявленых ошибок и сколько времени было затрачено на ревью.
Рассматривается также совпадение с выходным критерием.
Роли и области отвественности
Manager
Определяет что будет проревьюено, определяет необходимое время и определяет если цели ревью были
достигнуты. Managers обычно не вовлекаются в сам процесс ревью.
Moderator
Также называется “review leader”.
В задачи модератора входит планирование и организация ревью, проведение самого ревью и занятие
задачами из Follow up.
Author
Автор – создатель документа или человек отвечающий за создание документа. Автор также занимается
исправлением выявленных ошибок.
Reviewers
Люди со специальной подготовкой (технической или бизнесс подготовкой), которые после подготовительных
работ выявляют ошибки в документах.
Scribe (or recorder)
Посещает ревью митинги и документируют все выявленые ошибки.
6
5/2/2016 6:47:00 PM
Lecture 04
Типы ревью
Один и тот же документ может подвергаться разным типап ревью.
Существует четыре типа уровня ревью:
Low
Informal
Level of formality
Walkthrough
Technical review
Inspection
High
Каждый тип ревью имеет свои характеристики:
Informal review
 Результаты ревью не обязтельно будут документироваться
 У ревьюера не обязательно должны быть технические навыки, но он должен быть способен быстро
убедиться, что документ имеет смысл
 Основная цель найти ошибки
 Ревью может быть проведено программистами в паре (один программист просматривает код другого)
Walkthrough
 Ревью митинг проводится автором документа
 Формат проведения митингов свободный (от неформального до самого формального)
 Подготовка ревьюеров до митинга, создание репорта опционально
 Основная цель ознакомиться и понять документ и найти ошибки
Technical review
 Хорошо документированы и используют чёткий подход по определению ошибок
 Митинг проводится модератором, но не автором документа
 Ревьюеры готовятся к митингу
 Митинг может проходить как в формальном формате и неформальном и ставить перед собой цели
обсудить и принять решение по поводу документа, выявить ошибки, проверить документ на
соотвествие спецификациям и стандартам.
7
Lecture 04
5/2/2016 6:47:00 PM
Inspection – наиболее формальный тип ревью
 Ведуться обучеными модераторами (не авторами документа)
 Процесс Inspection формальный, основан на правилах, опирается на входной и выходной критерий.
 Подготовка к митингу основательная с детальным изучением документа
 По окончанию inspection создаётся репорт со списком выявленых замечаний и ошибок
 После митинга применяется регламентированый процесс по отслеживанию применения замечаний и
исправлений документа
 Основная цель выявить ошибки
На практике грани между каждым типом стераются. В разных компаниях одни и те же шаги могут называть
Technical review или Inspection.






Факторы удачного проведения review
У каждого ревью должен быть чёткий заранее определённый список целей. К работе должны быть
привлечены люди, способные достигнуть поставленых целей
Любые обнаруженые ошибки и замечания конструктивно воспринимаются. Ошибки озвучиваются
объективно
Применение одного из типов ревью (формальное или неформальное)
Среди участников распределяются роли (если необходимо) в целях улучшения эффективности
Необходима поддержка со стороны менеджмента
Статический анализ (Static Analysis)
Как ревью, статический анализ предполагает поиск ошибок без запуска самого кода программы. Однако,
статический анализ в отличие от ревью проводиться после того как код был написан.
Статический анализ может выявить баги, которые сложно обнаружить во время тестирования программы
через execution. Анализируется код, например, рисуются графики зваимодействия между модулями.
Цели статистического анализа:
 Ранее выявление багов
 Ранее выявление слабых моментов в архитектуре и коде
 Выявление ошибок относящихся к нарушению стандартов разработки, нарушению взаимодействия
мужде моделями, интерфейсами классов и т.п.
 Предотвращение появление багов – анализ первопричины имеющихся багов помогает исправлять
подобные баги на уровне архитектуры программы или на раной стадии разработки
Типичные ошибки выявляемые статическим анализом:
 На уровне кода – обращение к переменной без определённого значения
 Переменные, которые никогда не используются.
 Недосягаемый код (dead code)
 Нарушение стандартов программирования (например, комментарии к коду написаны кода, но
отсутствуют коммаентарии на протяжении кода)
 Нарушения по безопасности (например, стуктуры для хранения паролей недостаточно защищены)
Tools for static analysis
Анализ кода и структур также осуществляется с помощью автоматических инструментов (tools). Программы
исполняются в автономном режиме и генерируют репорт своей работы. Анализируется код на наличие тех же
проблемы, что были описаны раньше – корректность взаимодействия компонентов, соблюдение стандартов
кодирования и т.п.
8