Legal Contract Templates Software Development Contract

How do you write a Software Development Contract document?

COMPUTER SOFTWARE DEVELOPMENT AGREEMENT THIS AGREEMENT is made this current day day of current month current year by and between company name Developers and company name Customer Recitals A. Developers have experience and expertise in the development of Computer Software Software B. Customer desires to have Developers develop Software for them. C. Developers desire to develop Customers Software on the terms and conditions set forth in Exhibit attached hereto the Specifications Definitions Deliverables shall mean the Software provided in object and or source format as set forth in the Specifications and subject to Developers Proprietary Rights documentation or other materials required to be delivered by Developers to Customer as set forth in the Specifications. Critical Deliverables shall mean Deliverables that have Milestone date as outlined in the Specifications that must be transmitted to Customer on or before specific date.

Source Code shall mean the readable forms together with make and build files. Beta shall mean any and all Deliverables provided to Customer prior to the Launch Date. Final shall mean any and all Deliverables provided to Customer that are in accordance with the Specifications and accepted by Customer as completion of particular Deliverable. Launch Date shall mean the date that the Product is first available for use by the public. Software shall mean the computer software program described in the Specifications that is to be developed by Developers including all Enhancements made under this Agreement. Product shall mean software for computer or an end user. Schedule shall mean the schedule for completion of the Deliverables as set forth in the Specifications. Delivery shall mean transmitted by Developers to Customers electronically and in accordance with security measures agreed upon by both parties in accordance with the Specifications.

Services shall mean any training customization enhancement or other labor performed by Developers as required by the Specifications. Error shall mean malfunctions or defect within the Software or Deliverable that prevents it from conforming to the Specifications. Internet shall mean any system for distributing digital or electronic information to end users via transmission broadcast or any other form of delivery whether direct or indirect known or subsequently developed. Specifications shall mean the specifications for the Product and Services as detailed and attached to this Agreement as Exhibit that includes detailed specifications and instructions for all required Deliverables features and functionality and complete production schedule for each Deliverable and Milestone. Term shall mean the period of time commencing on the Effective Date of this Agreement and continuing indefinitely until this Agreement is terminated. User Interface shall mean all navigational devices menus menu structures or arrangements icons visual mechanisms metaphors or help and other operational instructions and all other components of any source or object computer code that comprises the Software. Web shall mean the World Wide Web containing pages written in hypertext markup language HTML and or any similar successor technology. Web Page shall mean document that may be viewed in its entirety on the Web.

Web Site shall mean collection of inter related Web pages or documents accessible through Web page browser interface or any other similar successor technology. Developers Proprietary Material shall mean all intellectual property rights in any text images or other components and or materials owned by Developers or which Developers have the legal right to use that are delivered to Customer including but not limited to software related documentation source code scripts object code logos graphics or tag lines. Customers Proprietary Material shall mean all intellectual property rights in any text images or other components and or materials owned by Customer or which Customer has the legal right to use that are delivered to Developers including but not limited to software related documentation Customer marketing material logos graphics or tag lines. Developer Code shall mean all Developers Proprietary Material or software Source Code existing as of the date of this Agreement that is to be incorporated into the Source Code of the Product. The license terms for Developer Code will be stated in the Specifications. Documentation shall mean all user guides reference integration installation or implementation manuals that describe in detail the operation of the Software that is normally provided by Developer as part of its deliveries to its customers.

Development Activities shall mean any activities undertaken by Developer in the development of the Software and Documentation satisfying the Specifications pursuant to this Agreement. Enhancements shall mean error corrections bug fixes modifications and updates not included in the Specifications with respect to the Software. Milestone shall mean each development or Deliverable reached by Developers and agreed upon in writing between Developers and Customer. Milestone Payment shall mean payment obligation related to the achievement and acceptance of particular Milestone. Acceptance shall mean completion of Deliverable that conforms to the Specifications and is mutually agreed upon in writing by both Developers and Customer. Agreements In consideration of the mutual covenants set forth in this Agreement Customer and Developers hereby agree as follows.

