POC

Your title for your proof of concept goes here.

Your full name goes here

Table of Contents  Table of Contents 1. Business Requirements 1.1. Background 1.2. Business Opportunity 1.3. Business Objectives and Success Criteria 1.4. Customer or Market Needs 1.5. Business Risks 2. Vision of the Solution 2.1. Vision Statement 2.2. Major Features 2.3. Assumptions and Dependencies 3. Scope and Limitations 3.1. Scope of Initial Release 3.2. Scope of Subsequent Releases 3.3. Limitations and Exclusions 4. Business Context 4.1. Stakeholder Profiles 4.2. Project Priorities 4.3. Operating Environment Appendices Appendix A: Prototype Layout Appendix B: Works Cited Appendix C: Gantt Chart Appendix D: Raw Data Appendix E: Project Backlog <Note: For your Table of Contents and Appendix, above, please ​generate page numbers that are clickable for the reader ​(i.e., clicking on the page number skips your reader to the section they wish to view).>

3 Proof of Concept for <Prototype Name>

1. Business Requirements

<The business requirements provide the foundation and reference for all detailed requirements development. You must gather business requirements from past research, current research (peer review articles, surveys, or questionnaires)--be sure to include data in every section.>

1.1. Background

<This section summarizes the rationale and environment for your prototype. Provide a general description of the history or situation that leads to the recognition that this prototype should be built into a product.>

1.2. Business Opportunity

<Describe the market opportunity that exists or the business problem that is being solved. Describe the market in which your prototype will be competing. This may include a brief comparative evaluation of existing prototypes and potential solutions, indicating why the proposed prototype is attractive. Identify the problems that cannot currently be solved without the proposed prototype (based on your data), and how the prototype fits in with market trends or your strategic directions.>

1.3. Business Objectives and Success Criteria

<Describe the important business objectives of the prototype in a way that is ​quantitative and measurable ​. The value provided to customers is described in section 1.4, so this section should focus on the value provided to your business. Determine how success will be defined and measured on this project, and describe the factors that are likely to have the greatest impact on achieving that success. Include things within your direct control, as well as external factors. Establish measurable criteria to assess whether your SMART objectives have been met.>

1.4. Customer or Market Needs

<Describe the needs of typical customers or market segments, including needs that are not yet met by the marketplace or by existing prototypes. You may wish to describe problems customers currently encounter that the new prototype will (AND will not--remember scope) address; address how the prototype would be used by customers. Identify needed customer hardware and software environments in which the prototype must operate. Define at a high level any known critical interface or performance requirements. Present the requirements in a numbered list so that more detailed user or functional requirements can be traced to them.>

1.5. Business Risks

<Summarize the major business risks associated with developing this prototype, such as marketplace competition, timing issues, user acceptance, implementation issues, or possible negative impacts to your business (career). Estimate the severity of the risks and identify any risk mitigation actions that could be taken.>

2. Vision of the Solution

<This section establishes a long-term vision for the system to be built that addresses your SMART objectives. This vision will provide the context for making decisions throughout the course of the prototype

4 Proof of Concept for <Prototype Name>

development life cycle (WHAT IS THE LIFECYCLE OF YOUR PROJECT?). The vision should not include detailed functional requirements or project planning information.>

2.1. Vision Statement

<Write a concise vision statement that summarizes the purpose and intent of the new prototype and describes what the world will be like when it includes the prototype. The vision statement should reflect a balanced view that will satisfy the needs of diverse customers. It may be somewhat idealistic, but it should be grounded in the realities of existing or anticipated customer markets, enterprise architectures, organizational strategic directions, and cost and resource limitations.>

2.2. Major Features

<Include a numbered list of the major features of the new prototype, emphasizing those features that distinguish it from previous or competing prototypes. Specific user requirements and functional requirements may be traced back to these features.>

2.3. Assumptions and Dependencies

<Record any assumptions that were made when conceiving the project and writing this Proof of Concept document. Note any major dependencies the project must rely upon for success, such as specific technologies, third-party vendors, development partners, or other business relationships.>

3. Scope and Limitations

