Template for Charter Document – Software Engineering Capstone Project

Version 2020-1

This is the template for the project Charter Document. Make a copy of it and rename the file XXX_Project_Charter_v1.docx where XXX is the name of the project. Then, edit the document according to the directions below.

If the document needs to be modified or updated during the course of the project, create a new version of it (v2, v3, etc. in the name of the file) and summarize the changes in the versions tracking table below. Don’t forget to update the document version number in the page headers. When turning in the Charter Document for grading, submit two printed copies of it (in color if necessary) bound or in a binder.

How to use this template:

All text in black – must be left as is.

All text in <red between angle brackets> must be replaced with appropriate text in black (and without the angle brackets)

All text in blue italics are instructions or examples and must be removed from the document.

Paragraphs inside a blue shaded box are instructions and must be removed from the document (including the boxes on this page).

Do not delete sections or paragraphs from the document.

- Any section that is not applicable to the project should be filled in with “Not applicable”

- Any section that is undecided should be filled in with “To be decided” or “TBD”

Keep the document’s styles and format (including full justification), in particular the styles for “Normal”, Headings 1, 2, 3, “Caption”, and TOC 1, 2, 3.

Keep the document header and footer, including page numbers

All figures must be accompanied by a number and a descriptive caption beneath them. Example caption: Figure 5: Flow Chart. We recommend using the automatic numbering features of MS Word (using the Caption style). Make sure all figures are readable and clear!

All tables must be accompanied by a number and a descriptive caption above them. Example caption: Table 2: Project Participants. We recommend using the automatic numbering features of MS Word (using the Caption style).

Create the table of contents, list of figures, and list of tables using the automatic generation feature of MS Word.

Content from external programs, external documents, or source code can be included in the document using one of the following methods:

Copy/Paste the content into the appropriate place in the document

Add the content as an appendix at the end of the document (number the appendix and include it in the table of contents), e.g. Section 7: Algorithm for Calculating X. Reference the appendix in the appropriate place in the document.

Put the content in a separate file and submit it with the project (add the file to the list of references below), e.g. ABC-Testing-Plan.docx. Reference the file in the appropriate place in the document.

<Project Name> Project

Software Engineering Department

Achi Racov School of Engineering

Kinneret Academic College

<Year> Academic Year

Charter Document

Version <Version number>

Submission Date: <Date>

Project Team
<Student Name>, ID <ID Number>, <Department/Major> <Student Name>, ID <ID Number>, <Department/Major>
Customer
<Name of the company/organization/person for whom the project is to be performed>
Industrial Advisor(s)
<Industrial Advisor Name>, <Position>, <Company or organization> <Industrial Advisor Name>, <Position>, <Company or organization>
Academic Advisor(s)
<Academic Advisor>, <Department>, <Institution> <Academic Advisor>, <Department>, <Institution>

List of versions of this document. After every major change, submission, or feedback from an advisor, increase the version number, write the date, and summarize the changes from the previous version.
Versions Table

Version	Date	Summary of changes from previous version
1	Initial version

Table of Contents

This table of contents is generated automatically by MS Word. Update it every time you make a change to the document. You can update it by right clicking on the table of contents and selecting “Update Field”.

1	Project Background	7

2	Project Properties	7

2.1	Project Goals	7

2.2	Project Deliverables	8

2.3	Development Lifecycle Model	8

2.4	Project Test Plan	8

2.4.1	Unit Tests	8

2.4.2	Software Integration Tests	8

2.4.3	Software and Hardware Integration Tests	8

2.4.4	Acceptance Tests	9

2.4.5	Validation Tests (Beta Testing)	9

2.5	Project Schedule and Work Plan	9

2.6	Project Stakeholders	10

2.7	Primary Risks	10

3	Theoretical Background	11

3.1	Existing State	11

3.2	Similar Systems	11

4	Technical Attributes	12

4.1	Primary Requirements	12

4.2	Implementation Attributes	12

4.3	Solution Attributes	13

4.4	Primary Interfaces	13

4.5	Development and Implementation Tools	13

4.5.1	Development and Testing Environment Elements	13

4.5.2	Production Environment Elements	14

5	References	14

List of Figures

The list of figures is generated automatically by MS Word. Update it every time you make a change to the document. You can update it by right clicking on the table of contents and selecting “Update Field”.

Figure 1: System Environment	7

Figure 2: Gantt Chart	10

