4726

Системный Анализ и Требования / Re: Управление требованиями

« : 14 Ноября 2007, 18:55:11 »

Вы говорите об "управлении требованиями" как о втором уровне зрелости CMMI (вон каких я умных слов нахватался ), когда предполагается, что требования разработаны заказчиком. Но пример, похоже, не соответствует этому условию - первые требования появляются из общей концепции системы, которую мы пропустили (или только я пропустил?) Эти начальные требования отсутствуют - значит, либо нужно их тоже перечислить (смоделировав второй уровень), либо разработать самостоятельно, выявив реальные потребности заказчика (третий уровень).
Обе задачи, наверное, могут использоваться как учебные.

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

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

4727

Системный Анализ и Требования / Re: Управление требованиями

« : 14 Ноября 2007, 18:49:44 »

а черновую работу по занесению и отслеживанию актуальности данных по требованиям переложить на Эдуарда в роли своего помощника.

Окей окей, я уже тружусь в поте лица. Однако как мы будем обмениваться информацией хотя бы. Есть ли у коллег RaQuest в каком-либо виде?

Или я пока требования фиксирую скажем в Excel? И выкладываю.

С чем сразу нужно определиться?
1. типы требований (по-русски | по-ангельски)
2. статусы требований (аналогично)
3. приоритеты требований (аналогично)
4. риски (аналогично)
5. сложность (аналогично)
6. стабильность (аналогично)
7. дополнительные атрибуты по требованиям?
8. формировать ли требования по группам с соотвествующей нумерацией внутри группы или делать сквозную нумерацию без префикса группы, а группировать через тип требования

4728

Сообщество Аналитиков / Re: Нужны добровольцы для структурирования файлового архива

« : 14 Ноября 2007, 15:22:47 »

Появилась литература электронная, как оформлять, кому сдавать нонеча?

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

4729

Системный Анализ и Требования / Re: Управление требованиями

« : 14 Ноября 2007, 15:20:29 »

Огромное сорри!
>общаца и торопица
это только в плане стёба над спецификой общения с ТОПами,
и только в пределах одного пОста,
в личном плане - ничего подобного и в мыслях не было,
да и по отношению к себе не люблю.

Это Вы что, типа обиделись?

4730

Системный Анализ и Требования / Re: Управление требованиями

« : 14 Ноября 2007, 15:18:40 »

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

Ага, теперь понятно, было что-то в подсознании из опыта использования интернет-карт

4731

Системный Анализ и Требования / Re: Управление требованиями

« : 14 Ноября 2007, 15:00:39 »

Да - а что такое срэтч-карта (простите за наивность)

4732

Системный Анализ и Требования / Re: Управление требованиями

« : 14 Ноября 2007, 14:59:50 »

Gevorg давайте (а может на ты, проще общаца) не будем торопица.

Еще не все ладно с классификацией, тем более нужно сразу сконфигурировать хранилище, которое я буду делать в RaQuest.

Я уже начал его формировать и сделал структуру: Бизнес-требования, Пользовательские требования, Функциональные требования

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

Пока у меня не все получилось - куда что пораскидать, также возникла проблема с названием каждого требования, пока делаю просто - из каждого описания выделяю ключевую фразу и делаю ее заголовком, а всё предложение помещаю в описание требования. Нужно еще разместить статусы и назначить атрибуты. Пока использую что есть по умолчанию

То есть требование Система должна обеспечивать учёт скрэтч-карт превращается в Обеспечить учет срэтч-карт с описанием Система должна обеспечивать учёт скрэтч-карт.

Далее что с нумерацией? придерживаться предложенной Вами? или разрешить автонумерацию?

Потом я включу Ваши указания по требованиям

4733

Системный Анализ и Требования / Re: Управление требованиями

« : 13 Ноября 2007, 22:23:21 »

Вот так всегда. Начинаешься кучу книг, кажется, все знаешь. Но стоит столкнуться с реальной задачей и пасуешь.

Однако на ум приходит фраза из детства. Был такой журнал. Что-то типа:
"Орешек знаний тверд. Но расколоть его поможет киножурнал 'Хочу все знать'"

Так что попытка №2. Классификация

Скажем так нужды
3. Необходимо использование БАР-кодов для номеров скретч-карт.
4. Необходимо использование БАР-кодов для секретных кодов скретч-карт.
5. Необходимо применять EAN-систему бар-кодирования, поскольку это является корпоративным стандартом.
11. Необходимо применять EAN-систему бар-кодирования, поскольку имеющееся в компании оборудование поддерживает только этот стандарт.
12. Необходима интеграция с внешними системами считывания бар-кодов.
13. Необходима интеграция с переносной системой считывания бар-кодов компании Х.


Системные требования
1. Система должна обеспечивать учёт скрэтч-карт.
2. Система должна поддерживать интеграцию с Клиент-Банком.
6. Система должна позволять регистрировать набор номеров скрэтч-карт путём ввода начального и конечного значения диапазона номеров.
7. Система должна давать возможность вводить номера карт, которые попадают в диапазон номеров для регистрации, но которые являются исключением, и регистрации не подлежат.
8. Регистрация в Системе прихода средств на счёт компании должна выполняться на основании информации из банка.
9. Регистрация в Системе прихода средств на счёт компании должна выполняться на основании телефонного звонка от финансового директора.
10. Система должна обеспечивать отчётность о текущем состоянии счёта компании.
14. Система должна обеспечивать отчётность об истории прихода денег на счёт компании.
15. Система должна обеспечивать отчётность только по тем приходам, которые были зарегистрированы по звонку от финдиректора.

Продолжим издевательства над требованиями:

3. Необходимо использование БАР-кодов для номеров скретч-карт.
4. Необходимо использование БАР-кодов для секретных кодов скретч-карт.

5. Необходимо применять EAN-систему бар-кодирования, поскольку это является корпоративным стандартом.
    11. Необходимо применять EAN-систему бар-кодирования, поскольку имеющееся в
         компании оборудование поддерживает только этот стандарт.
{хотя неочень четко понимаю разницу - и это как-то ближе к бизнес-правилу, по карйней мере что касается требования 5}

12. Необходима интеграция с внешними системами считывания бар-кодов.
      13. Необходима интеграция с переносной системой считывания бар-кодов компании Х.



1. Система должна обеспечивать учёт скрэтч-карт.
    6. Система должна позволять регистрировать набор номеров скрэтч-карт путём ввода начального и конечного значения диапазона номеров.
    7. Система должна давать возможность вводить номера карт, которые попадают в диапазон номеров для регистрации, но которые являются исключением, и регистрации не подлежат.


8. Регистрация в Системе прихода средств на счёт компании должна выполняться на основании информации из банка.
    2. Система должна поддерживать интеграцию с Клиент-Банком.

9. Регистрация в Системе прихода средств на счёт компании должна выполняться на основании телефонного звонка от финансового директора.

10. Система должна обеспечивать отчётность о текущем состоянии счёта компании.
14. Система должна обеспечивать отчётность об истории прихода денег на счёт компании.
15. Система должна обеспечивать отчётность только по тем приходам, которые были зарегистрированы по звонку от финдиректора.

4734

Системный Анализ и Требования / Re: Управление требованиями

« : 13 Ноября 2007, 20:42:43 »

Что-то туго у меня с классификацией.

Потому пока вот такой расклад. Я не учитель, я ученик в требованиях

1.   Работа со скрэтч-картами
   a.   Система должна обеспечивать учёт скрэтч-карт.
   b.   Система должна поддерживать интеграцию с Клиент-Банком.
   c.   Необходимо применять EAN-систему бар-кодирования, поскольку это является корпоративным стандартом.
       i.   Необходимо применять EAN-систему бар-кодирования, поскольку имеющееся в компании оборудование поддерживает только этот стандарт.
       ii.   Необходимо использование БАР-кодов для номеров скретч-карт.
       iii.   Необходимо использование БАР-кодов для секретных кодов скретч-карт.
       iv.   Необходима интеграция с внешними системами считывания бар-кодов.
       v.   Необходима интеграция с переносной системой считывания бар-кодов компании Х.
   d.   Система должна позволять регистрировать набор номеров скрэтч-карт путём ввода начального и конечного значения диапазона номеров.
       i.   Система должна давать возможность вводить номера карт, которые попадают в диапазон номеров для регистрации, но которые являются исключением, и регистрации не подлежат.

2.   Приход средств
   a.   Регистрация в Системе прихода средств на счёт компании должна выполняться на основании информации из банка.
   b.   Регистрация в Системе прихода средств на счёт компании должна выполняться на основании телефонного звонка от финансового директора.

3.   Отчетность по счету
   a.   Система должна обеспечивать отчётность о текущем состоянии счёта компании.
   b.   Система должна обеспечивать отчётность об истории прихода денег на счёт компании.
   c.   Система должна обеспечивать отчётность только по тем приходам, которые были зарегистрированы по звонку от финдиректора.

