Requirements Specification

• The result of requirements development is a documented agreement among stakeholders about the product to be built.
• The vision & scope document contains the business requirements, and user requirements can be captured in the form of use cases
• Functional and nonfunctional requirements often are stored in a software requirements specification (SRS)
• SRS is delivered to those who must design, build, and verify the solution.

You can represent software requirements in several ways, including:

• Well-structured and carefully written natural language.
• Visual models
• Formal specifications that define requirements by using mathematically precise specification languages. Provide the greatest rigor and precision, but few software developers and — even fewer customers — are familiar with them

• The SRS goes by many name: a business requirements document (BRD), functional specification, product specification, system specification, or simply requirements document.
• It states the functions and capabilities that a software system must provide, its characteristics, and the constraints that it must respect.
• It should describe as completely as necessary the system’s behaviors under various conditions, as well as desired system qualities such as performance, security, and usability.
• It is the basis for subsequent project planning, design, and coding, as well as the foundation for system testing and user documentation. However, it should not contain design, construction, testing, or project management details other than known design and implementation constraints.

• A single requirements deliverable often cannot meet the needs of all audiences
  • Some people need to know just the business objectives, others want only a high-level big picture, still others want to see just the user’s perspective, and yet others need all the details.
  • Not all user reps will go through the SRS, and developers need more than just the use cases
  • This is why we create the different models, and the SRS

• Every requirement needs a unique and persistent identifier
  • Helps refer to specific requirements in change requests, modification history, or requirements traceability matrix
  • Helps reuse requirements in multiple projects
  • Facilitate collaboration between team members
• Simple numbered or bulleted lists aren’t adequate for these purposes

• Simplest approach. Gives every requirement a unique sequence number, e.g. UC-9 or FR-26
• The prefeix indicate the requirement type
• A number is not reused if a requirement is deleted
• Used by commercial requirements management tools

I

3.2 Project

• f for example your functional requirements appear in ” Priorities ” of your SRS, they will all have labels that begin with “3.2”
• More digits indicate a more detailed, lower-level requirement
  • 3.2.4.3 is a child requirement of 3.2.4.

The system shall ask the user to confirm any request to print more

• “ than 10 copies Print.ConfirmCopies ” might be tagged
  • It is part of the print function and relates to the number of copies to print
• Hierarchical textual tags are structured, meaningful, and unaffected by adding, deleting, or moving other requirements.

• Number all figures and tables, give them captions, and refer to them by number.
• If you are storing requirements in a document, define your word processor’s cross-reference facility rather than hard-coded page or section numbers to refer to other locations within a document.
• Define hyperlinks to let the reader jump to related sections in the SRS or in other files.
• Include visual representations of information when possible to facilitate understanding.

Adopt requirement document templates

Identify requirement origins

Uniquely label each requirement

Record business rules

Specify non-functional requirements

or Volere Shell