RUP_Templates

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Doc_Especificacao_Suplementar.odt
<Project Name>
Supplementary Specification
Version <1.0>
[Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should be deleted before publishing the document. A paragraph entered following this style will automatically be set to normal (style=Body Text).]
[To customize automatic fields in Microsoft Word (which display a gray background when selected), select File>Properties and replace the Title, Subject and Company fields with the appropriate information for this document. After closing the dialog, automatic fields may be updated throughout the document by selecting Edit>Select All (or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must be done separately for Headers and Footers. Alt-F9 will toggle between displaying the field names and the field contents. See Word help for more information on working with fields.] 
Revision History
		Date
		Version
		Description
		Author
		<dd/mmm/yy>
		<x.x>
		<details>
		<name>
		
		
		
		
		
		
		
		
		
		
		
		
Table of Contents
1. Introduction	4
1.1 Purpose	4
1.2 Scope	4
1.3 Definitions, Acronyms, and Abbreviations	4
1.4 References	4
1.5 Overview	4
2. Functionality	4
2.1 <Functional Requirement One>	5
3. Usability 	5
3.1 <Usability Requirement One>	5
4. Reliability 	5
4.1 <Reliability Requirement One>	5
5. Performance	5
5.1 <Performance Requirement One>	6
6. Supportability	6
6.1 <Supportability Requirement One>	6
7. Design Constraints	6
7.1 <Design Constraint One>	6
8. Online User Documentation and Help System Requirements	6
9. Purchased Components	6
10. Interfaces	6
10.1 User Interfaces	6
10.2 Hardware Interfaces	6
10.3 Software Interfaces	6
10.4 Communications Interfaces	6
11. Licensing Requirements	7
12. Legal, Copyright, and Other Notices	7
13. Applicable Standards	7
Supplementary Specification 
Introduction
[The introduction of the Supplementary Specification provides an overview of the entire document. It includes the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Supplementary Specification. 
The Supplementary Specification captures the system requirements that are not readily captured in the use cases of the use-case model. Such requirements include: 
		Legal and regulatory requirements, including application standards. 
		Quality attributes of the system to be built, including usability, reliability, performance, and supportability requirements. 
		Other requirements such as operating systems and environments, compatibility requirements, and design constraints.]
Purpose
[Specify the purpose of this Supplementary Specification.]
Scope
[A brief description of the scope of this Supplementary Specification; what Project(s) it is associated with and anything else that is affected or influenced by this document.]
Definitions, Acronyms, and Abbreviations
[This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the Supplementary Specification. This information may be provided by reference to the project’s Glossary.]
References
[This subsection provides a complete list of all documents referenced elsewhere in the Supplementary Specification. Identify each document by title, report number if applicable, date, and publishing organization. Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document.]
Overview
[This subsection describes what the rest of the Supplementary Specification contains and explains how the document is organized.]
Functionality
[This section describes the functional requirements of the system for those requirements which are expressed in the natural language style. For many applications, this may constitute the bulk of the SRS Package and thought should be given to the organization of this section. This section is typically organized by feature, but alternative organization methods, for example organization by user or organization by subsystem, may also be appropriate. Functional requirements may include feature sets, capabilities, and security.
Where application development tools, such as requirements tools, modeling tools, and so on, are employed to capture the functionality, this section document will refer to the availability of that data, indicating the location and name of the tool used to capture the data.]
<Functional Requirement One>
[The requirement description.]
Usability 
[This section should include all of those requirements that affect usability. Examples follow:
		specify the required training time for a normal users and power users to become productive at particular operations
		specify measurable task times for typical tasks, or
		specify requirements to conform to common usability standards, for example, IBM’s CUA standards or Microsoft’s GUI standards]
<Usability Requirement One>
The requirement description.
Reliability 
[Requirements for reliability of the system should be specified here. Suggestions are as follows:
		Availability – specify percentage of time available ( xx.xx%), hours of use, maintenance access, degraded mode operations, and the like.
		Mean Time Between Failures (MTBF) – this is usually specified in hours but it could also be specified in terms of days, months or years.
		Mean Time To Repair (MTTR) – how long is the system allowed to be out of operation after it has failed?
		Accuracy – specify precision (resolution) and accuracy (by some known standard) that is required in the systems output.
		Maximum bugs or defect rate – usually expressed in terms of bugs/KLOC (thousands of lines of code), or bugs/function-point.
		Bugs or defect rate – categorized in terms of minor, significant, and critical bugs: the requirement(s) must define what is meant by a “critical” bug; for example, complete loss of data or complete inability to use certain parts of the functionality of the system.]
<Reliability Requirement One>
[The requirement description.]
Performance
[The performance characteristics of the system should be outlined in this section. Include specific response times. Where applicable, reference related Use Cases by name.
		Response time for a transaction(average, maximum)
		Throughput (for example, transactions per second)
		Capacity (for example, the number of customers or transactions the system can accommodate)
		Degradation modes (what is the acceptable mode of operation when the system has been degraded in some manner)
		Resource use: memory, disk, communications, and so forth]
<Performance Requirement One>
[The requirement description.]
Supportability
[This section indicates any requirements that will enhance the supportability or maintainability of the system being built, including coding standards, naming conventions, class libraries, maintenance access, maintenance utilities.]
<Supportability Requirement One>
[The requirement description.]
Design Constraints
[This section needs to indicate any design constraints on the system being built. Design constraints represent design decisions that have been mandated and must be adhered to. Examples include software languages, software process requirements, prescribed use of developmental tools, architectural and design constraints, purchased components, class libraries, and so on.]
<Design Constraint One>
[The requirement description.]
Online User Documentation and Help System Requirements
[Describes the requirements, if any, for on-line user documentation, help systems, help about notices, and so on.]
Purchased Components
[This section describes any purchased components to be used with the system , any applicable licensing or usage restrictions, and any associated compatibility/interoperability or interface standards.]
Interfaces
[This section defines the interfaces that must be supported by the application. It should contain adequate specificity, protocols, ports and logical addresses, and so forth, so that the software can be developed and verified against the interface requirements.]
User Interfaces
[Describe the user interfaces that are to be implemented by the software.]
Hardware Interfaces
[This section defines any hardware interfaces that are to be supported by the software, including logical structure, physical addresses, expected behavior, and so on.]
Software Interfaces
[This section describes software interfaces to other components of the software system. These may be purchased components, components reused from another application or components being developed for subsystems outside of the scope of this SRS, but with which this software application must interact.]
Communications Interfaces
[Describe any communications interfaces to other systems or devices such as local area networks, remote serial devices, and so on.]
Licensing Requirements
[Defines any licensing enforcement requirements or other usage restriction requirements that are to be exhibited by the software.]
Legal, Copyright, and Other Notices
[This section describes any necessary legal disclaimers, warranties, copyright notices, patent notice, wordmark, trademark, or logo compliance issues for the software.]
Applicable Standards
[This section describes by reference any applicable standards and the specific sections of any such standards that apply to the system being described. For example, this could include legal, quality and regulatory standards, industry standards for usability, interoperability, internationalization, operating system compliance, and so forth.]
<Company Name>
		<Project Name>
		Version: <1.0>
		Supplementary Specification
		Date: <dd/mmm/yy>
		<document identifier>
		Confidential
		<Company Name>, 2013
		Page 
Doc_Glossario.odt
<Project Name>
Glossary
Version <1.0>
[Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should be deleted before publishing the document. A paragraph entered following this style will automatically be set to normal (style=Body Text).]
[To customize automatic fields in Microsoft Word (which display a gray background when selected), select File>Properties and replace the Title, Subject and Company fields with the appropriate information for this document. After closing the dialog, automatic fields may be updated throughout the document by selecting Edit>Select All (or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must be done separately for Headers and Footers. Alt-F9 will toggle between displaying the field names and the field contents. See Word help for more information on working with fields.] 
Revision History
		Date
		Version
		Description
		Author
		<dd/mmm/yy>
		<x.x>
		<details>
		<name>
		
		
		
		
		
		
		
		
		
		
		
		
Table of Contents
1. Introduction	4
1.1 Purpose	4
1.2 Scope	4
1.3 References	4
1.4 Overview	4
2. Definitions	4
2.1 <aTerm>	4
2.2 <anotherTerm>	4
2.3 <aGroupofTerms>	4
2.3.1 <aGroupTerm>	5
2.3.2 <anotherGroupTerm>	5
2.4 <aSecondGroupofTerms>	5
2.4.1 <yetAnotherGroupTerm>	5
2.4.2 <andAnotherGroupTerm>	5
3. UML Stereotypes	5
Glossary
Introduction
[The introduction of the Glossary provides an overview of the entire document. Present any information the reader might need to understand the document in this section. This document is used to define terminology specific to the problem domain, explaining terms that may be unfamiliar to the reader of the use-case descriptions or other project documents. Often, this document can be used as an informal data dictionary, capturing data definitions so that use-case descriptions and other project documents can focus on what the system must do with the information. This document should be saved in a file called Glossary.]
Purpose
[Specify the purpose of this Glossary.]
Scope
[A brief description of the scope of this Glossary; what Project(s) it is associated with and anything else that is affected or influenced by this document.]
References
[This subsection provides a complete list of all documents referenced elsewhere in the Glossary. Identify each document by title, report number (if applicable), date, and publishing organization. Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document.]
Overview
[This subsection describes what the rest of the Glossary contains and explains how the document is organized.]
Definitions
[The terms defined here form the essential substance of the document. They can be defined in any order desired, but generally alphabetical order provides the greatest accessibility.]
<aTerm>
[The definition for <aTerm> is presented here. As much information as the reader needs to understand the concept should be presented.]
<anotherTerm>
The definition for <anotherTerm> is presented here. As much information as the reader needs to understand the concept should be presented
<aGroupofTerms>
[Sometimes it is useful to organize terms into groups to improve readability. For example, if the problem domain contains terms related to both accounting and building construction (as would be the case if we were developing a system to manage construction projects), presenting the terms from the two different sub-domains might prove confusing to the reader. To solve this problem, we use groupings of terms. In presenting the grouping of terms, provide a short description that helps the reader understand what <aGroupofTerms> represents. Terms presented within the group should be organized alphabetically for easy access.]
<aGroupTerm>
[The definition for <aGroupTerm> is presented here. Present as much information as the reader needs to understand the concept.]
<anotherGroupTerm>
[The definition for <anotherGroupTerm> is presented here. Present as much information as the reader needs to understand the concept.]
<aSecondGroupofTerms>
<yetAnotherGroupTerm>
[The definition for the term is presented here. Present as much information as the reader needs to understand the concept.]
<andAnotherGroupTerm>
[The definition for the term is presented here. Present as much information as the reader needs to understand the concept.]
UML Stereotypes
[This section contains or references specifications of Unified Modeling Language (UML) stereotypes and their semantic implications—a textual description of the meaning and significance of the stereotype and any limitations on its use—for stereotypes already known or discovered to be important for the system being modeled. The use of these stereotypes may be simply recommended or perhaps even made mandatory; for example, when their use is required by an imposed standard or when it is felt that their use makes models significantly easier to understand. This section may be empty if no additional stereotypes, other than those predefined by the UML and the Rational Unified Process, are considered necessary.]
<Company Name>
		<Project Name>
		Version: <1.0>
Glossary
		Date: <dd/mmm/yy>
		<document identifier>
		Confidential
		<Company Name>, 2013
		Page 
Doc_Lista_Riscos.odt
<Project Name>
Risk List
Version <1.0>
[Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should be deleted before publishing the document. A paragraph entered following this style will automatically be set to normal (style=Body Text).]
[To customize automatic fields in Microsoft Word (which display a gray background when selected), select File>Properties and replace the Title, Subject and Company fields with the appropriate information for this document. After closing the dialog, automatic fields may be updated throughout the document by selecting Edit>Select All (or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must be done separately for Headers and Footers. Alt-F9 will toggle between displaying the field names and the field contents. See Word help for more information on working with fields.] 
Revision History
		Date
		Version
		Description
		Author
		<dd/mmm/yy>
		<x.x>
		<details>
		<name>
		
		
		
		
		
		
		
		
		
		
		
		
Table of Contents
1. Introduction	4
1.1 Purpose	4
1.2 Scope	4
1.3 Definitions, Acronyms, and Abbreviations	4
1.4 References	4
1.5 Overview	4
2. Risks	4
2.1 <Risk Identifier—a descriptive name or number> 	4
2.1.1 Risk Magnitude or Ranking	4
2.1.2 Description	4
2.1.3 Impacts	4
2.1.4 Indicators	4
2.1.5 Mitigation Strategy	4
2.1.6 Contingency Plan	5
2.2 <next Risk Identifier—a descriptive name or number>	5
Risk List
Introduction
[The introduction of the Risk List provides an overview of the entire document. It includes the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Risk List.]
Purpose
[Specify the purpose of this Risk List.]
Scope
[A brief description of the scope of this Risk List; what Project(s) it is associated with and anything else that is affected or influenced by this document.]
Definitions, Acronyms, and Abbreviations
[This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the Risk List. This information may be provided by reference to the project’s Glossary.]
References
[This subsection provides a complete list of all documents referenced elsewhere in the Risk List. Identify each document by title, report number if applicable, date, and publishing organization. Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document.]
Overview
[This subsection describes what the rest of the Risk List contains and explains how the document is organized.]
Risks
<Risk Identifier—a descriptive name or number> 
Risk Magnitude or Ranking
[An indicator of the magnitude of the risk may be assigned to help rank the risks from most to least damaging to the project.]
Description
[A brief description of the risk.]
Impacts
[List the impacts on the project or product.]
Indicators
[Describe how to monitor and detect that the risk has occurred or is about to occur. Include such things as metrics and thresholds, test results, specific events, and so forth.]
Mitigation Strategy
[Describe what is currently done on the project to reduce the impact of the risk.]
Contingency Plan
[Describe what the course of action will be if the risk does materialize: alternate solution, reduction in functionality, and so on.]
<next Risk Identifier—a descriptive name or number>
<Company Name>
		<Project Name>
		Version: <1.0>
		Risk List
		Date: <dd/mmm/yy>
		<document identifier>
		Confidential
		<Company Name>, 2013
		Page of 
Doc_Visao.odt
<Project Name>
Business Vision
Version <1.0>
[Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should be deleted before publishing the document. A paragraph entered following this style will automatically be set to normal (style=Body Text).]
[To customize automatic fields in Microsoft Word (which display a gray background when selected), select File>Properties and replace the Title, Subject and Company fields with the appropriate information for this document. After closing the dialog, automatic fields may be updated throughout the document by selecting Edit>Select All (or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must be done separately for Headers and Footers. Alt-F9 will toggle between displaying the field names and the field contents. See Word help for more information on working with fields.] 
Revision History
		Date
		Version
		Description
		Author
		<dd/mmm/yy>
		<x.x>
		<details>
		<name>
		
		
		
		
		
		
		
		
		
		
		
		
Table of Contents
1. Introduction	4
1.1 Purpose	4
1.2 Scope	4
1.3 Definitions, Acronyms, and Abbreviations	4
1.4 References	4
1.5 Overview	4
2. Positioning	4
2.1 Business Opportunity	4
2.2 Problem Statement	4
2.3 Product Position Statement	5
3. Stakeholder and Customer Descriptions	5
3.1 Market Demographics	5
3.2 Stakeholder Summary	5
3.3 User Summary	6
3.4 User Environment	6
3.5 Stakeholder Profiles 	6
3.5.1 <Stakeholder Name>	7
3.6 Customer Profiles 	7
3.6.1 <Customer Name>	7
3.7 Key Stakeholder or Customer Needs	8
3.8 Alternatives and Competition	8
4. Business Modeling Objectives	8
4.1 <anObjective>	8
4.2 <anotherObjective>	8
5. Constraints	8
6. Quality Ranges 	8
7. Precedence and Priority	8
8. Other Requirements	8
8.1 Applicable Standards	9
8.2 System Requirements	9
8.3 Performance Requirements	9
8.4 Environmental Requirements	9
Appendix 1 – Objective Attributes	9
Business Vision
Introduction
The introduction of the Business Vision provides an overview of the entire document. It should include the purpose, scope, definitions, acronyms, abbreviations, references, and overview of the Business Vision.]
Purpose
[Specify the purpose of this Business Vision document.]
Scope
[A brief description of the scope of this Business Vision document; what Project(s) it is associated with and anything else that is affected or influenced by this document.]
Definitions, Acronyms, and Abbreviations
[This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the Business Vision document. This information may be provided by reference to the project’s Glossary.]
References
[This subsection provides a complete list of all documents referenced elsewhere in the Business Vision. Identify each document by title, report number if applicable, date, and publishing organization. Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document.]
Overview
[This subsection describes what the rest of the Business Vision contains and explains how the document is organized.]
Positioning
Business Opportunity
[Briefly describe the business opportunity being met by this project.]
Problem Statement
[Provide a statement summarizing the problem being solved by this project. The following format may be used.]
		The problem of
		[describe the problem]
		affects
		[who are the stakeholders affected
by the problem]
		the impact of which is
		[what is the impact of the problem]
		a successful solution would be
		[list some key benefits of a successful solution]
Product Position Statement
[Provide an overall statement summarizing, at the highest level, the unique position the product intends to fill in the marketplace. The following format may be used.]
		For
		[target customer]
		Who
		[statement of the need or opportunity]
		The (product name)
		is a [product category]
		That
		[statement of key benefit; that is, what is the compelling reason to buy]
		Unlike
		[primary competitive alternative]
		Our product
		[statement of primary differentiation]
[A product position statement communicates the intent of the application and the importance of the project to all concerned personnel.]
Stakeholder and Customer Descriptions
[To effectively provide products and services that meet your stakeholders’ and users' real needs, it is necessary to identify and involve all stakeholders as part of the Business Modeling process. You must also identify the users of the system and ensure that the stakeholder community adequately represents them. This section provides a profile of the stakeholders and users involved in the project, and the key problems that they perceive to be addressed by the proposed solution. It does not describe their specific requests or requirements as these are captured in a separate stakeholder requests artifact. Instead, it provides the background and justification for why the requirements are needed.]
Market Demographics
[Summarize the key market demographics that motivate your product decisions. Describe and position target market segments. Estimate the market’s size and growth by using the number of potential users or the amount of money your customers spend trying to meet needs that your product or enhancement will fulfill. Review major industry trends and technologies. Answer these strategic questions:
		What is your organization’s reputation in these markets? 
		What would you like it to be? 
		How does this product or service support your goals?]
Stakeholder Summary
[There are a number of stakeholders with an interest in the development and not all of them are end users. Present a summary list of these non-user stakeholders. (The users are summarized in section 3.3.)]
		Name
		Description
		Responsibilities
		[Name the stakeholder type.]
		[Briefly describe the stakeholder.]
		[Summarize the stakeholder’s key responsibilities with regard to the system being developed; that is, their interest as a stakeholder. For example, this stakeholder:
		ensures that the system will be maintainable
		ensures that there will be a market demand for the product’s features
		monitors the project’s progress
		approves funding
		and so forth]
User Summary
[Present a summary list of all identified users.]
		Name
		Description
		Responsibilities
		Stakeholder
		[Name the user type.]
		[Briefly describe what they represent with respect to the system.]
		[List the user’s key responsibilities with regard to the system being developed; for example:
		captures details
		produces reports
		coordinates work
		and so on]
		[If the user is not directly represented, identify which stakeholder is responsible for representing the user’s interest.]
User Environment
[Detail the working environment of the target user. Here are some suggestions:
		Number of people involved in completing the task? Is this changing?
		How long is a task cycle? Amount of time spent in each activity? Is this changing?
		Any unique environmental constraints: mobile, outdoors, in-flight, and so on?
		Which systems platforms are in use today? Future platforms?
		What other applications are in use? Does your application need to integrate with them?
This is where extracts from the Business Model could be included to outline the task and roles involved and so on.]
Stakeholder Profiles 
[Describe each stakeholder in the system here by filling in the following table for each stakeholder. Remember that stakeholder types can be as divergent as users, departments, and technical developers. A thorough profile would cover the following topics for each type of stakeholder.]
<Stakeholder Name>
		Representative
		[Who is the stakeholder representative to the project? (This is optional if it’s documented elsewhere.) What we want here is names.]
		Description
		[Brief description of the stakeholder type.]
		Type
		[Qualify the stakeholder’s expertise, technical background, and degree of sophistication—that is, guru, business, expert, casual user, and so on.]
		Responsibilities
		[List the stakeholder’s key responsibilities with regard to the system being developed—that is, their interest as a stakeholder.]
		Success Criteria
		[How does the stakeholder define success? How is the stakeholder rewarded?]
		Involvement
		[How is the stakeholder involved in the project? Relate, where possible, to the Rational Unified Process roles—that is, Requirements Reviewer and so on.]
		Deliverables
		[Are there any additional deliverables required by the stakeholder? These could be project deliverables or outputs from the system under development.]
		Comments and Issues
		[Problems that interfere with success and any other relevant information go here.]
Customer Profiles 
[Describe each unique user of the system here by filling in the following table for each customer type. A thorough profile covers the following topics for each type of user.]
<Customer Name>
		Representative
		[Who is the user representative to the project? (This is optional if it’s documented elsewhere.) This often refers to the Stakeholder that represents the set of users, for example, Stakeholder: Stakeholder1.]
		Description
		[A brief description of the customer type.]
		Type
		[Qualify the customer’s expertise, technical background, and degree of sophistication—that is, guru, casual user, and so on.] 
		Responsibilities
		[List the user’s key responsibilities with regard to the system being developed— that is, captures customers details, produces reports, coordinates work, and so on.]
		Success Criteria
		[How does the customer define success? How is the customer rewarded?]
		Involvement
		[How is the customer involved in the project? Relate, where possible, to the Rational Unified Process roles—that is, Requirements Reviewer and so on.]
		Deliverables
		[Are there any deliverables the customer produces and, if so, for whom?]
		Comments and Issues
		[Problems that interfere with success and any other relevant information go here.
These include trends that make the customer’s job easier or more difficult.]
Key Stakeholder or Customer Needs
[List the key problems with existing solutions as perceived by the stakeholder. Clarify the following issues for each problem:
		What are the reasons for this problem? 
		How is it solved now?
		What solutions does the user want?]
[It is important to understand the relative importance the stakeholder places on solving each problem. Ranking and cumulative voting techniques indicate problems that must be solved as opposed to issues they would like addressed.
Fill in the following table—if using Rational RequisitePro to capture the Needs, this could be an extract or report from that tool.]
		Need
		Priority
		Concerns
		Current Solution
		Proposed Solutions
		Broadcast messages
		
		
		
		
Alternatives and Competition
[Identify alternatives the stakeholder perceives as available. These can include buying a competitor’s product, building a homegrown solution or simply maintaining the status quo. List any known competitive choices that exist or that may become available. Include the major strengths and weaknesses of each competitor as perceived by the stakeholder.]
Business Modeling Objectives
<anObjective>
<anotherObjective>
Constraints
[Note any design constraints, external constraints or other dependencies.]
Quality Ranges 
[Define the quality ranges for performance, robustness, fault tolerance, usability, and similar characteristics that are not captured in the objectives.]
Precedence and Priority
[Define the priority of the different objectives.]
Other Requirements
[At a high level, list applicable standards, hardware or platform requirements, performance requirements, and environmental requirements.]
Applicable Standards
[List all standards with which the business must comply. These can include legal and regulatory (FDA, UCC) communications standards (TCP/IP, ISDN), platform compliance standards (Windows, UNIX, and so on), and quality and safety standards (UL, ISO, CMM).]
System Requirements
[Define any system requirements necessary to support the application. These may include the supported host operating systems and network platforms, configurations, memory, peripherals, and companion software.]
Performance Requirements
[Use this section to detail performance requirements. Performance issues can include such items as user load factors, bandwidth or communication capacity, throughput, accuracy, and reliability or response times under a variety of loading conditions.]
Environmental Requirements
[Detail environmental requirements as needed. For hardware-based systems, environmental issues include temperature, shock, humidity, radiation, and so on. For software applications, environmental factors include usage conditions, user environment, resource availability, maintenance issues, and error handling and recovery.]
Appendix 1 – Objective Attributes
[Objectives are given attributes used to evaluate, track, prioritize, and manage the product items proposed for implementation. List and briefly describe the attributes you have chosen. See the Artifact: Requirement Management Plan for a set of suggested feature attributes.]
<Company Name>
		<Project Name>
		Version: <1.0>
		Business Vision
		Date: <dd/mmm/yy>
		<document identifier>
		Confidential
		<Company Name>, 2013
		Page 
Doc_Especificacao_Casos_Uso.odt
<Project Name>
Use-Case Specification: <Use-Case Name>
Version <1.0>
[Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should be deleted before publishing the document. A paragraph entered following this style will automatically be set to normal (style=Body Text).]
[To customize automatic fields in Microsoft Word (which display a gray background when selected), select File>Properties and replace the Title, Subject and Company fields with the appropriate information for this document. After closing the dialog, automatic fields may be updated throughout the document by selecting Edit>Select All (or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must be done separately for Headers and Footers. Alt-F9 will toggle between displaying the field names and the field contents. See Word help for more information on working with fields.] 
Revision History
		Date
		Version
		Description
		Author
		<dd/mmm/yy>
		<x.x>
		<details>
		<name>
		
		
		
		
		
		
		
		
		
		
		
		
Table of Contents
1. Use-Case Name 	4
1.1 Brief Description	4
2. Flow of Events	4
2.1 Basic Flow 	4
2.2 Alternative Flows	4
2.2.1 < First Alternative Flow >	4
2.2.2 < Second Alternative Flow >	5
3. Special Requirements	5
3.1 < First Special Requirement >	5
4. Preconditions	5
4.1 < Precondition One >	5
5. Postconditions	5
5.1 < Postcondition One >	5
6. Extension Points	5
6.1 <Name of Extension Point>	5
Use-Case Specification: <Use-Case Name> 
[The following template is provided for a Use-Case Specification, which contains the textual properties of the use case. This document is used with a requirements management tool, such as Rational RequisitePro, for specifying and marking the requirements within the use-case properties.
The use-case diagrams can be developed in a visual modeling tool, such as Rational Rose. A use-case report, with all properties, may be generated with Rational SoDA. For more information, see the tool mentors in the Rational Unified Process.]
Use-Case Name 
Brief Description
[The description briefly conveys the role and purpose of the use case. A single paragraph will suffice for this description.]
Flow of Events
Basic Flow 
[This use case starts when the actor does something. An actor always initiates use cases. The use case describes what the actor does and what the system does in response. It is phrased in the form of a dialog between the actor and the system.
The use case describes what happens inside the system, but not how or why. If information is exchanged, be specific about what is passed back and forth. For example, it is not very illuminating to say that the actor enters customer information. It is better to say the actor enters the customer’s name and address. A Glossary of Terms is often useful to keep the complexity of the use case manageableyou may want to define things like customer information there to keep the use case from drowning in details. 
Simple alternatives may be presented within the text of the use case. If it only takes a few sentences to describe what happens when there is an alternative, do it directly within the Flow of Events section. If the alternative flow is more complex, use a separate section to describe it. For example, an Alternative Flow subsection explains how to describe more complex alternatives. 
A picture is sometimes worth a thousand words, though there is no substitute for clean, clear prose. If it improves clarity, feel free to paste graphical depictions of user interfaces, process flows or other figures into the use case. If a flow chart is useful to present a complex decision process, by all means use it! Similarly for state-dependent behavior, a state-transition diagram often clarifies the behavior of a system better than pages upon pages of text. Use the right presentation medium for your problem, but be wary of using terminology, notations or figures that your audience may not understand. Remember that your purpose is to clarify, not obscure.]
Alternative Flows
< First Alternative Flow >
[More complex alternatives are described in a separate section, referred to in the Basic Flow subsection of Flow of Events section. Think of the Alternative Flow subsections like alternative behavior each alternative flow represents alternative behavior usually due to exceptions that occur in the main flow. They may be as long as necessary to describe the events associated with the alternative behavior. When an alternative flow ends, the events of the main flow of events are resumed unless otherwise stated.]
< An Alternative Subflow >
[Alternative flows may, in turn, be divided into subsections if it improves clarity.]
< Second Alternative Flow >
[There may be, and most likely will be, a number of alternative flows in a use case. Keep each alternative flow separate to improve clarity. Using alternative flows improves the readability of the use case, as well as preventing use cases from being decomposed into hierarchies
of use cases. Keep in mind that use cases are just textual descriptions, and their main purpose is to document the behavior of a system in a clear, concise, and understandable way.]
Special Requirements
[A special requirement is typically a nonfunctional requirement that is specific to a use case, but is not easily or naturally specified in the text of the use case’s event flow. Examples of special requirements include legal and regulatory requirements, application standards, and quality attributes of the system to be built including usability, reliability, performance or supportability requirements. Additionally, other requirementssuch as operating systems and environments, compatibility requirements, and design constraintsshould be captured in this section.]
< First Special Requirement >
Preconditions
[A precondition of a use case is the state of the system that must be present prior to a use case being performed.]
< Precondition One >
Postconditions
[A postcondition of a use case is a list of possible states the system can be in immediately after a use case has finished.]
< Postcondition One >
Extension Points
[Extension points of the use case.]
<Name of Extension Point>
[Definition of the location of the extension point in the flow of events.]
<Company Name>
		<Project Name>
		Version: <1.0>
		Use-Case Specification: <Use-Case Name>
		Date: <dd/mmm/yy>
		<document identifier>
		Confidential
		Ó<Company Name>, 2013
		Page 
Doc_Especificacao_Requisitos.odt
<Project Name>
Software Requirements Specification
For <Subsystem or Feature>
Version <1.0>
[Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should be deleted before publishing the document. A paragraph entered following this style will automatically be set to normal (style=Body Text).]
[To customize automatic fields in Microsoft Word (which display a gray background when selected), select File>Properties and replace the Title, Subject and Company fields with the appropriate information for this document. After closing the dialog, automatic fields may be updated throughout the document by selecting Edit>Select All (or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must be done separately for Headers and Footers. Alt-F9 will toggle between displaying the field names and the field contents. See Word help for more information on working with fields.] 
Revision History
		Date
		Version
		Description
		Author
		<dd/mmm/yy>
		<x.x>
		<details>
		<name>
		
		
		
		
		
		
		
		
		
		
		
		
Table of Contents
1. Introduction	4
1.1 Purpose	4
1.2 Scope	4
1.3 Definitions, Acronyms, and Abbreviations	4
1.4 References	4
1.5 Overview	4
2. Overall Description	4
2.1 Use-Case Model Survey	5
2.2 Assumptions and Dependencies	5
3. Specific Requirements 	5
3.1 Use-Case Reports	5
3.2 Supplementary Requirements 	5
4. Supporting Information	5
Software Requirements Specification 
Introduction
[The introduction of the Software Requirements Specification (SRS) provides an overview of the entire document. It includes the purpose, scope, definitions, acronyms, abbreviations, references, and overview of the SRS.]
[Note: The SRS captures the complete software requirements for the system, or a portion of the system. Following is a typical SRS outline for a project using use-case modeling. This artifact consists of a package containing use cases of the use-case model and applicable Supplementary Specifications and other supporting information. For a template of an SRS not using use-case modeling, which captures all requirements in a single document, with applicable sections inserted from the Supplementary Specifications (which would no longer be needed), see the file titled rup_srs.dot.]
[Many different arrangements of an SRS are possible. Refer to [IEEE93] for further elaboration of these explanations, as well as other options for an SRS organization.]
Purpose
[Specify the purpose of this Software Requirements Specification. The SRS fully describes the external behavior of the application or subsystem identified. It also describes nonfunctional requirements, design constraints, and other factors necessary to provide a complete and comprehensive description of the requirements for the software.]
Scope
[A brief description of the software application that the Software Requirements Specification applies to, the feature or other subsystem grouping, what Use-case model(s) it is associated with, and anything else that is affected or influenced by this document.]
Definitions, Acronyms, and Abbreviations
[This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the Software Requirements Specification. This information may be provided by reference to the project’s Glossary.]
References
[This subsection provides a complete list of all documents referenced elsewhere in the Software Requirements Specification. Identify each document by title, report number (if applicable), date, and publishing organization. Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document.]
Overview
[This subsection describes what the rest of the Software Requirements Specification contains and explains how the document is organized.]
Overall Description
[This section of the Software Requirements Specification describes the general factors that affect the product and its requirements. This section does not state specific requirements. Instead, it provides a background for those requirements, which are defined in detail in Section 3, and makes them easier to understand. Include such items as product perspective, product functions, user characteristics, constraints, assumptions and dependencies, and requirements subsets.]
Use-Case Model Survey
[If using use-case modeling, this section contains an overview of the use-case model or the subset of the use-case model that is applicable for this subsystem or feature. This includes a list of names and brief descriptions of all use cases and actors, along with applicable diagrams and relationships. Refer to the Use-Case-Model Survey Report, which may be used as an enclosure at this point.]
Assumptions and Dependencies
[This section describes any key technical feasibility, subsystem or component availability, or other project related assumptions on which the viability of the software described by this Software Requirements Specification may be based.]
Specific Requirements 
[This section of the Software Requirements Specification contains all software requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements and testers to test that the system satisfies those requirements. When using use-case modeling, these requirements are captured in the use cases and the applicable supplementary specifications. If use-case modeling is not used, the outline for supplementary specifications may be inserted directly into this section.]
Use-Case Reports
[In use-case modeling, the use cases often define the majority of the functional requirements of the system, along with some non-functional requirements. For each use case in the above use-case model, or subset thereof, refer to, or enclose, the use-case report in this section. Make sure that each requirement is clearly labeled.]
Supplementary Requirements 
[Supplementary Specifications capture requirements that are not included in the use cases. The specific requirements
from the Supplementary Specifications, which are applicable to this subsystem or feature, should be included here and refined to the necessary level of detail to describe this subsystem or feature. These may be captured directly in this document or referred to as separate Supplementary Specifications, which may be used as an enclosure at this point. Make sure that each requirement is clearly labeled.]
Supporting Information
[The supporting information makes the Software Requirements Specification easier to use. It includes:
		Table of Contents
		Index
		Appendices 
These may include use-case storyboards or user-interface prototypes. When appendices are included, the Software Requirements Specification should explicitly state whether or not the appendices are to be considered part of the requirements.]
<Company Name>
		<Project Name>
		Version: <1.0>
		Software Requirements Specification
		Date: <dd/mmm/yy>
		<document identifier>
		Confidential
		<Company Name>, 2013
		Page