Спецификация программных требований: разработка и лучшие практики
Software requirements specification
Разработка ПО: SRS – спецификация требований к программному обеспечению. Описывает функции, взаимодействие с пользователем и снижает риски переработки.
Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Введение
Описание программной системы, подлежащей разработке.
Description of a software system to be developed
Спецификация требований к программному обеспечению (SRS) – это описание программной системы, которая будет разработана. Она создается на основе спецификации бизнес-требований (CONOPS). Спецификация требований к программному обеспечению определяет функциональные и нефункциональные требования и может включать набор сценариев использования, описывающих взаимодействие пользователя с программным обеспечением, необходимое для обеспечения оптимального пользовательского опыта. Спецификации требований к программному обеспечению служат основой для достижения соглашения между заказчиком и исполнителем (или поставщиком) о функционировании программного продукта (в проектах, ориентированных на рынок, эти роли могут выполнять отделы маркетинга и разработки). Спецификация требований к программному обеспечению представляет собой тщательную оценку требований перед этапами детального проектирования системы и направлена на минимизацию последующих переработок. Она также должна обеспечивать реалистичную основу для оценки стоимости продукта, рисков и сроков реализации. При правильном использовании спецификации требований к программному обеспечению помогают предотвратить неудачу программного проекта. Документ спецификации программных требований содержит достаточный и необходимый набор требований для разработки проекта. Для определения этих требований разработчику необходимо четкое и всестороннее понимание разрабатываемых продуктов, которое достигается посредством детального и непрерывного взаимодействия с командой проекта и заказчиком на протяжении всего процесса разработки программного обеспечения. SRS может являться одним из элементов, определяемых в описании поставляемых результатов контракта, или иметь другую организационно установленную структуру. Как правило, SRS разрабатывается техническим писателем, системным архитектором или программистом.
A software requirements specification (SRS) is a description of a software system to be developed. It is modeled after the business requirements specification (CONOPS). The software requirements specification lays out functional and non functional requirements, and it may include a set of use cases that describe user interactions that the software must provide to the user for perfect interaction. Software requirements specifications establish the basis for an agreement between customers and contractors or suppliers on how the software product should function (in a market driven project, these roles may be played by the marketing and development divisions). Software requirements specification is a rigorous assessment of requirements before the more specific system design stages, and its goal is to reduce later redesign. It should also provide a realistic basis for estimating product costs, risks, and schedules. Used appropriately, software requirements specifications can help prevent software project failure. The software requirements specification document lists sufficient and necessary requirements for the project development. To derive the requirements, the developer needs to have a clear and thorough understanding of the products under development. This is achieved through detailed and continuous communications with the project team and customer throughout the software development process. The SRS may be one of a contract's deliverable data item descriptions or have other forms of organizationally mandated content. Typically a SRS is written by a technical writer, a systems architect, or a software programmer.
Требования запах
Следуя концепции "плохих запахов" в коде, было предложено понятие "запах требований" для описания проблем в спецификации требований, когда само требование не обязательно является ошибочным, но может оказаться проблемным. Примерами "запахов требований" являются субъективная лексика, двусмысленные наречия и прилагательные, превосходные степени и отрицательные утверждения.
Following the idea of code smells, the notion of requirements smell has been proposed to describe issues in requirements specification where the requirement is not necessarily wrong but could be problematic. Examples of requirements smells are subjective language, ambiguous adverbs and adjectives, superlatives and negative statements.