<The project scope defines the concept and range of the proposed solution. It’s also important to define what will ​not​ be included in the prototype. Clarifying the scope and limitations helps to establish realistic expectations of the many stakeholders. It also provides a reference frame against which proposed features and requirements changes can be evaluated. Proposed requirements that are out of scope for the envisioned prototype must be rejected, unless they are so beneficial that the scope should be enlarged to accommodate them (with accompanying changes in budget, schedule, and/or resources).>

3.1. Scope of Initial Release

<Describe the intended major features that will be included in the initial release of the prototype. Consider the benefits the prototype is intended to bring to the various customer communities, and generally describe the prototype features and quality characteristics that will enable it to provide those benefits. Avoid the temptation to include every possible feature that any potential customer category might conceivably want some day. Focus on those features and prototype characteristics that will provide the most value, at the most acceptable development cost, to the broadest community.>

3.2. Scope of Subsequent Releases

<If a staged evolution of the prototype is envisioned over time, indicate which major features will be deferred to later releases. All projects and products have subsequent releases. Remember, Prototype + POC = PRODUCT>

3.3. Limitations and Exclusions

<Identify any prototype features or characteristics that a stakeholder might anticipate, but which are not planned to be included in the new prototype. REMEMBER your SCOPE. What you will include, what you won’t include, and why you won’t include what you say you won’t include.>

5 Proof of Concept for <Prototype Name>

4. Business Context

<This section summarizes some of the business issues around the project, including profiles of major customer categories, assumptions that went into the project concept, and the management priorities for the project.>

4.1. Stakeholder Profiles

<Stakeholders are individuals, groups, or organizations that are actively involved in a project, are affected by its outcome, or can influence its outcome. The stakeholder profiles identify the customers for this prototype and other stakeholders, and states their major interests in the prototype. Characterize business-level customers, target market segments, and different user classes, to reduce the likelihood of unexpected requirements surfacing later that cannot be accommodated because of schedule or scope constraints. For each stakeholder category, the profile includes the major value or benefits they will receive from the prototype, their likely attitudes toward the prototype, major features and characteristics of interest, and any known constraints that must be accommodated. Examples of stakeholder values include: ● improved prototypetivity ● reduced rework ● cost savings ● streamlined business processes ● automation of previously manual tasks ● ability to perform entirely new tasks or functions ● conformance to current standards or regulations ● improved usability or reduced frustration level compared to current applications

4.2. Project Priorities

<Describe the priorities among the project’s requirements, schedule, and budget. Identify the parameters around the project’s key drivers (top priority objectives that are set by YOU), constraints to work within, and dimensions that can be balanced against each other to achieve the drivers within the known constraints. ​The ​project driver ​ is a person or team who is responsible for setting the direction for the project​. The ​driver ​ can set goals, approve bug targeting, or set backporting for any major series in the project​. Alternatively, you can select to leave the ​project driver ​ unset and appoint a team (Agile self-directed teams) for each series. ​Enablers​ are employees of an organization, customers, suppliers ,  advisors and technologies.​>

4.3. Operating Environment

<Describe the environment in which the system will be used and define (in detail) the major availability, reliability, performance, and integrity requirements. This information will significantly influence the definition of the system’s architecture. Consider questions such as (please touch on all of these areas in your POC): ● Are the users widely distributed geographically or located close to each other? How many time zones

are they in? ● When do the users in various locations need to access the system? ● Where is the data generated and used? How far apart are these locations? Does the data from

multiple locations need to be combined? ● Are specific maximum response times known for accessing data that might be stored remotely?

6 Proof of Concept for <Prototype Name>

● Can the users tolerate service interruptions or is continuous access to the system critical for the

operation of their business? ● What access security controls and data protection requirements are needed?>

7 Proof of Concept for <Prototype Name>

<Tables are labeled at the top of the table and figures are labeled at the bottom of the figure. Each title uses a hanging indent.

Table 1 ​. This is an example of a very long title that you would place at the top of your table using a hanging indent style.

Figure 1 ​. This is an example of a very long title that you would place on/at the bottom of your figure using a hanging indent style.

All tables and figures are sourced on the bottom. Source:​ www.sjsu.edu/cs100w (We will cover creating tables and figures in lecture)> Appendix A: Prototype Layout Appendix B: Works Cited Appendix C: Gantt Chart Appendix D: Raw Data Appendix E: Project Backlog