1. Development of Software. Developers agree to installation management documentation and development of the Software and Software based operations according to the compensation terms listed on Exhibit attached hereto. 2. Specifications. Developers agree to develop the Software pursuant to the Specifications set forth in Exhibit attached hereto the Specifications 3. Delivery Dates and Milestones. Developers will use reasonable diligence in the development of the Software and endeavor to deliver to Customer operational Software no later than delivery date. Customer acknowledges however that this delivery deadline and the other payment milestones listed in Exhibit are estimates and are not required delivery dates unless otherwise noted in the Specifications. Deliverables defined as Critical Deliverables shall be outlined in Exhibit and shall contain the delivery date and terms of delivery of the Critical Deliverable. Developers will be retaining the Source Code for the Software and providing Customer with the output formats only. The output is to be used only within the scope of the Software as outlined in Exhibit and does not include the following. replication duplication or otherwise copying the Software in any form not authorized by Developers creating new Software based on the code its functions or other Proprietary Rights as outlined in Paragraph sale or distribution of the code in any form or any relinquishment of copyright by Developers in any way. 4. Ownership Rights. Except for Customers Proprietary Material defined below contained in the Software Developers shall hold all right title and interest in and to the Software. Specifically but without limitation Developer shall hold all right title and interest in and to all text graphics animation audio components and digital components of the Software the Content all interfaces navigational devices menus menu structures or arrangements icons help and other operational instructions and all other components of any source or object computer code that comprises the Software all literal and nonliteral expressions of ideas that operate cause create direct manipulate access or otherwise affect the Content and all copyrights patents trade secrets and other intellectual or industrial property rights in the Software or any component or characteristic thereof. Customer shall not do anything that may infringe upon or in any way undermine Developers right title and interest in the Software as described in this Paragraph 4. Notwithstanding the above Customer shall retain and Developer shall have no Proprietary Rights whatsoever in all of Customers intellectual property rights in any and all text images or other components and or materials owned by Customer or which Customer has the legal right to use that are delivered to Developers including but not limited to software related documentation Customer marketing material logos and tag lines Customers Proprietary Material Developers agree that it shall not use Customers Proprietary Material for any other purpose than those expressly set forth in this Agreement.

5. Software Development. Software Development and Services described here are provided for Linux Windows Macintosh Sun Solaris UNIX systems only unless otherwise specified. Unless otherwise agreed upon by Developers and Customer any modifications required to the Software code or other component related to its operation that are result of third party changes to resources required by the Software shall be considered ADDITIONAL and will fall outside of the Specifications. Third party modifications may include but are not limited to. patches fixes security flaws errors updates upgrades or any other changes to third party operating systems plug ins or any required resources not created by Developers. 6. Specific Enhancements. Developers and Customer acknowledge that at some time during the Term of this Agreement that enhancements to the Software may be proposed by either Developer or Customer which fall outside of the scope of the Specifications. Upon such proposal Developers shall confer in good faith with Customer concerning the feasibility of developing such enhancements and the time frame for developing testing and incorporating such enhancements. Developers and Customer shall mutually agree in writing as to whether Developers shall pursue the development of such enhancements and if so which party will fund such development. The Specifications will be amended to include such enhancements. 7. Backups and Redundancies for Development.

Developers will maintain off site storage of all stages of the Source Code and other backup media related to this Agreement to ensure Software integrity and protection and will be responsible for setting up daily procedure for backing up all data. Developers agree to update all backups of code on daily basis unless otherwise agreed upon in the Specifications. Backups will be maintained for one year from the acceptance date of the project. 8. Acceptance. The terms and conditions contained in this Section will apply to the initial release of the Software as well as to subsequent release upgrades enhancements or any other version thereof. Customer shall evaluate any beta or final version of each Deliverable and shall submit an acceptance or rejection to Developers within days days after Customers receipt of an agreed upon transmission of each Deliverable. 9. Testing and Quality Assurance. Developers agree to thoroughly test the Software Product including without limitation each and every release version and enhancement thereof as appropriate under the circumstances at all appropriate stages of development and shall document its testing by written test documents delivered to Customer. Developers will submit its test plans to Customer so as to ensure that Customers standards of quality are maintained and Developers agree to subsequently modify the test plans to accommodate Customers requests if Customer reasonably deems necessary. Quality Assurance or test documentation shall include detailed descriptions of the tests conducted their results and any outstanding or unresolved issues. Developers will not deploy the Product Software or any enhancement thereof unless Customer and Developers agree upon such action in writing. 10. Adherence to Schedule.

