The first step in the development process is to submit an approved project proposal (the process for developing an approved proposal that meets the criteria and sets priorities for development is not covered within this document). The proposal should describe clearly what the project or service is – what problem is being solved, what the constraints are on the solution, what approach will be taken, what existing technologies may be used as a starting point, how the project will affect other systems, applications, services, etc.

The Learning Environments Tech Team and developers require the following information to be included when any project is submitted. Click here to download the form

Section 1: Identification

Title:

Summary:

Sponsoring organization (campus, department, etc.) :

Project Sponsor:
Contact phone:
Contact e-mail:
Association to sponsoring organization:

Project Lead (must be from within submitting group) :
Contact phone:
Contact e-mail:

Section 2: Request

Detailed project description:
What is the target (SLN, IPCC, SLN Request, web site)?

Use case(s):
What will this request provide the organization, sponsor, submitter and/or users? How will they use it?

Redundancy:
Why don't existing systems, applications, products or services meet this need?

Relationships:
Current, or in development, systems, applications, projects, products or services that the request project will affect once correct and complete.

Dependencies:
Current, or in development, systems, applications, projects, products or services that the request project will rely upon for correct and complete functionality.

Regression:
Will any of the dependant or related systems, applications, products or services be rendered obsolete, deprecated, or in need of revision as a result of this work?

Schedule:
What is the timeframe for deployment?

Key Dates:
Are there any specific events related to this project?

Section 3: Requirements

Requirements should be provided through contracting, prototyping and use cases. Requirements analysis can be a long and arduous process. Requirements specialists do their work by talking to people, documenting their findings, analyzing the collected information to discover inconsistencies and oversights, and then talking to people again. This process can go on for a while, and may continue throughout the life cycle of a system.

New systems change the environment and relationships between people, so it is important to identify all the stakeholders, make sure you take into account all their needs; and ensure they understand the implications of the new systems. Frequently, this objective is not met because:

• there is not enough talking, and important needs are overlooked when the system is implemented; and/or
• there is not enough descriptive feedback, and the users are disappointed by the new system's characteristics.

To keep all these discussions well organized and efficient, the evolving requirements must be documented.

Contract
All requirements listed in the contract must be identified by a unique ID. These should include both high level requirements, e.g. "SLN 2.0 shall support IE 5.5+," "Mozilla 1.0+ etc. or SLN 2.0 shall respond within 750ms to most common queries," and low level requirements such as, "all tables must be displayed with alternating row colors," or "the SLN logo should appear at the bottom of each page."

Prototyping
Prototypes can be flat diagrams (referred to as 'wireframes') that show relationships between screens or functions, storyboards that provide screen shots or mock-ups or even working applications using synthesized functionality.

Use Cases
A use case is a technique for capturing requirements of a new feature or change in the software. Each use case provides one or more scenarios that conveys how the new or modified function should interact with the end user or another system to achieve a specific goal. Use cases typically avoid technical jargon, preferring instead the language of the end user. For example: "After you log in a list of your current courses appear."

Section 4: Contributions

It is important to the success of the SUNY community, the health of our partnerships and the project itself, that work undertaken by the Learning Environments Tech Team be developed in a manner which provides the community and the public with insight into the work all parties are doing, and the decisions that the Tech Team has made. The Tech Team would like to ensure Project Leads understand the value of this transparency and ask that each Project have an operating plan in place for how their project will address the involvement of the community and the public. Please provide your plan here. You may refer to the Learning Environments' Development Process for a detailed description, some suggestions and questions that may help you to develop your plan. You are also encouraged to use Learning Environments existing Confluence and Jira sites for engaging communities.

References:
Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

Explanation of how these items might be used as a starting point for the work:

Topic Experts:
Please provide the names and contact information for any people, groups or organizations you feel may add to the success of the project.

Explanation of how these persons may help in the design, development and/or deployment of the product or service.

Section 5: Additional Information

Other:
Please provide any additional information that you feel may help the Tech Team understand and/or complete the project.

Section 6: Authorization

Any request for work that results in an alteration of current SLN functionality must be subnitted in the above format. The submission must be authorized by the Director of the SUNY Learning Network.