List of Tables

The list of tables is generated automatically by MS Word. Update it every time you make a change to the document. You can update it by right clicking on the table of contents and selecting “Update Field”.

Table 1: Project Stakeholders	10

Table 2: Project Risks	11

Table 3: Primary Requirements	12

Project Background

This document defines the <Project Name> project that was approved to be performed (see reference [1]). It contains the steps that will be done to implement the project.

Text, between 1 and 3 pages long that details the project background, including:

Existing state: The organizational/business environment into which the project will be integrated, the customer’s organizational structure (if the customer is a department or team within a larger organization, explain the customer’s place and role and how it works with other departments or organizational units), the important business processes in the environment, and an explanation of how the processes work without the proposed system.

Business need: Why is the customer interested in the project? What benefit will the customer will derive from it? What are the problems to be solved?

A schematic diagram that shows the environment/existing system (for instance, computing systems, existing hardware, existing software) and the points where the system to be developed will integrate into the environment/system.

System Environment

Figure 1: System Environment

Project Attributes

Project Goals

1-3 primary goals that the project must achieve. Examples: creating a web site for…, creating an information system for…, building a functional library suite for…, writing a software implementation of…

<Goal 1>

<Goal 2>

<Goal 3>

Project Deliverables

A numbered list of deliverables to be produced. Examples: source code, HTML/ASP code, DLLs, user manual, specification document, test document. Include all required academic project deliverables: Charter, Specification & Design, Final Report.

Development Lifecycle Model

What software development lifecycle model will you use? Examples: waterfall with one delivery, iterative with multiple deliveries (how many?), agile with deliveries every X weeks.

Project Test Plan

List how the tests will be done at the various testing levels. Give as much detail as you know now about what rounds of tests will be done, what test environments will be used, and the manner of the tests (manual/automatic). Ensure your testing plan matches the customer’s organizational practices. You do not need to give a lot of detail about unit tests, but you must give sufficient details about acceptance tests. Other testing levels will be as per the customer’s requirements.

Note: You do not need to list the actual tests here. Instead, give the testing approach and plans for how testing will be done later.

Unit Tests

<How unit testing will be done>

Software Integration Tests

<How software integration testing will be done>

These are tests between different project modules, including software from external sources or existing libraries/tools.

Software and Hardware Integration Tests

<How the software will be tested on the target hardware>

If the project does not have specific hardware requirements and the production environment is meant to be platform independent (e.g. a web service) you may mark this section “Not Applicable” and briefly explain why.

Acceptance Tests

<How will acceptance testing be done>

Acceptance tests are ones that the customer uses to determine whether the project was successful or not. They are required for the results of the project to be approved for use.

Validation Tests (Beta Testing)

<How will validation be done>

Validation testing is done by giving the product to end users in the production environment and receiving feedback from them. If the project will not include validation tests, explain why.

Project Schedule and Work Plan

A Gantt figure created with MS Project that details the tasks required to complete the project (Work Breakdown Structure - WBS), the dependencies between them, and the expected timeline for completion.

In addition to the project tasks (planning, development, testing, etc.), include college project milestones, including:

Project proposal

Proposal approval

Charter completion

Specification & Design completion

Final Report completion

Project defense

Poster creation and editing

Final submission

Important: The Gantt reflects the initial project plan. Do not update it after the Charter document has been completed and submitted (the date shown it the Gantt for Charter completion). The Final Report document contains a place to put the final (actual) project timeline (another Gantt).

Gantt Chart

Figure 2: Gantt Chart

Project Stakeholders

A list of users, advisors, company engineers, consultants, administrators of other systems, or other bodies/organizations that have an influence on the project or who are influenced by it. Examples: standards bodies, regulatory agencies, business processes, security functions.

For industrial projects, do not include academic advisors or academic bodies that are external to the project, whose sole task is academic oversight, and who do not influence and are not influenced by the system.

Table 1lists the project stakeholders.

Table 1: Project Stakeholders

Stakeholder/Organization Name	Role/Function	Manner of Involvement in the Project
Example: Joe Smith	Chief Security Officer	Approves classification/security attributes of the project
Example: National Laws	Accessibility Laws	Provides guidance for system accessibility standards for handicapped users

Main Risks

List of 3-5 events that may cause the project to not be successful. For each event, estimate the probability of its occurrence (in percent), the influence it would likely have on the project (e.g., delivery delayed by X weeks), and actions to be done to mitigate or avoid the risk.