If Developers fail transmission of any Critical Deliverable within the dates specified in the Schedule or fail to meet Milestone as defined in the Specifications then Breach of Agreement Breach shall be considered to have occurred. Customer may. amend the Schedule to include correction period; or suspend the Schedule until the problem is corrected at the sole expense of Developers subject to Customers reasonable satisfaction; or terminate this Agreement. Delivery of all Deliverables not defined in the Specifications as Critical Deliverables shall be considered estimates and delivery shall not be subject to Breach. Developers shall not be held responsible for any delays due to. milestones missed by Customer delays due to Customer Deliverables delays due to transmission equipment failure strikes riots disasters or other natural occurrences. 11. Support Services. Developers will be available to respond to Customers questions about Software and Software problems. Developers will staff help desk with combination of phone and email support services from 9. am to 5. pm Monday through Friday time zone. Developers will be responsible for maintaining an ongoing log of support requests actions taken and track user support requests to completion. 12. Compensation. For all of Developers services under this Agreement Customer shall compensate Developers in cash pursuant to the terms of Exhibit attached hereto. In the event Customer fails to make any of the payments referenced in Exhibit by the deadline set forth in Exhibit Developers have the right but are not obligated to pursue any or all of the following remedies. terminate the Agreement remove equipment owned by Developers whether leased to Customer by Developers or not and any Developers Personnel or Staff from Customer location bring legal action or Customer may suspend development of the Software and is responsible for any schedule changes required and additional financial impact. 13. Confidentiality. Customer and Developers acknowledge and agree that the Specifications and all other documents and information related to the development of the Software the Confidential Information will constitute valuable trade secrets of Developers. Customer shall keep the Confidential Information in confidence and shall not at any time during or after the term of this Agreement without Developers prior written consent disclose or otherwise make available to anyone either directly or indirectly all or any part of the Confidential Information. 14. Limited Warranty and Limitation on Damages.

Writing the Software Requirements Specifications document (alternate or related contract document)

Software Requirements Specification SRS THE SRS PROJECT DOCUMENT TITLE Author Title company name

current date Document Version Control Information V 1. 0 1. Introduction. 1 Purpose of This Document. Insert the purpose of this document and its intended audience. 1 Scope of Document. Insert description of the scope of this Software Requirement Specification

1. 21 Scope Constraints. Insert constraints such as schedules costs interactions overview or any other information relevant to the construction of the development requirements. 1 Overview. Insert an overview or brief description of the product software or other desired end result. 1 Business Context. Insert an overview of the business or organization desiring the development of this project. Include the business or organizations mission statement and its organizational goals and objectives. 2. General Description. 2 Product Functions.

Insert description of the functionality of the product. 2 Similar System Information. Insert description of the relationship between this product and any other product or product ; whether the product shall be stand alone product or whether the product shall be used as component or to support another program or programs. This section is intended to discuss the relationships between the above mentioned items. 2 User Characteristics. Insert description of the characteristics of the typical user or user community that this product serves or will serve. Include features that the user or user community currently uses or expects. Include current relevant features and describe the expected experience level and familiarity with similar software systems applications or other programs and program use. 2 User Problem Statement.

Insert user problem statement that describes the essential problem currently being faced by the intended user community. 2 User Objectives. Insert the objectives and requirements for the product from the users perspective. The user objectives section may also include wish list of features or functionality that the user want and how that relates to the business context 2 General Constraints. Insert the general constraints placed upon the developers including hardware requirements schedule requirements industry protocols or standards to be met or any other constraint placed upon the development of the product. 3. Functional Requirements. This section describes the functional requirements ranked in order of importance. Here you will describe what the product must accomplish; what other component requirements must accomplish; the requirements for Interface Scalability Performance Compatibility or other components of the product; and how the product fulfills these requirements. Each functional requirement should be specified in format similar to the following. Functional Requirement #1 Name

3 Description. complete description of the functional requirement. 3 Criticality. description of how critical this functional requirement is to the overall product. 3 Technical Issues. description of issues related to the design development or integration of this functional requirement. 3 Cost Summary and Schedules. description of the costs and timelines associated with this functional requirement.

3 Risks. description of the risks and possible circumstances under which this functional requirement may not be able to be met. Include provisions the developers must take in order to overcome this risk. 3 Dependencies with other requirements. description of the various interactions between this requirement and other functional requirements. Here you will insert statements concerning the impact of these dependencies and the impact on the ranking of requirements. Functional Requirement #2 Name Repeat the section above for more requirements. 4. Interface Requirements. This section describes both how the product will interface with other software products or dependencies or with end users for input and output.

