Как написать требования к приложению
Терминология – вот камень преткновения, когда начинается обсуждение требований к программному обеспечению. Подчас количество названий одного и того же документа начинает приближаться к числу экспертов, которые работают над данной задачей. Стоит ли удивляться, что в скором времени такое многообразие приведёт к сумятице, а последняя плавно перерастёт в серьёзные проблемы коммуникации?
Эксперты могут называть документ по-разному:
– требование к проекту;
– пользовательская точка зрения;
– требование к программному обеспечению;
– требование к продукту;
Мало того. Вышеперечисленные «рабочие названия» часто наполнены совершенно разным смыслом. Он зависит от того, является эксперт заказчиком или представляет сторону разработчиков. Первые часто считают, например, то же бизнес-требование полноценной высокоуровневой концепцией продукта, ориентируясь на который, исполнители вполне смогут создать желаемое. Программисты же со своей стороны видят в нём всего лишь «разработку интерфейса пользователя». Правда – достаточно детализированную.
Важное уточнение. Слово «документ» в данном контексте вовсе не означает «бумажный документ». Более того, оно даже не – «электронный документ». Здесь «документ» – своего рода «контейнер», где хранится информация о требованиях.
Такой «контейнер» может представлять из себя:
– стандартный (традиционный) документ;
– сочетание всего вышеперечисленного.
Само же требование к ПО состоит из трёх уровней: бизнес-требования, пользовательские и функциональные.
Легко догадаться: первые представляют из себя цели, ради которых собралась команда; вторые – пожелания клиентов. А вот последние обращены исключительно к разработчикам. Они «увязывают» между собой первый и второй уровень. То есть делают так, что пользователь, работая с готовым ПО, автоматически движется в сторону выполнения задачи, ради которой, данный продукт, собственно, и был создан. В случае сомнений, к какому именно уровню относится то или иное требование, есть смысл задать «ключевой» вопрос. Если он будет начинаться со слова «хочу», то мы имеем дело с уровнем пользователя, а если «должен» – речь идет о функциональном.
Несколько иной подход к терминологии позволяет разбить подготовку к созданию ПО на этапы и тем самым значительно улучшить качество продукта. В данном случае процесс носит название «разработка технических условий». Он делится на две части: разработка требований и управление требованиями.
Разработка требований в свою очередь включает в себя:
Каждый из пунктов требует к себе особого внимания. И насколько тщательно они будут проработаны на совместных обсуждениях проекта с участием всех заинтересованных сторон – пользователей-клиентов, бизнес-аналитиков, программистов – тем больше шансов, что готовый продукт будет содержать лишь допустимый минимум ошибок.
К тому же, что просчёты обязательно будут, лучше заранее морально подготовиться. Идеальных требований к программному обеспечению просто не существует.
А раз задача настолько сложна, есть смысл сделать её хотя бы немного проще. Для начала – условиться о единой терминологии.
Терминология – вот камень преткновения, когда начинается обсуждение требований к программному обеспечению. Подчас количество названий одного и того же документа начинает приближаться к числу экспертов, которые работают над данной задачей. Стоит ли удивляться, что в скором времени такое многообразие приведёт к сумятице, а последняя плавно перерастёт в серьёзные проблемы коммуникации?
Эксперты могут называть документ по-разному:
– требование к проекту;
– пользовательская точка зрения;
– требование к программному обеспечению;
– требование к продукту;
Мало того. Вышеперечисленные «рабочие названия» часто наполнены совершенно разным смыслом. Он зависит от того, является эксперт заказчиком или представляет сторону разработчиков. Первые часто считают, например, то же бизнес-требование полноценной высокоуровневой концепцией продукта, ориентируясь на который, исполнители вполне смогут создать желаемое. Программисты же со своей стороны видят в нём всего лишь «разработку интерфейса пользователя». Правда – достаточно детализированную.
Важное уточнение. Слово «документ» в данном контексте вовсе не означает «бумажный документ». Более того, оно даже не – «электронный документ». Здесь «документ» – своего рода «контейнер», где хранится информация о требованиях.
Такой «контейнер» может представлять из себя:
– стандартный (традиционный) документ;
– сочетание всего вышеперечисленного.
Само же требование к ПО состоит из трёх уровней: бизнес-требования, пользовательские и функциональные.
Легко догадаться: первые представляют из себя цели, ради которых собралась команда; вторые – пожелания клиентов. А вот последние обращены исключительно к разработчикам. Они «увязывают» между собой первый и второй уровень. То есть делают так, что пользователь, работая с готовым ПО, автоматически движется в сторону выполнения задачи, ради которой, данный продукт, собственно, и был создан. В случае сомнений, к какому именно уровню относится то или иное требование, есть смысл задать «ключевой» вопрос. Если он будет начинаться со слова «хочу», то мы имеем дело с уровнем пользователя, а если «должен» – речь идет о функциональном.
Несколько иной подход к терминологии позволяет разбить подготовку к созданию ПО на этапы и тем самым значительно улучшить качество продукта. В данном случае процесс носит название «разработка технических условий». Он делится на две части: разработка требований и управление требованиями.
Разработка требований в свою очередь включает в себя:
Каждый из пунктов требует к себе особого внимания. И насколько тщательно они будут проработаны на совместных обсуждениях проекта с участием всех заинтересованных сторон – пользователей-клиентов, бизнес-аналитиков, программистов – тем больше шансов, что готовый продукт будет содержать лишь допустимый минимум ошибок.
К тому же, что просчёты обязательно будут, лучше заранее морально подготовиться. Идеальных требований к программному обеспечению просто не существует.
А раз задача настолько сложна, есть смысл сделать её хотя бы немного проще. Для начала – условиться о единой терминологии.
Прежде чем начинать проект, обязательно нужно знать, какой результат (продукт) вы хотите получить. И порой этот продукт необходимо описать самым тщательным образом. Иными словами, нужно знать, какие требования заказчик предъявляет к продукту. Полный набор этих требований называют каталогом требований, или спецификацией.
Крупные и сложные проекты обычно насчитывают тысячи требований. Бизнес-анализ как раз и позволяет выявлять проблемы и определять, что требуется для их преодоления. В крупных проектах, таких, как разработка программного обеспечения, сбор требований является одним из важнейших этапов жизненного цикла проекта, котоорыый может занять несколько недель/месяцев.
Для выявления требований проводится серия структурированных интервью с заказчиками, которые позволяют точно определить их пожелания к готовому продукту. Попытка напрямую узнать у заказчика, какие результаты ему нужны, может закончится крахом: заказчик станет выдвигать все новые и новые требования, так что вы просто будете не в силах их удовлетворить. Помните, любое требование влияет на продолжительность и стоимость проекта. Соответственно, получая подробный список требований, вам нужно знать, являются ли они:
Важно сохранять пользовательские требования для хранения их в первоначальном виде, отслеживания источника их возникновения (вплоть до конкретного лица), расстановки их приоритетов (с точки зрения пользователя) и т.д.
Схема процесса разработки с уровнями требований
Формирование и анализ требований
Анализ предметной области. Аналитики должны изучить предметную область, где будет эксплуатироваться система.
Сбор требований. Это процесс взаимодействия с лицами, формирующими требования. Во время этого процесса продолжается анализ предметной области.
Классификация требований. На этом этапе бесформенный набор требований преобразуется в логически связанные группы требований.
Разрешение противоречий. Без сомнения, требования многочисленных лиц, занятых в процессе формирования требований, будут противоречивыми. На этом этапе определяются и разрешаются противоречия такого рода.
Назначение приоритетов. В любом наборе требований одни из них будут более важны, чем другие. На этом этапе совместно с лицами, формирующими требования, определяются наиболее важные требования.
Проверка требований. На этом этапе определяется их полнота, последовательность и непротиворечивость.
Аттестация требований
Аттестация должна продемонстрировать, что требования действительно определяют ту систему, которую хочет иметь заказчик. Проверка требований важна, так как ошибка в спецификации требований могут привести к переделке системы и большим затратам, если будут обнаружены во время процесса разработки системы или после введения её в эксплуатацию. Стоимость внесения в систему изменений, необходимых для устранения ошибок в требованиях, намного выше, чем исправление ошибок проектирования или кодирования. Причина в том, что изменение требований обычно влечёт за собой значительные изменения в системе, после внесения которых она должна пройти повторное тестирование.
Подготовка к интервью по сбору требований у заказчика
Источники: Топ-менеджмент компании
Документ: Бизнес-требования (обоснование потребностей инициативы)
Ответственный: Менеджер проекта
Состав бизнес-требований может отличаться на практике. Обычно включаются следующие пункты:
- Описание контекста и списка ключевых заинтересованных лиц
- Описание целей создания системы и критериев достижения
- Ключевые бизнес-требования к решению и их приоритеты
- Существующие и возможные ограничения на решение
Контекст — это то, что стало причиной создания системы, какая ситуация была в компании, какая проблема и как пришли к тому, что систему надо делать.
Этот документ описывает рекомендуемое содержание документа требований заинтересованных лиц:
- Бизнес-назначение
- Бизнес-рамки
- Обзор бизнеса
- Заинтересованные лица
- Организационная среда
- Цели и результаты
- Бизнес-модель
- Информационная среда
- Бизнес-процессы
- Политики и правила
- Ограничения деятельности
- Организационная структура
- Концепция использования системы
- Сценарии эксплуатации
- Проектные ограничения
Эти требования должны определять только внешнее поведение системы, избегая по возможности определения структурных характеристик системы. Пользовательские требования должны быть написаны естественным языком с использованием простых таблиц, а также наглядных и понятных диаграмм.
Проблемы при формировании пользовательских требований
Отсутствие чёткости изложения. Иногда нелегко изложить какую-либо мысль естественным языком чётко и недвусмысленно, не сделав при этом текст многословным и трудно читаемым.
Смешение требований. В пользовательских требованиях отсутствует чёткое разделение на функциональные требования, на системные цели и проектную информацию.
Объединение требований. Несколько различных требований к системе могут описываться как единое пользовательское требование.
Системные требования
Функциональные требования
Стандартные формы для специфицирования функциональных требований:
- Описание функции или объекта.
- Описание входных данных и их источники.
- Описание выходных данных с указанием пункта их назначения.
- Указание, что необходимо для выполнения функции.
- Если это спецификация функции, необходимо описание предварительных условий (предусловий), которые должны выполняться перед вызовом функции, и описание заключительного условия (постусловия), которое должно быть выполнено после завершения выполнения функции.
- Описание побочных эффектов (если они есть).
Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
Нефункциональных требований
Нефункциональные требования отображают пользовательские требования:
Нефункциональные требования основываются на бюджетных ограничениях, учитывают организационные возможности компании-разработчика, возможность взаимодействия разрабатываемой системы с другими программными и вычислительными системами, а также такие внешние факторы, как правила техники безопасности, законодательство о защите интеллектуальной собственности и т.п.
Нефункциональные требования описывают цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:
- легкость и простота использования;
- легкость перемещения;
- целостность;
- эффективность и устойчивость к сбоям;
- внешние взаимодействия между системой и внешним миром;
- ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта.
Требования предметной области
Требования предметной области характеризуют ту предметную область, где будет эксплуатироваться система. Эти требования могут быть функциональными и не функциональными. Эти требования отображают условия, в которых будет эксплуатироваться программная система. Они могут быть представлены в виде новых функциональных требований или в виде ограничений на уже сформулированные функциональные требования или в виде указаний, как система должна выполнять вычисления. Невыполнение требований предметной области может привести к выходу системы из строя.
Требования к продукту
Требования к продукту описывают эксплуатационные свойства программного продукта. Это требования к производительности системы, объёму необходимой памяти, надёжности (определяет частоту возможных сбоев в системе), переносимости системы на разные компьютерные платформы и удобству эксплуатации.
Организационные требования
Организационные требования отображают политику и организационные процедуры заказчика и разработчика ПО. Включают стандарты разработки программного продукта, требования к реализации ПО (т.е. к языку программирования и методам проектирования), выходные требования, которые определяют сроки изготовления программного продукта, и сопутствующую документацию.
Требования к интеграции
Требования к интеграции описывают низкоуровневый интерфейс взаимодействия новой системы с несколькими другими системами компании. Цель данного документа обосновать и формализовать выбор метода интеграции. Документ содержит в себе описание методов и способов интеграции с внешними системами, сервисами.
Интеграция приложений – это технологические процессы, используемые для организации обмена данными между различными информационными системами с помощью средств интеграции, предоставляемыми приложениями. К средствам интеграции, предоставляемыми приложениями относятся API функции, пакеты обработки и экспорта/импорта данных.
Интеграция через ESB
Интеграция через ESB (Enterprise Service Bus, «Сервисная шина предприятия») применяется для обеспечения информационных систем возможностями для взаимодействия с сервисами. Использование этого метода интеграции приложений обеспечивает слабую связанность между информационными системами, так как системы взаимодействуют не напрямую, а через сервисы, размещенные на сервисной шине предприятия.
Основными функциями ESB являются:
Интеграция точка-точка
Интеграция приложений напрямую, является методом интеграции, при котором взаимодействие между системами происходит без применения универсального централизованного посредника, такого, как сервисная шина предприятия (ESB).
Интеграция данных
Интеграция данных – это процессы пакетного обмена данных между информационными системами, с помощью средств баз данных этих систем или экспорта-импорта файлов.
Задачи интеграции данных:
- Передачи больших объемов данных, включающая логику преобразования данных.
- Синхронизация (репликация) данных информационных систем
Интеграция ETL
Интеграция ETL характеризуется следующим сценарием:
На платформе ETL пишется процесс, который
1) С помощью средств доступа к БД 1ой системы забирает из таблиц 1ой системы данные
2) С помощью средств и ресурсов БД 1ой или 2й системы или своих собственных механизмов осуществляет преобразование к структурам таблиц 2й системы
3) Загружает данные в таблицы БД 2й системы.
Файловый обмен
Файловый обмен характеризуется следующим сценарием:
1) Приложение, которому требуется передать данные другому приложению, сохра¬няет их в файле.
2) Разрабатывается интеграционное решение, которое преобразует формат файла в формат, требуемый другим приложением. (В частном случае для этого дорабатывается одна из интегрируемых систем)
3) Приложение которому нужны данные, загружает подготовленный файл.
Требования к пользовательскому интерфейсу
- требования к внешнему виду пользовательского интерфейса и формам взаимодействия с пользователем;
- требования по доступу к внутренней функциональности системы при помощи пользовательского интерфейса.
К первой группе можно отнести следующие типы требований:
Ко второй группе относятся следующие типы требований:
- Требования к реакции системы на ввод пользователя
- Требования к времени отклика на команды пользователя
С точки зрения разработки требования можно разделить на два класса.
Постоянные требования. Это относительно стабильные требования, которые исходят из основной деятельности организации и касаются непосредственно предметной области, где будет эксплуатироваться система.
Изменяемые требования. Эти требования отображают изменения, сделанные во время разработки системы или после ввода её в эксплуатацию.
Классификация изменяемых требований
Процесс управления изменениями
Анализ проблем изменения спецификации. Процесс начинается с определения проблем в требованиях или с прямого предложения внесения изменений. На этой стадии проблема или предложенные изменения анализируются для проверки их обоснованности. Затем могут быть сделаны более определённые предложения относительно изменений в требованиях.
Анализ осуществимости и расчёт их стоимости. Эффект от внесения предложенного изменения оценивается с использованием оперативного контроля. Стоимость изменений оценивается двумя показателями: стоимостью внесения изменения в спецификацию и стоимостью внесения изменений в структуру системы и непосредственно в программный код. По окончании этого этапа принимается решение, продолжать или нет внесение изменений в систему.
Реализация изменений. Реализация изменений в системной спецификации, структуре системы и программном коде.
Заказчики системы. Определяют требования, проверяют специфицированные требования на соответствие требованиям заказываемой системы. Они могут вносить изменения в спецификацию.
Руководство компании-разработчика. Использую спецификацию для расчёта цены системы и для планирования процесса разработки системы.
Разработчики системы. Используют спецификацию в процессе разработки системы.
Инженеры, тестирующие систему. Используют спецификацию при разработке тестов, необходимых для аттестации системы.
Инженеры поддержки системы. Спецификация помогает разобраться в системе и понять, как взаимодействуют её отдельные компоненты.
Как и у всех путешествий, у проекта улучшения процессов должна быть цель. Если не определить конкретных целей по улучшению, люди не смогут работать согласованней, а вы не сможете сказать, есть ли движение вперед, не сможете определять приоритеты задач и сказать, когда цель достигнута.
Метрика — измеримая характеристика проекта, продукта или процесса.
Ключевые показатели производительности (KPI) — это метрики, привязанные цели и служащие мерилом продвижения проекта к достижению определенной цели или результата. Набор KPI-показателей может отображаться на контрольной панели, показывая приближение к целям.
При определении целей по совершенствованию процессов нужно иметь в виду два обстоятельства.
- Во-первых, надо помнить, что совершенствование процесса ради самого совершенствования бессмысленно. Поэтому спросите себя, действительно ли достижение цели даст искомый рост бизнес-ценности.
- Во-вторых, не стоит разочаровывать членов команды, ставя цели, которые нереально достичь, поэтому нужно хорошенько подумать, достижима ли поставленная цель в вашей среде. Чтобы цель улучшения была разумной, ответ на оба вопроса должен быть положительным.
Если вы выбрали реалистичные KPI для своих целей, но не видите признаков прогресса по истечении разумного времени, нужно провести расследование:
- Правильно ли были проанализированы проблемы и выявлены их первопричины?
- Выбрали ли вы действия по улучшению, непосредственно направленные на эти первопричины?
- Был ли реалистичным план реализации этих действий по улучшению? Был ли план реализован, как планировалось?
- Изменилось ли что-то со времени исходного анализа, что должно было заставить переориентировать действия команды по улучшению?
- Действительно ли члены команды приняли новые приемы работы и прошли период обучения, чтобы начать активно применять их на практике?
- Были ли поставлены реалистичные цели, которые команда была в состоянии достичь?
Высокопроизводительные проекты отличаются эффективными процессами на всех этапах создания требований: выявления, анализа, спецификации, проверки и управления. Для облегчения выполнения этих процессов каждой организации необходим набор документов процесса (process assets).
Любой процесс определяют выполняемые действия и получаемые результаты; документы процесса помогают команде выполнять процессы последовательно и эффективно. Эти документы позволяют участникам проекта понять, какие шаги им следует предпринять и каких результатов от них ждут.
Во всех научных работах: реферате, курсовой, дипломе, диссертации приложения оформляются совершенно одинаково согласно ГОСТ 2.301 и ГОСТ 2.105-95. В статье подробно, что и как оформить вставить в приложение.
Как оформить приложение в любой работе правильно обновлено: 29 октября, 2021 автором: Научные Статьи.Ру
Что такое приложение?
В приложение выносятся все материалы, которые из-за большого объема (А4 и больше) не размещают в тексте работы.
Приложение носит информационный или справочный характер. Оно подтверждает указанные в работе тезисы.
В случае, если возникают разногласия по поводу выводов, сделанных автором работы, подробные данные из приложений помогут прояснить ситуацию.
Например, у членов комиссии на защите появились вопросы, почему автор пришел к определенным выводам на основе проведенного анкетирования.
Объем приложения не учитывается в общем объеме научной работы. Если требуемый объем составляет 60 страниц, значит работа без приложений должна составлять 60 страниц.
К самому приложению требований по объему не предъявляется, оно может состоять из 1 или 100 страниц.
Нужна помощь в написании курсовой?
Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Наша система гарантирует сдачу работы к сроку без плагиата. Правки вносим бесплатно.
Общие требования к оформлению приложений
Заголовок «Приложения» располагают по центру первой страницы раздела.
Каждое приложение должно иметь свой номер. Его располагают вверху страницы (например, Приложение 1). Можно именовать, используя римские или арабские цифры, латинские или русские буквы.
В разных вузах требования к оформлению приложений могут различаться. Это касается расположения нумерации и оформления заголовков.
Таблицы в приложении
Пример оформления приложения
Каждое приложение размещается на отдельном листе, даже если он не занимает всю страницу целиком.
В конце страницы вставляют «разрыв страницы», чтобы приложения не смещались при открытии файла в другой версии Microsoft Word.
Перенос таблиц в приложении
Если файл больше одного листа, его продолжение переносят на следующий лист, приписывая при этом «продолжение приложения №…». Это касается, в первую очередь, таблиц.
В них при переносе на следующую страницу дублируют головную часть. Это делается для удобства чтения таблицы на следующей странице.
При переносе таблицы указывают «продолжение таблицы №…»
Пример оформления продолжения таблицы на следующей странице с продублированной головной частью
Изображения и иллюстрации в приложении
К изображениям относятся и отсканированные документы. Сканируя готовые материалы, проверяйте, как отображаются все символы — они должны хорошо читаться.
Тоже самое касается и обычных изображений. Они должны быть в высоком разрешении и без водяных знаков.
Каждое изображение подписывают (рис.1, рис. 2). В приложении они размещаются в порядке упоминания в тексте.
Примеры оформления изображений в приложении.
Оформление приложений крупных форматов
В зависимости от дисциплины приложения оформляются не только на листах формата А4, но и больших — А3, А4*3, А1, А4*4.
Крупные форматы используются в точных дисциплинах, где необходимы чертежи, которые делают от руки или в специальных программах (например, AutoCad).
Пример оформления на листе большого формата
Приложение в оглавлении
В оглавлении раздел «Приложения» идет в конце списка, нумеруется 1 раз. Не нужно писать «Приложение 1, Приложение 2» и т. д.
Пример оформления приложения в содержании
Как сделать ссылки на приложение
Располагаются приложения в таком же порядке, в каком они упоминаются по тексту.
В тексте вынесенные в приложения материалы помечаются ссылками «См. Приложение №…».
Пример оформления ссылки на приложение в тексте
Рекомендуется составлять список приложений по ходу написания работы. Например, упомянули в тексте о проведенном анкетировании, сразу же заносите в список приложений пустой бланк анкеты и методику ее обработки (если есть). Когда работа будет закончена, по такому списку можно легко собрать все материалы для приложения.
Заключение
Приложение — не менее важная часть научной работы, чем любая другая.
Приложение состоит из материалов, которые из-за своего размера не помещаются в основной текст работы. Это могут быть изображения, таблицы, анкеты, опросники, схемы, расчеты, чертежи.
Все они должны быть хорошего качества, располагаться в соответствии с упоминанием в тексте. Из-за неправильно оформленного приложения всю работу могут не принять.
А качественно выполненное приложение показывает серьезный подход студента, глубину понимания темы, умение работать с информацией и повышает ценность всей работы. Оно может добавить пару баллов к работе или стать причиной снижения оценки.
Читайте также: