Составление требований к разрабатываемому ПО
Alistair Cockburn - Writing Effective Use Cases
Dean Leffingwell, Don Widrig - Managing Software Requirements: A Use Case Approach
Rational Unified Process наверно еще почитать можно.
Вот еще ссылки с Озона:
web page 1
web page 2
Dean Leffingwell, Don Widrig - Managing Software Requirements: A Use Case Approach
Rational Unified Process наверно еще почитать можно.
Вот еще ссылки с Озона:
web page 1
web page 2
RUP это слишком круто 
А на русском можешь чего-нибудь порекомендовать? А то я забугорну мову плохо розумлю
А на русском можешь чего-нибудь порекомендовать? А то я забугорну мову плохо розумлю
А на русском можешь чего-нибудь порекомендовать? А то я забугорну мову плохо розумлю
Первая из книг есть в русском переводе:
Алистер Коберн - Современные методы описания функциональных требований к системам
Вторую (Dean Leffingwell, Don Widrig - Managing Software Requirements: A Use Case Approach) я тоже кажется видел в переводе, но почему-то по ссылкам она только в оригинале на английском.
Ну и там в ссылках есть еще одна книга на русском, я про нее ничего сказать не могу, но судя по тому, что там на сайте про нее написано - должно быть вроде ничего.
Да, забыл сказать: эти книги рассматривают только функциональные требования к системе. А есть еще нефункциональные, типа производительность, надежность, защищенность и т.д. Это отдельная история.
RUP это слишком крутоНу, не знаю, может быть.
Можно почитать "Введение в Rational Unified Process" (Филипп Крачтен думаю, не очень загрузная книга.
Ну, на худой конец есть еще такая книга:
А. М. Вендров - Проектирование программного обеспечения экономических информационных систем
Там про требования должно быть вкратце
А. М. Вендров - Проектирование программного обеспечения-1
довольно водянистая книга, для быстрого освоения темы скорее всего не подходит.
возникло впечатление, что ее можно ужать в несколько раз без потери содержательности.
-1+1
довольно водянистая книга, для быстрого освоения темы скорее всего не подходит.
возникло впечатление, что ее можно ужать в несколько раз без потери содержательности.
-1Возможно.
довольно водянистая книга, для быстрого освоения темы скорее всего не подходит.
Но если РУП сразу ботать не хочется или не можется, то можно попробовать начать с Вендрова, в качестве краткого введения.
А есть еще нефункциональные, типа производительность, надежность, защищенность и т.д. Это отдельная история.А тут кто что посоветует?
не понял,
это возражение или проявление солидарности?
если возражение, то прошу аргументировать.
это возражение или проявление солидарности?
если возражение, то прошу аргументировать.
Первая из книг есть в русском переводе:
Алистер Коберн - Современные методы описания функциональных требований к системам
тут
Леффингуэлл Д. Уидриг
Принципы работы с требованиями к программному обеспечению: Унифицированный подход.
кажется оно
не понял,Ну, скорее солидарность с уточнением
это возражение или проявление солидарности?
если возражение, то прошу аргументировать.
Я, если честно, содержание книжки Вендрова уже не помню. Но мне кажется, что там в кратце про требования написано, про Use Case'ы, например. Поэтому я думаю, что если "Введение в РУП" кажется сложной книгой, то можно попробовать почитать Вендрова, чтоб получить представление о проблеме. А так, конечно, Вендров - это мало.
А есть еще нефункциональные, типа производительность, надежность, защищенность и т.д. Это отдельная история.А тут кто что посоветует?
На Амазоне поиск выдает кучу книг, но они в основном про требования вообще. Надо полагать, нефункциональные требования там идут отдельной главой.
И еще есть стандарт ISO 9126 - Software Quality Standard. Там приведены основные нефункциональные характеристики ПО вроде производительности, надежности, usability, security и так далее. Для каждой характеристики есть под-характеристики и в конечном счете - атрибуты. Например, для производительности, насколько я помню, - это время ответа (response time пропускная способность (throughgput) и используемость ресурсов (resource usage). Соответсвенно, в проекте требования по производительности задаются в этих терминах. Например, такая-то функция должна выполняться не более чем за Х секунд или сервер должен обрабатывать не менее Н запросов в минуту.
Сам стандарт платный.
На русском про него есть неплохая книга
В. В. Липаев - Обеспечение качества программных средств. Методы и стандарты
Насколько я помню, она как раз про ISO 9126.
Сейчас наверно глупость спрошу, тем не менее: А что есть менее академичное.
Нужен вариант "для чайников". Нечто вроде 10 простых советов, как по разрозненым требованиям разных людей, понять какой должна быть система, чтобы нравилась всем и чтобы обладала перспективами развития?
Нужен вариант "для чайников". Нечто вроде 10 простых советов, как по разрозненым требованиям разных людей, понять какой должна быть система, чтобы нравилась всем и чтобы обладала перспективами развития?
А что есть менее академичное
Я бы сказал, что, например, Use Cases - это отнюдь не академическая вещь. Да и ISO 9126 тоже не в академиях придумано. Это все реально и очень широко используется на практике, особенно Use Cases.
А вообще, я не совсем понял, что имелось ввиду под "академичностью".
Если речь идет о том, чтоб использовать какой-то простой подход, который не надо долго ботать ("для чайников" то Use Cases как раз таковым и является. Мое мнение - там по существу реально очень мало теории, и она проста как пень. Главное - это практика и опыт.
Нечто вроде 10 простых советов, как по разрозненым требованиям разных людей, понять какой должна быть система, чтобы нравилась всем и чтобы обладала перспективами развития?
Хм ...
Есть большая вероятность того, что в результате получится не то, что нужно.
Только мне кажется, что это уже не совсем составление требований к ПО. Это уже шаг дальше - дизайн системы. Тут можно много чего писать и говорить. Я бы сказал, что многое зависит от размера системы, от ее характеристик и от опыта разработчиков. Например, если нужно разработать не что-то принципиально новое, а что-то более-менее типичное (типа интернет-магазина то скорее всего разработчики уже заранее в целом знают, как будет выглядеть система, особенно если они это делают не в первый раз. В этом случае анализ требований возможно уже не играет большой роли. А если нужно делать систему, с которой раньше команда разработчиков не сталкивалась, то тогда нужно уже закапываться в требования глубже. Еще есть вариант, когда пользователи и сами особо не знают, а что им собственно нужно от будущей системы. То есть требования размытые и неполные. Тогда нужно садиться вместе с ними и ботать. Рекомендуется создавать как можно быстрее прототипы будущей системы и показывать их пользователям, чтобы выяснить, это им нужно или что-то другое.
В общем, тут много чего есть. В 10 советах "для чайников" не уложиться.
Я бы все же посоветовал использовать Use Cases.
у меня есть в пдф-формате:
Элизабет Халл, Кен Джексон, Джереми Дик - "Разработка и управление требованиями" (практическое руководство пользователя)
хорошая, правда весьма фундаментальная книжка
могу скинуть на мыло - кому надо
размер примерно 5 Мб
Элизабет Халл, Кен Джексон, Джереми Дик - "Разработка и управление требованиями" (практическое руководство пользователя)
хорошая, правда весьма фундаментальная книжка
могу скинуть на мыло - кому надо
размер примерно 5 Мб
Мне надо. yojick на v.gz.ru
И аську свою присылай
И аську свою присылай
Фотку забыл 
Оставить комментарий
and-guzij
Подскажите источники мудрости, книжки какие-нибудь.