Анализ требований. Функциональные и нефункциональные требования.
Требования (requirements):
· подробное описание того, что должно быть реализовано
· возможности или условия, которым должна соответствовать система или проект
функциональные — какое поведение должна предлагать система
нефункциональные — особые свойства или ограничения, накладываемые на систему
Производительность:
Время отклика (Response Time)
Быстрота реагирования (Responsiveness)
Время задержки (Latency)
Пропускная способность (Throughput) количество транзакций в секунду
(Transactions per second, TPS)
Загрузка (Load)
Чувствительность к загрузке (Load Sensitivity)
A: отклик — 0,5 с для 10-20 пользов.
B: отклик — 0,2 с для 10 пользов., 2 с для 20 пользов.
Эффективность (Efficiency)
Мощность (Capacity)
Масштабируемость (Scalability)
Антитребование - это некое утверждение, что не должна делать программа. Например: "Программа не должна иметь внешнего загрузчика файлов". Хорошая спецификация должна иметь антитребования, чтобы явно описать, что программа не должна делать.
Требования к ПО состоят из трех уровней — бизнес-требования, требования пользователей и функциональные требования. Вдобавок каждая система имеет свои нефункциональные требования. Модель на рис. ниже иллюстрирует способ представления этих типов требований.
Бизнес-требования (business requirements) содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга. В этом документе объясняется, почему организации нужна такая система, то есть описаны цели, которые организация намерена достичь с ее помощью. Мне нравится записывать бизнес-требования в форме документа об образе и границах проекта, который еще иногда называют уставом проекта (project charter) или документом рыночных требований (market requirements document). Определение границ проекта представляет собой первый этап управление общими проблемами увеличения объема работ.
|
|
|
Требования пользователей (user requirements) описывают цели и задачи, которые пользователям даст система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие — отклик». Таким образом, в этом документе указано, что клиенты смогут делать с помощью системы.
Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы.
|
|
|
Системные требования (system requirements) - это высокоуровневые требования к продукту, которые содержат многие подсистемы. Говоря о системе, мы подразумеваем программное обеспечение или подсистемы ПО и оборудования. Люди — часть системы, поэтому определенные функции системы могут распространяться и на людей.
Требования и прецеденты. Формат описания прецедента. Структура прецедента.
Прецеде́нт — спецификация последовательностей действий (варианты последовательностей и ошибочные последовательности), которые может осуществлять система, подсистема или класс, взаимодействуя с внешними акторами (англ. Actors).
Прецеденты служат для документирования функциональных требований к программным системам. Прецедент описывает некоторый целостный фрагмент поведения системы, не вдаваясь при этом в особенности внутренней структуры субъекта. Определение прецедента содержит все свойственные ему виды поведения: основную последовательность, различные варианты стандартного поведения и различные исключительные ситуации с указанием ответной реакции на них. С точки зрения пользователя некоторые из видов поведения выглядят как ошибочные. Однако для системы ошибочная ситуация является одним из вариантов поведения, который должен быть описан и обработан.
|
|
|
Прецедент описывает взаимодействие программной системы с актерами в виде последовательности сообщений. В понятие актер входят люди, компьютерные системы и процессы.
При проектировании программной системы производится поиск таких классов для реализации прецедента, которые удачно сочетали бы в себе требуемые роли и не приводящие к излишнему усложнению системы. Реализацию прецедента можно смоделировать в виде одной или нескольких коопераций (реализаций прецедента).
Один и тот же прецедент может быть описан с различной степенью детализации.
Исполнитель (актер, actor) — некоторая роль, которую пользователь играет по отношению
к системе: люди, организации, машины, программы.
типы:
· основной (primary)
· вспомогательный (supporting)
· закулисный (offstage)
Прецедент (вариант использования, use case) — множество взаимосвязанных сценариев, объединенных некоторой общей целью пользователя (исполнителя).
|
|
|
Прецеденты — текстовые описания, а не диаграммы.
Форматы прицедентов:
· сжатый (при анализе требований для быстрого определения задач и масштабов системы) (Покупатель подходит к кассе с выбранными товарами. Кассир с помощью системы регистрирует каждый товар. Система отображает...)
· свободный (там же)Возврат товара
o Основной успешный сценарий: Покупатель подходит к кассе с товарами, подлежащими возврату. Кассир использует систему для регистрации каждого возвращаемого товара...
o Альтернативные сценарии: Если в авторизации кредитной карточки отказано, кассир информирует об этом покупателя и предлагает ему другой способ оплаты покупки.
o Если у системы возникли сложности при коммуникации с внешней системой вычисления налога...
· развернутый (для представления части наиболее важных прецедентов)
Содержимое прецедентов:
· Название
o Оформление продажи
· рамки
o Приложение автоматизации торговли NextGen
· уровень
o пользовательские (user-geal level)
o вспомогательные (subfuncion level)
o Задача, определенная пользователем
· основной исполнитель
o Кассир
· заинтересованные лица и их требования
o Кассир. Хочет точно и быстро ввести данные, не допуская ошибок в платеже, поскольку недостача вычитается из его зарплаты.
o Продавец. Хочет получить сои комиссионные от продажи. ...
· предусловия (preconditions)
o Кассир идентифицирован и аутентифицирован
· результаты или постусловия (postconditions)
o Данные о продаже сохранены. Налоги корректно вычислены. ... Чек сгенерирован
· Основной успешный сценарий
· Расширения
· Специальные требования
· Список технологий и типов данных
· Частота использования
· Список открытых вопросов
Дата добавления: 2018-05-13; просмотров: 784; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!