Sistemas informaticos

The ............................. System

Requirements Specification

Version ...




Table of Contents


PROJECT DRIVERS

1. The Purpose of the Product
2. Client, Customer and other Stakeholders
3. Users of the Product

PROJECT CONSTRAINTS

4. Mandated Constraints
5. Naming Conventions and Definitions
6. Relevant Facts and AssumptionsFUNCTIONAL REQUIREMENTS

7. The Scope of the Work
8. The Scope of the Product
9. Functional and Data Requirements

NON-FUNCTIONAL REQUIREMENTS

10. Look and Feel Requirements
11. Usability Requirements
12. Performance Requirements
13. Operational Requirements
14. Maintainability and Portability Requirements
15. SecurityRequirements
16. Cultural and Political Requirements
17. Legal Requirements

PROJECT ISSUES

18. Open Issues
19. Off-the-Shelf Solutions
20. New Problems
21. Tasks
22. Cutover
23. Risks
24. Costs
25. User Documentation and Training
26. Waiting Room
27. Ideas for Solutions
Specification prepared by........................................ Date ...................

Preamble
This is a template for a requirements specification. Select all the sections that apply to your project, and replace the entries with your text. Delete any sections that are not relevant. Add any applicable new sections, and any facts that are relevant to your product.

Volere is the result of many years of practice, consulting and researchin requirements engineering. We have packaged our experience in the form of a generic requirements process, requirements training, requirements consultancy, requirements audits and this requirements template.
The Volere requirements process is described in the book:
Mastering the Requirements Process by Suzanne and James Robertson,
Addison-Wesley, London, 1999. ISBN is 0-201-36046-2Requirements Types

Functional requirements are the fundamental subject matter of the system and are measured by concrete means like data values, decision-making logic and algorithms.
Non-functional requirements are the behavioral properties that the specified functions must have, such as performance, usability, etc. Non-functional requirements can be assigned a specific measurement. This template willgive examples of quantifying non-functional requirements.
Project constraints identify how the eventual product must fit into the world. For example the product might have to interface with or use some existing hardware, software or business practice, or it might have to fit within a defined budget or be ready by a defined date.

Project drivers are the business- related forces. For example thepurpose of the product is a project driver, as are all of the stakeholders – each for different reasons.
Project issues define the conditions under which the project will be done. We include these in the requirements specification to present a coherent picture of all the factors that contribute to the success or failure of the project.


Testing requirements


You start testing the as soonas you start to specify the requirements.
You first test is to determine if you can quantify the requirement by specifying its fit criterion. This fit criterion is an objective measure of the requirement’s meaning; it is the criterion for evaluating whether or not a given solution fits the requirement. If a fit criterion cannot be adequately specified, then the requirement is ambiguous, or illunderstood. If there is no fit criterion, then there is no way of knowing if a solution matches the requirement.


Requirement Shell


Use this requirement shell as a guide for writing each requirement.

Requirement #: Unique ID
Requirement Type:The type from the template
Event/use case #: List of Events / Use cases that need this requirement
Description: A one sentence statement of...