Тестирование программного обеспечения. Базовый курс. 3-е издание
Software requirements specification, SRS
жүктеу/скачать 5,03 Mb. Pdf көрінісі
|
Software Testing - Base Course (Svyatoslav Kulikov) - 3rd edition - RU
- Бұл бет үшін навигация:
- Requirements management tool.
| Software requirements specification, SRS.
SRS describes as fully as necessary the expected behavior of the software system. The SRS is used in development, testing, quality assurance, project management, and related project functions. People call this deliverable by many different names, including business requirements document, functional spec, requirements document, and others. [ «Software Requirements (3rd edition)», Karl Wiegers and Joy Beatty] 85 Requirements management tool. A tool that supports the recording of requirements, requirements attributes (e.g. priority, knowledge responsible) and annotation, and facilitates traceability through layers of requirements and requirements change management. Some requirements management tools also provide facilities for static analysis, such as consistency checking and violations to predefined requirements rules. [ISTQB Glossary] 86 Обширный список инструментальных средств управления требованиями можно найти здесь: http://makingofsoftware.com/resources/list-of-rm-tools Свойства качественных требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2023 Стр: 44/301 2.2.5. Свойства качественных требований В процессе тестирования требований проверяется их соответствие опреде- лённому набору свойств (рисунок 2.2.f). Рисунок 2.2.f — Свойства качественного требования Завершённость (completeness 87 ). Требование является полным и закончен- ным с точки зрения представления в нём всей необходимой информации, ничто не пропущено по соображениям «это и так всем понятно». Типичные проблемы с завершённостью: • Отсутствуют нефункциональные составляющие требования или ссылки на соответствующие нефункциональные требования (например: « пароли должны храниться в зашифрованном виде » — каков алгоритм шифрова- ния?). • Указана лишь часть некоторого перечисления (например: « экспорт осу- ществляется в форматы PDF, PNG и т.д. » — что мы должны понимать под «и т.д.»?). • Приведённые ссылки неоднозначны (например: « см. выше » вместо « см. раз- дел 123.45.b »). Способы обнаружения проблем Способы устранения проблем Применимы почти все техники тестиро- вания требований {51} , но лучше всего по- могает задавание вопросов и использо- вание графического представления раз- рабатываемой системы. Также очень по- могает глубокое знание предметной об- ласти, позволяющее замечать пропу- щенные фрагменты информации. Как только было выяснено, что чего-то не хватает, нужно полу- чить недостающую информа- цию и дописать её в требова- ния. Возможно, потребуется не- большая переработка требова- ний. 87 Each requirement must contain all the information necessary for the reader to understand it. In the case of functional requirements, this means providing the information the developer needs to be able to implement it correctly. No requirement or necessary information should be absent. [ «Software Requirements (3rd edition)», Karl Wiegers and Joy Beatty] Корректность и проверяемость Проранжированность Важность Стабильность Срочность Модифицируемость Прослеживаемость Обязательность Актуальность Выполнимость Недвусмысленность Непротиворечивость Атомарность Завершённость Свойства качественных требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2023 жүктеу/скачать 5,03 Mb. Достарыңызбен бөлісу:
|