4 User Interfaces. Describes how this the end user interfaces with the product. 4. Graphical User Interface GUI. Describes the graphical user interface or whether another system is required to provide the GUI. Include mock ups or screenshots of the user interface features. Describe all navigation systems hierarchy of menus sub menus buttons and all other relevant GUI features of the product. 4. Command Line Interface CLI. Describes the command line interface if present. For each command description of all arguments and example values and invocations should be provided. 4. Application Programming Interface API. Describes the application programming interface if present. For each public interface function the name arguments return values examples of invocation and interactions with other functions should be provided.

4. Debugging and Diagnostics. Describes the process required for the product to return troubleshooting debugging or other diagnostic data and feedback. 4 Hardware Interfaces. description of all interfaces to hardware or hardware devices. 4 Communications Interfaces.

description of all communication and network interfaces. 4 Software Interfaces. description of all software interfaces. 5. Performance Requirements. Insert specific performance requirements. 6. Design Constraints. Insert specific design constraints including compliance with specific standards and constraints on design due to hardware limitations.

7. Other Non Functional Attributes. A description of other non functional attributes required by the product. Examples. 7 Security. Insert the attributes description here. 7 Binary Compatibility. Insert the attributes description here.

7 Reliability. Insert the attributes description here. 7 Maintainability. Insert the attributes description here. 7 Portability. Insert the attributes description here.

7 Extensibility. Insert the attributes description here. 7 Reusability. Insert the attributes description here. 7 Application Compatibility. Insert the attributes description here.

7 Resource Utilization. Insert the attributes description here. 7. 10 Serviceability. Insert the attributes description here. 8. Preliminary Object Oriented Domain Analysis. A description or list of the fundamental objects required to be modeled within the product in order to satisfy its requirements. The goal is to create structural view on the requirements and how they may be satisfied. This section deals primarily with higher level programming and functional requirements AND may be safely omitted for projects not concerned with Object Oriented Domain Analysis OODA. This section should not be removed from your SRS Document. Instead you should include an entry such as. No Object Oriented Domain Analysis Requirement. 8 Inheritance Relationships.

description of primary inheritance hierarchy. Include diagrams graphs or other UML examples to further illustrate such relationships. 8 Class descriptions. description of each class identified during the OODA. Include more detailed description of each class. The description of each class should be organized as follows. 8. Insert the Class name identifier 8. 2. Abstract or Concrete. Indicates whether this class is abstract designed only as parent from which subclasses may be derived or concrete suitable to be instantiated.

8. 2. List of Superclasses. Lists the class from which another class subclass inherits. 8. 2. List of Subclasses. Lists the class that is derived from base class by inheritance. The new class contains all the features of the base class but may have new features added or existing features redefined. 8. 2. Purpose. Lists the purpose of the class. 8. 2. Collaborations. Lists the names of each class that this class must interact with and how it must interact in order to accomplish its purpose. 8. 2. Attributes.

Lists each attribute associated with each instance of this class and indicates examples of possible values or range of values. 8. 2. Operations. Lists each operation able to be invoked upon instances of this class. 8. 2. Constraints. Lists the constraints and restrictions upon the behavior of instances of this class. 9. Operational Scenarios. description of the various scenarios that an end user may experience when using the product under certain conditions or situations. Scenarios are not considered to be functional requirements rather they are used to help set parameters and expectations for the use of the product under these conditions or situations. 10. Preliminary Schedule.

description of the project schedule and timeline for completion. The project plan should include all major tasks who is responsible for the completion of such tasks what the interdependencies of each task are and what the start and completion of each task will be. You should also include vendor information and requirements of such that affect the schedule and timeline. 11. Preliminary Budget. description of the cost summary and an attachment of the initial line item and itemized budget for the project. 12. Appendices. A description of all other supporting information for understanding these requirements. All SRS documents require the following two appendices. 12 Definitions Acronyms Abbreviations.

description of the definitions of important terms abbreviations and acronyms. May also include Glossary. 12 References. listing of all citations to all documents and meetings referenced or used in the preparation of this requirements document. Customer Initials Developers Initials