Практическая работа №3. Составление спецификации.

Практическая работа № 3 «Составление спецификации».

Тема занятия: Составление спецификации ПО (Software Requirement Specification – SRS).

Цель выполнения задания: научиться создавать и редактировать спецификацию для ПО.

Оборудование (приборы, материалы, дидактическое обеспечение) Инструкционные карты, мультимедийные презентации, персональные компьютеры.

ОСНОВНЫЕ ТЕОРЕТИЧЕСКИЕ ПОЛОЖЕНИЯ

Что такое Спецификация требований ПО (Software Requirement Specification – SRS).

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

Для чего нужна Спецификация.

• Можно получить точную оценку стоимости, рисков и затрат времени

• Клиент сможет более четко сформировать собственное видение проекта

• Заказчик и Исполнитель будут иметь одинаковое представление о продукте

• Она поможет выявить оптимальный набор функций

• Она служит основой для формирования другой технической документации

• Процесс разработки будет оптимизирован — минимизированы затраты времени

• Никакого дублирования задач

• Позволяет структурировать проблемы, чтобы решать их проще и быстрей

• Она помогает понять, какие результаты считаются оптимальными при тестировании.

Проблемы, возникающие при разработке проекта без спецификации

• Невозможно будет получить точную оценку стоимости, рисков и затрат времени

• Заказчик и Исполнитель могут иметь абсолютно разное представление о продукте

• Разработчики не смогут быть уверены, что создаваемое  ими программное обеспечение полностью соответствует требованиям заказчика

• Будет очень сложно написать руководство для пользователей

• Велика вероятность того, что потребуется переделывать части проекта заново.

Методология составления спецификации.

Шаг 1: Исходная документация

Наш менеджер проектов связывается с клиентом и запрашивает у него всю имеющуюся о проекте информацию, а затем передает ее аналитику. Эти данные могут включать написанную ранее Спецификацию, пользовательские сценарии или просто текстовое описание программного обеспечения. Аналитик может задать заказчику уточняющие вопросы, ведь основная задача на этом этапе – сформировать четкое понимание видения клиента и его требований к системе.

Шаг 2: Первичная Спецификация

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

Обычно спецификация содержит следующие разделы:

1. Введение. Обзор содержимого спецификации.

1.1 Цели. Здесь содержится детальная информация о целях, которые должны быть достигнуты при помощи разрабатываемого продукта.

1.2 Масштаб проекта — описание того, что приложение должно или не должно делать.

1.3 Определения, сокращения и аббревиатуры. В этой главе содержатся пояснения для всех специфических терминов, чтобы все в документе было понятным.

1.4 Организационное построение спецификации.

2. Общее описание.

В этой части основное внимание уделяется факторам, определяющим параметры продукта и требования к нему. Здесь вы не найдете четкого описания требований, оно будет приведено в части 3. Данная глава призвана помочь лучше понять эти требования.

2.1 Обзор продукта. Основной фокус — на взаимосвязи продукта с другими продуктами или проектами: будет ли он независимым или станет частью более крупной системы.

2.2 Функции продукта — просто и ясно составленное краткое изложение функционала.

2.3 Характеристика пользователей. Рисует портрет будущей аудитории и то, как эти данные влияют на требования к программному обеспечению.

2.4 Общие ограничения содержат информацию о рамках и стандартах, которые ограничивают опции разработчика при создании системы.

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

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

3.2 Нефункциональные требования, в свою очередь, определяют критерии для оценки важных параметров работы системы, таких как: производительность, сохранность данных и безопасность.

4. Специальные требования

4.1 Схема информационных потоков отображает входные и выходные данные, их источники, пункты назначения и хранения.

4.2 Диаграмма пользовательских сценариев. Основное ее назначение – продемонстрировать то, как объекты будут взаимодействовать с программным обеспечением и выделить основной функционал.

5. Модели (Mockups). Еще один отличный способ начать работу над проектом. Они помогут сформировать представление о базовой структуре и пользовательском интерфейсе.

Шаг 3: Ознакомление клиента со спецификацией

Документ передается клиенту. Ознакомившись с содержанием, он сможет сформировать целостную картину и определиться с деталями. Имеющаяся версия спецификация либо будет одобрена, либо отправлена на доработку.

Шаг 4: Уточнение

В Спецификацию будут вноситься модификации до тех пор, пока она не будет полностью соответствовать всем требованиям заказчика.

Шаг 5. Pазбивка на этапы

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