В теме 40 ответов, и 7 участников, последнее обновление сделано пользователем 
Андрей В. 13 г, 6 мес. назад.
-
Сообщения
-
Пожалуйста, покажите начинающему аналитику как вы оформляете требования к ПО.
Пока использую DOORS 8.1 т.к. прочитал книжку от Telelogic "Разработка и управление требованиями. Практическое руководство пользователя" и к нему есть руководство на русскому языке.
Если использовать мастер при создании проекта то получаю множество требований в System requirements:
1.Introduction
Purpose of the Document
Scope of the Software
Definitions Acronyms, and Abbreviations
References
Overview of the Document
2.General Description
Relation to Current Projects
Relationship to Predecessor and Successor Projects
Functions and Purpose
Environmental Considerations
Relationship to other Systems
General Constraints
Model Description
3.Specific Requirements
Functional Requirements
Performance Requirements
Interface Requirements
Operational Requirements
Resource Requirements
Verification Requirements
Acceptance Testing Requirements
Documentation Requirements
Security Requirements
Portability Requirements
Quality Requirements
Reliability Requirements
Maintainability Requirements
Safety Requirements
4.User Requirements vs. Software Requirements TraceabilityЯ думаю, что это слишком много. Хочется посмотреть как у вас выглядит конечный результат работы?
Так. Во-первых, определитесь, нужна ли вам RMS в принципе. Если вы начинающий аналитик + один таковой на проекте, то зачем? Удобство сомнительное, хотя на вкус и цвет…
Я так понял, что вы пытаетесь следовать некому процессу, описанному в книге. Попробуйте выбросить это из головы и действовать интуитивно. Очертите задачу — чего конкретно вам нужно достичь? Вам нужно: 1) очертить высокоуровневый скоуп проекта или 2) произвести детальные функциональные требования и донести до команды или 3) где-то хранить требования всех уровней в зафиксированном виде или 4) ваш вариант.. Я веду к тому, что не пытайтесь воспроизвести процесс анализа идентично какой-либо книге. Поймите, что от вас нужно на данном проекте и исходя из этого уже думайте, как этого наиболее эффективно достичь. На проекте в идеале должен быть менеджер. Спросите у него, какова конкретно ваша роль здесь (надеюсь, ответ будет не "произвести бизнес-анализ проекта
")На самом деле, этого и вправду много. Особенно, если вы только начинаете, то у вас явно глаза разбежались. Ещё один отрицательный момент: вы будете пытаться вписать что-то в быть может ненужную секцию => тратить своё время и, м.б., самостоятельно расширять список требований к системе (выдумывая их) => тратить время разработчиков и др. членов команды.
Правильней, действительно, как и говорит Герыч, определиться с постановкой задачи, и начать добавлять действительно нужные разделы (/артефакты/документы) по мере необходимости. В подавляющем большинстве проектов, которые я встречал, такие вещи как Relationship to Predecessor and Successor Projects, Performance Requirements, Operational Requirements, Resource Requirements, Verification Requirements, Documentation Requirements (это, кстати, не требования к системе), Reliability Requirements и Maintainability Requirements не используются вовсе.
Скорей всего, вам хватит Interface requirements (выраженных в макетах / вайерфреймах / скетчах и т.д.), Functional Requirements и связки между ними.Однако есть и положительная сторона того, что сгенерировал DOORS. Это задает тон (;
Благодарю за ответы, но так никто и не показал свои примеры требований к ПО
Я вот подумал и придумал.Может мне системные требования разделить на функциональные и нефункциональные?
В функциональных будут требования что должна делать система, а в нефункциональных все остальные:
Performance Requirements
Interface Requirements
Operational Requirements
Resource Requirements
Verification Requirements
Acceptance Testing Requirements
Documentation Requirements
Security Requirements
Portability Requirements
Quality Requirements
Reliability Requirements
Maintainability Requirements
Safety RequirementsУ меня в функциональных требованиях указано, что система должна строить график N. Это график расчитывается по формуле Y. Где мне указать эту формулу? В том же требовании или как? Как будет правильно? Формула нужна будет архитектору и лучше ее где то указать, а не устно передать.Повторю опять идею своего первого поста. Какая, в принципе, разница, где формулу указывать? Вы правильно поняли то, что формула не должна быть только у вас в голове. Ответьте себе на вопрос — где наиболее удобно ее будет расположить, чтобы архитектор (и другие заинтересованные лица) ее точно нашли и им было бы удобно ей пользоваться? Вот туда и кладите…
А вообще бизнес-формулы кладутся в business rules. Только вот если она используется в спеке только один раз и больше ее участие в требованиях не предвидится, то удобство в этом сомнительное.Andre, проекты, в которых для описания требований в спецификацию необходимо включать все разделы, перечисленные вами, можно пересчитать по пальцам, ибо далеко не всегда они действительно необходимы. То, что в шаблонах, которые вам встречаются, присутствуют те или иные разделы, не должно для вас быть сигналом к действию. Подумайте: а действительно ли для данного проекта вам нужно описывать, например, Portability Requirements? Спецификация должна включать необходимые и достаточные требования, избыточность — зло. Чем объемнее документ, тем сложнее его читать и понимать.Повторю опять идею своего первого поста. Какая, в принципе, разница, где формулу указывать?
Я думаю, что это важно. Лучше сразу придерживаться правильного пути, а то потом будет очень тяжело менять свой стиль.
У меня пока так:
1) Пользовательские требования
2) Системные требования, которые подразделяются на функциональные и нефункциональные.
Я пишу в функциональных:
[code]1. Система должна отображать линейные графики
1.1 График А
1.2 График Б
1.2 График В[/code]
До какой степени детализации мне описывать это требование?
[code]
1. Система должна отображать линейные графики
1.1 График А
1.1.1 Расчет по формуле А
1.1.2 Типы графиков
.....
1.1.2.1 Настройки типов графиков
1.1.2.1.1....
......
1.2 График Б
1.2 График В[/code]Вы правильно поняли то, что формула не должна быть только у вас в голове. Ответьте себе на вопрос — где наиболее удобно ее будет расположить, чтобы архитектор (и другие заинтересованные лица) ее точно нашли и им было бы удобно ей пользоваться? Вот туда и кладите…
Я хотел бы знать как принято это правильно делать. К сожалению нет сейчас время на чтение книг по требованиям. Осилил всего пару, но обязательно прочту еще и не одну, но это не сейчас. Сейчас время уходит на изучения предметной области, общение с заказчиком и фиксацию требований.
А вообще бизнес-формулы кладутся в business rules. Только вот если она используется в спеке только один раз и больше ее участие в требованиях не предвидится, то удобство в этом сомнительное.
Пока такого не использую
Andre, проекты, в которых для описания требований в спецификацию необходимо включать все разделы, перечисленные вами, можно пересчитать по пальцам, ибо далеко не всегда они действительно необходимы.
Значит я не один так думаю. Это хорошо
То, что в шаблонах, которые вам встречаются, присутствуют те или иные разделы, не должно для вас быть сигналом к действию. Подумайте: а действительно ли для данного проекта вам нужно описывать, например, Portability Requirements?
После прочтения пары книжек по требованиям и учитывая 6летний опыт в ИТ я в первый раз слышу про некоторые требования и понятия не имею что они значат
Спецификация должна включать необходимые и достаточные требования, избыточность — зло. Чем объемнее документ, тем сложнее его читать и понимать.
Благодарю. Ясно. У меня пока упор идет только на функциональные требования.
В процессе написания требования я получил две особенности:
1) В почти не пиши пользовательские требования, а пишу сразу системные которые у меня разделяются на функциональные (точнее только функциональные пишу) и нефункциональные.
2) У меня пункты уже выглядят в таком виде: «2.2.2.3.4.1.1.3». Это о чем говорит? Это ошибка? Слишком уж сложное дерево получается, да?Пока не чувствую до какой степени детализации надо описывать функциональные требования.
2. Системы должны отображаться таблица
2.1 Таблица «очень важная»
2.1.1 Название заголовка таблицы должна быть «очень важная»
2.1.1 Столбцы такие
2.1.2 Строки такие
2.1.3 Подсветка строк такая то
2.1.4 Настройка подсветки
2.1.5. Сортировка значений в колонках
2.1.6. Сортировка строк таблицы
2.1.7. Сортировка колонок таблицыФункциональные требования
3. Система должна проводить операцию xЭто операция непростая. Я для нее нарисовал блок-схему. Куда мне этe схему вставить? В само требование или в отдельное приложение?
На мой взгляд, в спецификации должны присутствовать все перечисленные в первом сообщении разделы. Но не все они должны быть описаны. Т.е. если заказчик не выдвигает требований какого-либо вида, то в данном разделе я обычно пишу, например: «Заказчик не выдвинул требований к документации». В данном случае я, менеджер и контора прикрыты, если заказчик на этапе сдачи-приемки системы начнет придумывать требования или вставать с позу «Вы меня не спрашивали про это, я думал это само собой разумеющиеся требования и т.п.».На самом деле, этого и вправду много. Особенно, если вы только начинаете, то у вас явно глаза разбежались. Ещё один отрицательный момент: вы будете пытаться вписать что-то в быть может ненужную секцию => тратить своё время и, м.б., самостоятельно расширять список требований к системе (выдумывая их) => тратить время разработчиков и др. членов команды.
Правильней, действительно, как и говорит Герыч, определиться с постановкой задачи, и начать добавлять действительно нужные разделы (/артефакты/документы) по мере необходимости. В подавляющем большинстве проектов, которые я встречал, такие вещи как Relationship to Predecessor and Successor Projects, Performance Requirements, Operational Requirements, Resource Requirements, Verification Requirements, Documentation Requirements (это, кстати, не требования к системе), Reliability Requirements и Maintainability Requirements не используются вовсе.
Скорей всего, вам хватит Interface requirements (выраженных в макетах / вайерфреймах / скетчах и т.д.), Functional Requirements и связки между ними.Однако есть и положительная сторона того, что сгенерировал DOORS. Это задает тон (;
Естественно требования самостоятельно выдумывать не нужно
. Но, насчет добавления нужных разделов по мере появления требований я не согласна. Так можно поступать, когда есть опыт и четкое представление, какие требования вообще бывают. В начале лучше, ИМХО, удалять (т.е. писать, что таких-то и таких-то требований не поступило).
И насчет видов требований, которые неиспользуются, я бы тоже поспорила
. Все зависит от вида системы, специфики заказчика/вендора и т.д. Documentation Requirements – очень даже требования к системе, если в системе есть встроенная справочная служба.Благодарю за ответы, но так никто и не показал свои примеры требований к ПО
Спеки, все так не код. Они часто очень специфичны для каждого заказчика и почти все заказчики требуют не распространения документации. Посмотрите выложенные на форме темплейты спек. Возможно, станет понятнее.
Я думаю, что это важно. Лучше сразу придерживаться правильного пути, а то потом будет очень тяжело менять свой стиль.
У меня пока так:
1) Пользовательские требования
2) Системные требования, которые подразделяются на функциональные и нефункциональные.Из моего опыта, каждый новый проект — новый подход/стиль, т.к. начальные условия везде разные (новый заказчик, новый вид системы, новый менеджер, разные сроки и бюджеты и т.п.). Например, под десктопное приложение я буду писать спеку с одной структурой, под кастомный сайт с другой, под сайт на liferay с третьей, а под сайт на SharePoint с 4-ой. Общая структура будет одна, но наполнение, а иногда даже термины (например, для десктопа я буду описывать "формы", а для сайтов "страницы"), разные.
То, что Вы не пишите пользовательские требования не очень хорошо. Для кого система создается? Кто ей будет пользоваться? Как и кто ее будет принимать?
У Вас получается такое дерево, что требования не сгруппированы правильно. Спеки вида "Система должна быть такой, а потом такой и еще такой" в конечном итоге получаются нечитабильными.
Я использую несколько подходов в группировке требований:
-От интерфейса, если система простая типа информационного сайта.
-По модулям. В модули объединяю подобные друг на друга функции (типа "бухгалтерсикий учет", "учет данных сотрудников" и т.п.).
-По классам пользователей, если у пользователей различный функции в системе.Функциональные требования
3. Система должна проводить операцию xЭто операция непростая. Я для нее нарисовал блок-схему. Куда мне этe схему вставить? В само требование или в отдельное приложение?
На мой взгляд, не совсем правильная формулировка требования. Система редко что сама проводит. Чаще всего все взаимодействия происходят между пользователем и системой, и пользователь является причиной операции. Если же это случай когда система совершает действие по расписанию, а не реагирует на действие пользователя, то это все равно должен быть отсдельный сценарий, испольнителем которого выступает система.
Вообщем, предлагаю, попобробовать писать сценарии использование (прецеденты, use cases).
Ваша блок схема вполне может оказаться сценарием использования и быть частью пользовательских требований.На мой взгляд, в спецификации должны присутствовать все перечисленные в первом сообщении разделы.
А что они значат?
Можете провести краткий ликбез к каждому указанному требованию?
Ранее я не думал, что системные требования включают все указанные выше.
Прочитаю, обдумаю отвечу в понедельник.
Вы должны авторизироваться для ответа в этой теме.
