Документирование требований в RUP

Относительный путь

Абсолютный путь

Возьмем, к примеру, файл doc.html, который находится по адресу: http://somesite.ru/catalog/doc.html. На сервере, как известно, находится папка www. Как мы видим из адреса, в этой папке находится папка catalog, и уже в ней находится файл doc.html.

Если, при указывании пути к файлу, перед адресом поставить /, то это будет аналогично следующему: корневая_директория_на_севере/www/путь к файлу. То есть, http://somesite.ru/catalog/doc.html аналогично следующему: /catalog/doc.html. Итак, когда перед адресом стоит /, то это означает, что "отсчет" начинается с директории www. Теперь вместо http://localhost/index.html из любого документа можно писать /index.html. А вот что бы добраться до директории cgi надо писать так: /cgi-bin/путь к файлу.

Пути, созданные способами, описанными выше, называется абсолютными, т.к указывается абсолютный (полный) путь к файлу на сервере.

Существуют также относительные пути, которые указываются относительно самого документа, откуда идет ссылка. Например, если в doc.html создать ссылку newcat/new.html, то это подразумевает, что файл new.html находится в каталоге newcat, который, в свою очередь, находится в том же каталоге, что и файл doc.html. Как видите, этот путь указан относительно файла doc.html. Где бы этот файл не находился, путь newcat/new.html будет всегда справедлив, если файл doc.html и каталог newcat будут находиться на одном уровне (т.е. в одном каталоге).

Также относительно какого-то документа можно подняться на директорию вверх. Для этого необходимо написать../. Например, есть каталог big, в нем находятся два каталога: primary и secondary. В каталоге primary лежит, уже знакомый нам файл doc.html; а в каталоге secondary находится файл new.html. Для того, чтобы из файла doc.html сделать ссылку на файл new.html, то нужно написать../secondary/new.html. А вот если каталог big находится в каталоге www, то путь к файлу new.html можно было указать и так: /big/secondary/new.html.

Вместо заключения стоит сказать, что использование абсолютных и относительных путей значительно облегчает работу веб мастерам, будь то новичок или профессионал. Так что используйте эту возможность, как говорится, на полную катушку, и старайтесь избегать путей типа http://site.ru/catalog/file.file, или же, по крайней мере, прибегайте к их помощи как можно реже.

Шаблон SRS, предложенный в RUP ¹⁾, по сути представляет собой контейнер, в который необходимо "упаковать" артефакты, полученные в процессе специфицирования требований (см. материалы лекции 8). Кроме того, SRS частично перекликается с документом "Видение" (см. материалы лекции 7). Шаблон удобен своей компактностью и лаконизмом.

1. Введение.

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

1.2. Краткая сводка возможностей.

1.3. Определения, акронимы и сокращения.

1.4. Ссылки.

1.5. Краткое содержание.

1. Обзор системы

2.1. Обзор прецедентов. Содержит список имен и кратких описаний вариантов использования и акторов с иллюстрациями в виде диаграмм прецедентов.

2.2. Предположения и зависимости. Данная секция описывает ключевые технические возможности, компоненты, подсистемы, связанные проекты, которые могут влиять на жизнеспособность разрабатываемой системы.

Предположением (assumption) называется положение, которое считается истинным при отсутствии доказательства или определяющей информации. [1].

При определении зависимостей (dependencies) проекта от внешних факторов, необходимо проанализировать, какие новые операционные системы, регламенты бизнес-процессов, стандарты качества, информационные системы могут появиться на предприятии внедрения и как это может повлиять на функционирование изготовляемой АИС.

1. Описание требований

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

3.2. Специальные требования. Параграф содержит описание функциональных требований (не описанных в качестве вариантов использования), а также описание нефункциональных требований общего характера (не сопоставленных ни одному прецеденту в предыдущем разделе), либо ссылки на соответствующие артефакты.

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

Дата добавления: 2014-01-20