Table 2below lists the main risks for the project.

Table 2: Project Risks

Risk (Event)	Probability	Influence	Actions to mitigate/avoid the risk
Example: The company changes one of the systems that connects to the project	25%	Changes to the project contents and interfaces	We will use generic or multipurpose interfaces for external systems

Theoretical Background

This section contains background information necessary to understand the project, its contents, and implementation.

Existing State

Information about and a description of the existing systems, accepted formats, protocols, standards, etc. the customer has or uses that will affect the project’s planning and implementation. Include references to the standards and documents in the References section (including URLs if appropriate). List the titles and roles of such systems, protocols, standards, etc. and include a numbered reference to them from the References section between square brackets (e.g. RFC 3514 [3] defines the bit format we will use…).

Similar Systems

Information about existing solutions to problems similar to the ones that will be addressed by the project (e.g., design patterns, published documentation, previous projects), even if such solutions are not currently used by the customer. If the chosen solution for this project is different from the ones previously published, explain why the existing solutions were not chosen. If there are solutions on the market that address the project’s goals, explain why the customer chose to develop the project and not use the existing solutions.

Technical Attributes

High-Level Requirements

A numbered list of the high-level requirements for the project (normally 8-12). Fill in all table columns. A list of detailed requirements will be in Specification & Design document.

Table 3 details the high-level project requirements.

Table 3: High-Level Requirements

#	Requirement	Type (F/NF)	Critical (Y/N)	Priority (H/M/L)	Difficulty (H/M/L)
Critical requirements should be between one third and half of all requirements	Ensure that priority is distributed evenly over the requirements	A large number of requirements with H difficulty makes the project riskier

Type: F = Functional requirement, NF = Non-functional requirement (e.g. reliability, availability, information security, etc.)
Critical: Fulfilling all critical requirements is required to complete the project.
Priority: How important is it to address the requirement in the project’s timetable. H = High, M = Medium, L = Low
Difficulty: H = High, M = Medium, L = Low.

Implementation Attributes

Explain if the planned solution is:

Entirely new, without any connection to existing systems

New, but connected somehow to existing systems (briefly explain the existing system)

An extension of an existing system (briefly explain the existing system)

New, but similar to another system, (e.g., one that already exists at the organization) (briefly explain the existing system)

Combines elements or subsystems that were previously created by the organization or were created in previous projects

Combines elements or subsystems from external sources (e.g., off-the-shelf commercial products, open source libraries or modules)

Note: If you plan to use existing systems or components, you may reuse requirements, design, and code from them if that is permitted by intellectual property and licensing rules. Check them first!

Solution Attributes

List the primary attributers of the solution with respect to the following issues (as applicable):

Platform: specialized hardware, stand-alone computer, smartphone, local area network, internet, etc.

Architecture: centralized, distributed, client/server, cloud based, Service Oriented Architecture (SOA), etc.

Operating system

Information security level (scale of 1 to 10, where 10 is the highest). Is the system going to be accessible to other departments of the organization? Will it serve the general public?

Additional attributes as necessary

Primary Interfaces

Based on the figure in section 1, list (at a high level, don’t go into too much detail here) the primary interfaces for the system/solution:

Human-computer interface

Interfaces with other systems/components in the production environment

Interfaces with other systems/components in the development environment (simulators, testing tools, etc.)

Development and Implementation Tools

Development and Testing Environment Elements

List the hardware (e.g., computers, servers, communication equipment, networks, specialized hardware) and software (e.g., MS Office programs, configuration management tools, modeling tools, compilers, debuggers, testing tools) that will be needed during the development of the solution.

Production Environment Elements

List the hardware (e.g., computers, servers, communication equipment, networks, specialized hardware, etc.) and software (e.g., helper applications, operating systems, run time libraries/DLLs, etc.) that will be needed for the installation and operation of the solution

References

A numbered list of documents and other sources using full bibliographical entries (use APA or IEEE style). Every time one of the documents is mentioned in the body of the Charter, cite the document using the source’s number between square brackets (e.g. [3]). You may use MS Word’s “Manage Sources” feature to do this automatically. If the reference is an external document, some associated documentation, or an external resource (excluding websites or online resources), include a copy of the reference in the project submission package as well.

Project proposal form for <Project Name> project, signed and approved. <date>