pleased with the multiple number of contracts for different scenarios and I also liked the advice given throughout the different manuals. You turned what would usually be a time-consuming, expensive process into an easy and affordable one that gives professional results."
MOBILE 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 Mobile Software Mobile Software B. Customer desires to have Developers develop Mobile Software for it.
C. Developers desire to develop Customers Mobile Software on the terms and conditions set forth in Exhibit attached hereto the Specifications Definitions Deliverables shall mean the Mobile 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. Mobile Software shall mean the Mobile Software program described in the Specifications that are to be developed by Developers including all Enhancements made under this Agreement. Mobile Device shall mean all hand held touch screen or other portable devices on which the Mobile Software shall operate. full list of such devices shall be contained in Exhibit B. Mobile Browser shall mean device specific browser technology which the Mobile Software shall be displayed on or run from. full list of such devices shall be contained in Exhibit B. Product shall mean Mobile 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 malfunction or defect within the Mobile Software or within Deliverable that prevents that software 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. Mobile Network shall mean any network in which connection to the Internet is delivered through to Mobile Device. Mobile Plug ins shall mean all software required by Mobile Devices in order to run the Mobile Software. Specifications shall mean the specifications for the Product and Services attached to this Agreement as Exhibit which shall include 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 Mobile 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 any document that may be viewed in its entirety on the Web. Web Site shall mean collection of interrelated Web pages or documents accessible through Web page browser interface or any other similar successor technology. Mobile Site shall mean any collection of interrelated Web Pages or documents which have been specifically created or formatted for Mobile Devices or specifically for the Mobile Software. 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 Mobile 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 Mobile Software related documentation Customer marketing material logos graphics or tag lines. Developer Code shall mean all Developers Proprietary Material or Mobile 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 Mobile Software and which are 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 Mobile 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 Mobile 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 Mobile Software. Developers agree to complete the installation management documentation and development of the Mobile Software and Mobile Software based operations according to the compensation terms listed on Exhibit attached hereto. 2. Specifications. Developers agree to develop the Mobile 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 Mobile Software and endeavor to deliver to Customer operational Mobile 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 retain the Source Code for the Mobile Software and provide Customer with the output formats only. The output is to be used only within the scope of the Mobile Software as outlined in Exhibit and does not include the following. replication duplication or otherwise copying the Mobile Software in any form not authorized by Developers; creating new Mobile Software based on the code its functions or other Proprietary Rights as outlined in Paragraph 4; 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 Mobile Software Developers shall hold all rights title and interest in and to the Mobile Software. Specifically but without limitation Developers shall hold all rights title and interest in and to all text graphics animation audio components and digital components of the Mobile 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 comprise the Mobile 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 Mobile Software or any component or characteristic thereof. Customer shall not do anything that may infringe upon or in any way undermine Developers rights title and interest in the Mobile Software as described in this Paragraph 4. Notwithstanding the above Customer shall retain and Developers 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 Mobile Software related documentation Customer marketing material logos and tag lines Customers Proprietary Material Developers agree that they shall not use Customers Proprietary Material for any purpose other than those expressly set forth in this Agreement. 5. Mobile Software Development. Mobile Software Development and Services described here are provided for Android iPhone Windows Mobile Sun and Linux Windows Macintosh Sun Solaris UNIX systems only unless otherwise specified. Insert device specific information here. Unless otherwise agreed upon by Developers and Customer any modifications required to the Mobile Software code or other component related to its operation that are result of third party changes to resources required by the Mobile 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 Mobile Software may be proposed by either Developers 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 Mobile 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 Mobile Software as well as to subsequent releases upgrades enhancements or any other versions 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 Mobile 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 their testing by written test documents delivered to Customer. Developers will submit their test plans to Customer including list of all devices the Mobile Software is to be tested on 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 this 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 Mobile Software or any enhancement thereof unless Customer and Developers agree upon such action in writing. 10. Adherence to Schedule. If Developers fail to transmit 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 or delays due to transmission equipment failure strikes riots disasters or other natural occurrences.
EXHIBIT F CONTRACT ADDENDUM THIS AGREEMENT is made this current day day of current month current year by and between company name Company and company name Customer The following requirements are made and are to be included as part of the attached contract.
ADDENDUM A. Project Change Request Insert Addendum A. Information Here ADDENDUM B. Financial Impact and Schedule Impact Insert Addendum B. Information Here Each party represents and warrants that on the date first written above they are authorized to enter into this Agreement in entirety and duly bind their respective principals by their signature below. EXECUTED as of the date first written above. company name
By signator authorized signature or signer. Job title of signator authorized signature or signer. Date when the contact was signed company name By signator authorized signature or signer. Job title of signator authorized signature or signer. Date when the contact was signed
Customer Initials Company Initials
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