Несовсем понял из задания. Нужно ли самому придумать, если нет, но подразумеваются: бизнес требования, требования пользователей? Или нужно действовать в жестких рамках предложеного списка, не добавляя и не убавляя

4735

Системный Анализ и Требования / Re: Управление требованиями

« : 13 Ноября 2007, 20:17:35 »

7. Система должна давать возможность вводить номера карт, которые попадают в диапазон номеров для регистрации, но которые являются исключением, и регистрации не подлежат.

Неясное требование. Что же должна делать система? Отлавливать карты с разрешенным диапазоном кодов, но какие-то бракованные?

4736

Системный Анализ и Требования / Re: Управление требованиями

« : 13 Ноября 2007, 18:31:33 »

система статусов и групповая работа, в т.ч. и обсуждения имхо спасут и тебя, и отца русской демократии.

Стоп стоп стоп. Ты хочешь сказать, что в RaQueste есть нечто под понятием раздача задач и поручений? Или это просто смена статуса ПМ?

4737

Sparx / Re: Enterprise Architect: Практика использования

« : 13 Ноября 2007, 18:28:51 »

Спасибо участникам обсуждений, FAQ обновлен до текущего состояния ветки обсуждения.

+5

4738

Системный Анализ и Требования / Обсуждение статьи: CMMI — шаг в будущее: разработка требований

« : 13 Ноября 2007, 18:27:44 »

Хотелось бы получить критику или разъяснение статьи CMMI — шаг в будущее: разработка требований

Цитата1.
Требования клиента могут быть выражены в его собственных терминах и представлять собой нетехнические описания. Требования к продукту являются представлением требований клиента с помощью технической терминологии и могут быть использованы для проектных решений.

Вопрос 1.
Что значит выражены "с помощью технической терминологии"?

Цитата 2.
Разработка концепций и сценариев использования системы является первым шагом процесса анализа и утверждения требований

Вопрос 2.
Правильно ли я понимаю, что разработка концепции и ВИ есть суть анализа и осуществляется после сбора " требований клиента, требований к продукту и его компонентам, требований к компонентам продукта, требований к интерфейсам". Просто я как-то наивно полагал, что концепция делается до начала массового сбора требований?

Цитата 3 
Сценарий представляет собой последовательность событий, которые могут произойти при использовании продукта. Сценарий обычно используется, чтобы «высветить» некоторые потребности заинтересованных сторон. В отличие от сценария, концепция работы описывает, каким образом продукт используется или работает. Концепция зависит как от проектных решений, так и от сценария. Обычно при начальной выработке концепции альтернативные решения еще не существуют, поэтому концептуальные решения разрабатываются для анализа требований. По мере разработки технических решений и соответствующей разработки детальных требований нижнего уровня концепция работы может уточняться. Точно так же, как проектное решение для продукта может стать требованием для компонента продукта, концепция работы может стать сценарием (требованием) для компонентов продукта.

Вопрос 3
Как совершенно не въезжаю в то, что тут написано. То, что не понятно, подчеркнул.

4739

Системный Анализ и Требования / Re: Управление требованиями

« : 13 Ноября 2007, 18:08:11 »

Здорово.

Но...

Примерил это на RaQuest, и (его возможности пока знаю плохо, т.к. совершенно нет возможности проверить работу на коллективность - но зато есть стимул), думается мне, это там не возможно. Разве только в опции обсуждения.

Судя из контекста сценария - система управления требованиями должна также поддерживать и управление поручений и задач?

4740

Системный Анализ и Требования / Re: Управление требованиями

« : 13 Ноября 2007, 17:26:41 »

Ага пошла живая работа. Правда я бы точна таких требований не напридумывал студентам
В лучшем случае что-то из области вуза.

Нужно бы ещё придумать для них авторов, других заинтересованных лиц и их интересы, степень важности.

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

Набросок списка первых заданий студенту:
- классифицировать требования по 3-м уровням.

Вы имеете в виду: потребности, фичи и программные требования.
Или бизнес-требования, требования пользователей, функциональные требования

- Определить наличие и тип простейших зависимостей между требованиями одного уровня (детализация\агрегирование).

а если одно требование реализует несколько требований более высокого уровня, т.е. нет строгой иерархии

- Определить наличие связей проблема-решение между требованиями различных уровней.

А это что за связь?

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

Несовсем понял, что вы имеете в виду? И кто такой дизайнер требований?

Дело менеджера оных должно свестись к простой регистрации в определённом формате.
В нашем случае - заведению в РаКвесте.

Менеджера чего? Т.е. лица отвественного за требования, тот кто их формирует и утверждает?