Requirements Documentation
The result of requirements development is a documented agreement between customers and developers about the product to be built.
We can represent software requirements in several ways:
• Documents that use well structured and carefully written natural language.
• Graphical models that illustrate transformational processes, system states, data relationships, logic flows or object classes.
• Formal specifications that define requirements using mathematically precise formal logic languages.
Structured natural language, augmented with graphical models, remains the most practical way for most software projects to document their requirements.
The Software Requirements Specification (SRS)
The SRS states the functions and capabilities that a software system must provide and the constraints that it must respect. It is the basis for all subsequent project planning, design, coding, and testing.
Several audiences rely on the SRS:
• Customers, the marketing department, and sales staff need to know what product they can expect to be delivered.
• Project managers base their estimates of schedule, effort, and resources on the product description.
• The SRS tells the software development team what to build.
• The testing group uses the SRS to develop test plans, cases and procedures.
• The SRS tells maintenance and support staff what each part of the product is supposed to do.
• Documentation writers base user manuals and help screens on the SRS and user interface design.
• Training personnel use the SRS and user documentation to develop educational materials.
• Legal staff ensures that the requirements comply with applicable laws and regulations.
• Subcontractors base their work on the SRS.
The SRS must be comprehensive. Developers and customers should make no assumptions.
You don’t have to write the SRS for the entire product before beginning development, but you need to capture the requirements for each increment before building that increment.
Every project should baseline an agreement for each set of requirements before the team implements them. Baselining is the process of transitioning an SRS under development into one that has been reviewed and approved.
SRS Template
• Introduction – an overview to help the reader understand how the SRS is organized and how to use it.
o Purpose – indentify the product, application or subsystem whose requirements are specified in this document, including the revision or release number.
o Document Conventions – describe any standards or typographical conventions, including text styles, highlighting, or significant notations.
o Intended audience and reading suggestions – list the different readers to whom the SRS is directed. Describe what the rest of the SRS contains and how it is organized.
o Project scope – provide a short description of the software being specified and its purpose. Relate the software to user or corporate goals and to business objectives and strategies.
o References – list any documents or other resources to which the SRS refers. Like user interface style guides, contracts, standards, system requirements etc.
• Overall description – this section presents a high level overview of the product and the environment in which it will be used, the anticipated product users, and known constraints.
o Product perspective – describe the product’s context and origin.
o Product features – list the major features the product contains or the significant functions that it performs.
o User classes and characteristics – identify the various user classes that you anticipate will use this product and describe their characteristics.
o Operating environment – describe the environment in which the software will operate, including the hardware platform, the operating systems and versions, and the geographical locations of users, servers and databases.