Всё просто: нормальным русским языком описывайте нужные функции в формате сценария использования.
Сценарий проще всего описывать в по схеме: [роль пользователя] может [действие], [описание целей пользователя, а также необходимых шагов и вариантов развития событий]. Оптимально — разбивать описание больших компонентов на маленькие составляющие.
В конечном итоге, пункты ТЗ должны быть объективными, просто изложенными и элементарным способом проверяемыми требованиями.
Например, вполне адекватные функциональные требования в формате сценария:
Гость должен иметь возможность зарегистрироваться на сайте, путем заполнения формы регистрации (обязательно указав своё имя, адрес электронной почты и желаемый пароль). Также гость, при наличии у него учётной записи, должен иметь возможность войти на сайт, указав в соответствующей форме свой адрес электронной почты и пароль. Это нужно для того, чтобы у него была возможность выполнять действия, требующие наличия учетной записи (например, покупать товары в интернет-магазине или оставлять комментарии).
Техническое задание на проектирование. Как правильно написать?
Каждый аутентифицированный (вошедший на сайт) пользователь должен иметь возможность выйти из системы, например, чтобы исключить осуществление дальнейших действий на сайте от своего имени другими пользователями компьютера.
Примеры некорректных требований ТЗ
Субъективные требования — это все требования с оценочными прилагательными типа удобный, красивый, простой и тому подобными. Они некорректны для ТЗ, так как их никак нельзя проверить, а значит принять работу, основываясь на таких критериях просто не получится:
Непонятно изложенные требования — это еще один пример того, что не должно попадать в ТЗ. Такие требования формулируются так, что нельзя без должной подготовки понять о чём вообще идёт речь, например:
Пользователь должен иметь возможность реструктуризировать компоненты своего аккаунта путём декомпозиции отдельных сущностей на произвольно задаваемое число взаимно зависимых компонентов.
Субъективные требования чаще всего формулирует бизнес и маркетинг, а непонятно изложенные — ИТ и другие технические специалисты. И с тем, и с другим надо бороться, так как ТЗ должно быть руководством к действию и чек-листом, по которому можно проверить выполненную работу. А некорректные требования приводят к тому, что ТЗ для этого не может быть использовано, и не очень понятно зачем его было вообще писать, если никто им не пользуется.
Примеры корректных требований ТЗ
Еще примеры нормальных функциональных требований:
Гость на каждой странице может войти на сайт. По нажатию кнопки «войти» открывается форма для ввода логина и пароля. При корректном вводе логина и пароля пользователь входит на сайт и ему выводится уведомление об этом, дальше он работает с сайтом как аутентифицированный пользователь и ему становятся доступны дополнительные возможности. При некорректном вводе логина и/или пароля отображается уведомление о произошедшем и пользователю предлагается повторно заполнить форму
Клецкова Ю.С. Подготовка ТЗ на проектирование объекта капитального строительства с применением ТИМ.
Зарегистрированный пользователь при посещении сайта должен видеть персональное приветствие «Здравствуйте, [Имя] [Отчество]!» и ссылку для выхода с сайта. При нажатии на своё имя пользователь попадает в личный кабинет, при нажатии на ссылку «выход» — выходит из системы и дальше работает с сайтом как гость.
Администратор может удалить страницу сайта. В списке страниц напротив каждой страницы есть кнопка для удалени, по нажатию на эту кнопку выводится диалог подтверждения удаления. При подтверждении страница удаляется, а при отказе — удаления не происходит.
Как правило, функциональные требования развиваются: уточняются и конкретизируются как в процессе согласования, так и в процессе разработки.
Например, описание процедуры регистрации в конечном итоге может выглядеть так:
Гость должен иметь возможность зарегистрироваться на сайте. Для этого он может с любой страницы сайта по ссылке «зарегистрироваться» перейти на страницу с формой регистрации.
Форма регистрации содержит поля: Фамилия, Имя, Адрес электронной почты, Пароль и его Подтверждение, а также флаг согласия с публичной офертой. Все поля являются обязательными для заполнения. Адрес электронной почты должен быть корректным адресом e-mail, Пароль должен быть не короче 6 символов и содержать буквы и цифры, Пароль и Подтверждение должны совпадать, флаг согласия с публичной офертой должен быть установлен. При некорректном заполнении формы выводится список ошибок при заполнении формы, а поля с ошибками подсвечиваются.
Корректно заполнив и отправив форму регистрации гость создаёт новую учётную запись, а ему на указанный адрес электронной почты отправляется письмо с уведомлением о регистрации и со ссылкой для активаци аккаунта. Для активации аккаункта пользователь должен перейти по полученной ссылке, после чего он будет автоматически аутентифицирован (войдёт на сайт).
Если пользователь не получил ссылку для активации, то он может запросить её повторную отправку, просто указав свой адрес электронной почты, в этом случае ему должно быть также выведено сообщение с рекомендацией поискать письмо в спаме.
Вход при помощи формы входа до активации учётной записи невозможен, в случае попытки входа или регистрации с реквизитами доступа неактивной учетной записи пользователю должно быть выведено уведомление о том, что учетная запись неактивна, а также предложение повторно отправить письмо со ссылкой для активации аккаунта.
Если пользователь не активирует свою учётную запись в течение одной недели, то она будет удалена из базы данных.
В случае перехода по ссылке «зарегистрироваться» уже зарегистрированным и аутентифицированным пользователем форма регистрации не должна показываться, а должна быть осуществлена переадресация на страницу профиля текущего пользователя с уведомлением: «Вы уже зарегистрированы и уже вошли на сайт».
Такая подробная спецификация пусть и не очень проста в написании, но зато достаточно точно описывает требования к итоговой логике работы компонента, что позволяет без проблем провести сдачу-приёмку выполненных работ.
Разумеется, что в написании любой спецификации рационально соблюдать баланс между полнотой / детализированностью требований и простотой понимания / написания самого ТЗ.
Избыточная детализация времязатратна и делает ТЗ перегруженным очевидными деталями, но недостаточная детализация приводит к тому, что какие-то важные требования не будут описаны и могут не быть реализованы. Задача бизнес-аналитика, составляющего ТЗ, как раз и заключается в том, чтобы найти баланс между полнотой изложения и лаконичностью.
Уровень необходимой детализации ТЗ обычно зависит от компетентности специалистов и от корпоративной культуры. Профессионалам можно ставить высокоуровневые задачи и они их решат адекватным способом, а начинающим специалистам лучше более полно детализировать задачи, декомпозировать их и формулировать критерии приёмки. С корпоративной культурой всё несколько сложнее, например: чёткое следование регламентам и формализация — это отличный фактор для процессной деятельности, но в проектной / продуктовой разработке это несколько замедляет работу, так как требует более формальной и детализированной постановки задач.
Функциональное техническое задание — более простой и понятный способ описания требований, нежели классическое ТЗ.
Источник: web-creator.ru
1. Введение
Программа автоматизации учета об улицах, домах, квартирах, квартиросъёмщиках.
1.2. Краткая характеристика области применения программы
Система предназначена для поиска, хранения, обработки сведений об улицах, домах, квартирах, квартиросъёмщиках.
2. Основание для разработки
2.1. Основание для проведения разработки
Основанием для проведения разработки является лабораторная работа по дисциплине “Проектирование информационных систем”.
2.2. Наименование и условное обозначение темы разработки
Наименование – “Система автоматизации учета об улицах, домах, квартирах, квартиросъёмщиках”.
Условное обозначение – “Автоматизация учета об улицах, домах, квартирах, квартиросъёмщиках”.
3. Назначение разработки
3.1. Функциональное назначение программы
Функциональным назначением программы является представление информации об улицах (название, район), домах (номер, этажность, количество подъездов и квартир), квартирах (серия, метраж, количество комнат, количество квартиросъёмщиков), квартиросъёмщиках (паспортные данные)
3.2. Эксплуатационное назначение программы
Программа должна использоваться в ЖЭКах города для предоставления необходимой информации.
Конечными пользователями программы могут являться как сотрудники ЖЭКа (полное право доступа к информации), так и лица, не имеющие отношения к ЖЭКу (частичное предоставление информации).
4. Требования к программе
4.1. Требования к функциональным характеристикам
4.1.1. Требования к составу выполняемых функций
Программа должна обеспечивать возможность выполнения перечисленных ниже функций:
· Учет улиц, домов, квартир, квартиросъёмщиков
· Данные о состоянии улиц, домов, квартир
· Сведения о квартиросъёмщиках
· Автоматизированный поиск необходимой информации
· Защита базы данных от несанкционированного доступа к данным.
4.1.2. Требования к организации входных данных
Входные данные программы должны быть организованы в виде вводимого в специальную форму текста или файла, соответствующего определенному шаблону. Данные, вводимые вручную, проверяются на корректность после попытки сохранения; данные, вводимые из файла, проверяются в ходе анализа и размещения данных.
Файлы указанного формата должны размещаться (храниться) на локальных или съемных носителях, отформатированных согласно требованиям операционной системы. Каждый день происходит резервирование полученной информации на отдельный носитель, для возможности восстановления информации в случае ошибки программы или поломки оборудования.
4.1.3. Требования к организации выходных данных
Выходные данные программы должны быть организованы в виде отчетов или таблиц. Отчеты делятся на несколько групп по предназначению определенной группе пользователей. Доступ к таблицам зависит и от принадлежности пользователя к определенной группе пользователя с теми или иными правами.
Файлы указанного формата должны храниться на локальных или съемных носителях, отформатированных согласно требованиям операционной системы. Отчеты формируются в режиме реального времени и передаются пользователю. Отчеты, являются временными и стираются по завершению работы программы, могут быть сформированы заново при следующем запуске компьютера. При желании любой отчет можно сохранить отдельно.
4.1.4. Требования к временным характеристикам
Требования к временным характеристикам зависит от выполняемой задачи. При формировании отчета временные рамки увеличиваются пропорционально обрабатываемым данным.
4.2. Требования к надежности
4.2.1. Требования к обеспечению надежного (устойчивого) функционирования программы
Надежное (устойчивое) функционирование программы должно быть обеспечено выполнением совокупности организационно-технических мероприятий, перечень которых приведен ниже:
1) организацией бесперебойного питания технических средств;
2) выполнением рекомендаций Министерства труда и социального
развития РФ, изложенных в Постановлении от 23 июля 1998 г. «Об утверждении
межотраслевых типовых норм времени на работы по сервисному обслуживанию
ПЭВМ и оргтехники и сопровождению программных средств»;
3) выполнением требований ГОСТ 51188-98. Защита информации.
Испытания программных средств на наличие компьютерных вирусов;
4) необходимым уровнем квалификации сотрудников профильных подразделений.
4.2.2. Время восстановления после отказа
Время восстановления после отказа, вызванного сбоем электропитания технических средств (иными внешними факторами), не фатальным сбоем (не крахом) операционной системы, не должно превышать времени, необходимого на перезагрузку операционной системы и запуск программы, при условии соблюдения условий эксплуатации технических и программных средств.
Время восстановления после отказа, вызванного неисправностью технических средств, фатальным сбоем (крахом) операционной системы, не должно превышать времени, требуемого на устранение неисправностей технических средств и переустановки программных средств.
Обеспечивается копиями (обеспечивается программой) необходимой информации и хранении дистрибутивов на отдельном компьютере (обеспечивается стороной-заказчиком).
4.2.3. Отказы из-за некорректных действий оператора
Отказы программы возможны вследствие некорректных действий оператора (пользователя) при взаимодействии с операционной системой. Во избежание возникновения отказов программы по указанной выше причине следует обеспечить работу конечного пользователя без предоставления ему административных привилегий.
4.3.Условия эксплуатации
4.3.1. Климатические условия эксплуатации
Климатические условия эксплуатации, при которых должны обеспечиваться заданные характеристики, должны удовлетворять требованиям, предъявляемым к техническим средствам в части условий их эксплуатации.
4.3.2. Требования к видам обслуживания
См. Требования к обеспечению надежного (устойчивого) функционирования программы.
4.3.3. Требования к численности и квалификации персонала
Минимальное количество персонала, требуемого для работы программы, должно составлять не менее 2 штатных единиц — системный программист и конечный пользователь программы — оператор.
Системный программист должен иметь техническое образование. В перечень задач, выполняемых системным программистом, должны входить:
1) задача поддержания работоспособности технических средств;
2) задачи установки (инсталляции) и поддержания работоспособности системных программных средств — операционной системы;
3) задача установки (инсталляции) программы.
4.4. Требования к составу и параметрам технических средств
В состав технических средств должен входить персональный компьютер. В случае работы системы в сети все компьютеры должны быть подобны. Так же необходимы кабеля для создания сети, сетевые карты на каждом компьютере и маршрутизатор. При предоставлении возможности поступления информации через сеть Интернет, один из компьютеров в сети, не являющийся сервером, должен иметь модем.
4.5. Требования к информационной и программной совместимости
4.5.1. Требования к информационным структурам и методам решения
Пользовательский интерфейс должен быть интуитивно понятным и содержать подсказки. Должен существовать программный доступ из пользовательского интерфейса к созданию копий базы данных в XML формате. Отчеты должны содержать лишь интересующую информацию. Программа-анализатор должна выполнять запрос за наименее короткое время.
4.5.2. Требования к исходным кодам и языкам программирования
Исходные коды программы должны быть реализованы на любом языке (… C #). В качестве интегрированной среды разработки программы должна быть использована среда Microsoft Visual Studio 2005(локализованная, русская версия). Взаимодействие с СУБД и создание базы данных реализуется на языке SQL .
4.5.3. Требования к программным средствам, используемым программой
Системные программные средства, используемые программой, должны быть представлены локализованной версией операционной системы Windows .
Основой для системы должна стать база данных, в которой будет храниться вся информация.
База данных должна включать в себя следующие таблицы:
Таблица “Улицы” должна включать в себя следующие поля:
Таблица “Дома” должна включать в себя следующие поля:
Таблица “Квартиры” должна включать в себя следующие поля:
— Данные на владельца квартиры
— Количество жильцов в квартире
Таблица “Квартиросъёмщики” должна включать в себя следующие поля:
Подсистема администрирования.
Подсистема администрирования предназначена для управления настроек системы. Управление осуществляется администратором. Управление должно учитывать настройку следующих параметров:
— регистрация групп пользователей,
— регистрация пользователей (с настройкой пароля),
— предоставление различных прав различным группам пользователей,
— настройка параметров источника базы данных,
Для удобства администрирования данная подсистема должна иметь свой интерфейс (где видны все настройки и графы), который предоставляется пользователю в том случае, если последний идентифицирован как администратор. Интерфейс должен иметь инструменты настройки вышеперечисленных параметров, а так же модули ввода, обработки и поиска информации.
Подсистемы учета.
Данные подсистемы должны содержать следующие модули:
— модуль ввода информации,
— модуль поиска информации (по заданным параметрам),
— модуль создания отчетов.
Модуль ввода информации для подсистем учета.
Данный модуль должен осуществлять внесения новых данных в базы, так же модуль должен выполнять следующие функции:
— обеспечение удобный ввод, соответствующий подсистеме данных,
— улучшение качество ввода за счет ограничений на значение, типизированные форматы данных, значения по умолчанию, списки выбора значения, и т.п.,
— обеспечение ввода критериев поиска из списка имеющихся параметров,
— обеспечение ввода информации из файлов.
Модуль поиска информации для подсистем учета.
Модули поиска информации всех подсистем учета должны обеспечивать выборку информации из базы данных по заданным критериям и выполнять следующие функции:
— обеспечение задания критериев поиска,
— создание запросов по заданным критериям поиска.
— обеспечение удобного предоставления найденной информации для пользователя.
Модуль создания отчетов.
— данный модуль должен обеспечивать выборку информации по заданным параметрам и выполнять следующие функции:
— создание соответственного электронного файла-документа с отчетом
— вывод документа на печать
— возможность рассылки данного документа на почту или на другой компьютер в сети.
4.5.4. Требования к защите информации и программ
В Системе должен быть обеспечен надлежащий уровень защиты информации в соответствии с законом о защите персональной информации и программного комплекса в целом от несанкционированного доступа — “ Об информации, информатизации и защите информации” РФ N 24-ФЗ от 20.02.95.
4.6. Специальные требования
Программа должна обеспечивать взаимодействие с пользователем (оператором) посредством графического пользовательского интерфейса, разработанного согласно рекомендациям компании-производителя операционной системы. Программа должна обеспечивать высокую защиту данных и удобный и быстрый просмотр необходимой информации посредством отчетов.
5. Требования к программной документации
5.1. Предварительный состав программной документации
Состав программной документации должен включать в себя:
1) техническое задание;
3) текст программы ;
4) описание программы ;
5) программу и методики испытаний;
6) пояснительная записка ;
7) ведомость эксплуатационных документов;
9) описание применения;
10) руководство системного программиста;
11) руководство программиста;
12) руководство оператора;
6. Стадии и этапы разработки
6.1. Стадии разработки
Разработка должна быть проведена в три стадии:
1) разработка технического задания;
2) рабочее проектирование;
6.2. Этапы разработки
На стадии разработки технического задания должен быть выполнен этап разработки, согласования и утверждения настоящего технического задания.
На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ:
1) разработка программы;
2) разработка программной документации;
3) испытания программы.
На стадии внедрения должен быть выполнен этап разработки — подготовка и передача программы.
6.3. Содержание работ по этапам
На этапе разработки технического задания должны быть выполнены перечисленные ниже работы:
1) определение и уточнение требований к техническим средствам;
2) определение требований к программе;
3) определение стадий, этапов и сроков разработки программы и документации на неё;
4) выбор языков программирования;
5) согласование и утверждение технического задания;
На этапе разработки программы должна быть выполнена работа по программированию и отладке программы.
На этапе разработки программной документации должна быть выполнена разработка программных документов в соответствии с требованиями ГОСТ 19.101-77 и требованием п. « Предварительный состав программной документации» настоящего технического задания.
На этапе испытаний программы должны быть выполнены перечисленные ниже виды работ:
1) разработка, согласование и утверждение программы и методики испытаний;
2) проведение приемо-сдаточных испытаний;
3) корректировка программы и программной документации по результатам испытаний.
На этапе подготовки и передачи программы должна быть выполнена работа по подготовке и передаче программы и программной документации в эксплуатацию .
Источник: npu11.narod.ru