F4: Feasibility and Requirements Tables

Feasibility [Project name]

Author	----------
[institution-name-here] Lead	----------
Date	----------
Contact(s)	----------
PI	----------
Department or Client organisation	----------
Funder & Scheme	----------
Size of overall grant	----------

For guidance in completing this documentation stage please see the Feasibility guidelines.

The purpose of this document is to gather information to help decide if the project should be stopped, if unlikely to be viable. The level of detail required is at outline level.

RESEARCH CASE

Vision and justification from a research perspective

REQUIREMENTS

List of requirements (based on those in the Terms of Reference but updated to reflect subsequent discussions and clarifications), prioritised using MoSCoW.
Note: for complex projects you may want to create separate lists for the various work areas or modules.

Default requirements

ID	Priority	Description	Days (est.)
D01	M, S or W	Data Protection Workflow and resource must comply with UK General Data Protection Regulation.	A xx D xx U xx S xx PM xx
D02	M, S or W	Digital accessibility and sustainability KDL will plan and implement a sustainable accessibility approach, including scoping, testing, assessment and drafting an accessibility statement as required. This is in addition to accessibility work which is incorporated directly throughout the other project requirements.	A xx D xx U xx S xx PM xx
D03	M, S or W	Usability testing At a time decided jointly by partners and the RES Lab, but prior to Acceptance testing (see below), a group of potential users who are representative of the principal target audience is given access to a functional version of the resource and asked to perform a series of tasks designed to test whether the resource is intuitive and pleasing to use for people previously unfamiliar with it. * Note: project partners are responsible for recruiting and organizing the test group (recommend 3-8 test participants)	A xx D xx U xx S xx PM xx
D04	M or W	Acceptance testing Late in the development phase and prior to Change Freeze (see below) project partners will test the resource to confirm that it meets all in-scope MUST HAVE requirements.1
D05	M or W	Change freeze Following Acceptance testing and any development effort that entails, no new feature development will be started. The purpose of this period is to prepare the resource for public launch. RS developer & UI/UX teams will focus on - Bug fixes - Minor design tweaks - Digital accessibility final test & statement - Security test - Deployment	A xx D xx U xx S xx PM xx
D06	M or W	Documentation and planning Project workflow and review, evolving solution and dependencies are discussed and documented both in KDL management systems, code repositories and outfacing documents (e.g. technical overview on project website) or research outputs as appropriate.	A xx D xx U xx S xx PM xx
D07	M or W	SLA sign-off or handover agreement sign off Agreement on who will be responsible for hosting & maintaining the live site. SLA will need to be signed before public release	A xx D xx U xx S xx PM xx
D08	M or S	Data publication and deposit RSE team provides help and advice with respect to preparing and depositing the digital data appropriate for deposit e.g. in institutional Research Data Management service (RDMS).	A xx D xx U xx S xx PM xx
D09	M or S	Copyright clearance documentation Management of PI- or partner-provided documentation will be in line with the approach outlined in the "Copyright Clearance" section of this Product Quote.	A xx D xx U xx S xx PM xx
D10	M or S	Training KDL staff will undertake training when the project requires knowledge of specific technologies etc and that training cannot be justified outside the project.	A xx D xx U xx S xx PM xx
		Total estimated days	A xx D xx U xx S xx PM xx

1 ‘In-scope’ is used here to allow for the possibility that one or more requirements which were MUST HAVE in the Product Quote might subsequently have had their priority downgraded in agreement with the project partners. ↩

Project-specific requirements

ID	Priority	Description	Days (est.)
P01	M		Eg: A xx D xx U xx S xx PM xx
Pxx	S
Pxx	C
Pxx	W
		Total estimated days	A xx D xx U xx S xx PM xx

SOLUTION ARCHITECTURE DEFINITION

High level design framework for the solution

ALTERNATIVE SOLUTIONS

Other options considered for the technical solution should be covered and a rationale for rejecting them in favour of the solution outlined in the section above should be given.

DEVELOPMENT APPROACH DEFINITION

High-level definition of the tools, techniques, customs, practices and standards that will be applied to the evolutionary development of the solution, including QA and strategy for testing and review.

DELIVERY PLAN

High-level schedule of project increments

MANAGEMENT APPROACH DEFINITION

Describe the approach to the management of the project, and considers how the project will be organised and planned, how stakeholders will be engaged and how progress will be demonstrated and reported

FORWARD PLANNING DEFINITION

Discussion options for the long-term sustainability of the project, e.g. SLA, Archiving, etc.

ACCESSIBILITY

While compliance with UK government accessibility standards is not required for research outputs, KDL regards a sustainable approach to accessibility as an essential consideration in our digital outputs. KDL integrates digital accessibility planning into new projects from the very start, connecting it with the sustainability planning outlined in the sections above, to embed both accessibility and sustainability considerations into digital resources. By keeping these considerations in mind, KDL aims to balance the accessibility needs of the project’s users with the need to ensure a resource remains sustainable long-term, alongside other factors such as project budget, technical solution and requirements. Rather than listing most accessibility work as a separate requirement, we have allowed for it within estimates for all relevant requirements.

COSTINGS

High-level costings, possibly using a range

NB. give costings in two forms: (1) with a breakdown of roles, FTE percentages, and days; (2) as a summary to be used for the Product Quote.

Example 1 - with breakdown

	Year(s)	Role/Resource	FTE	Days	Total
Data Protection	1	Senior Analyst
		UI/UX Developer
		Senior Developer
	2-	Senior Analyst
		UI/UX Developer
		Senior Developer
		Total for web application
Administration	1-	Project manager
Infrastructure	1-
				TOTAL
				% of overall bid

Example 2 - summary costing for use in Product Quote

Web application
Administration
Infrastructure	years 1-
	years
		TOTAL
		% of overall bid

RELATED RESOURCES

If applicable, a list of links to other documents or resources

FEASIBILITY ASSESSMENT

Justification for go or no go of the project

APPROVAL

[Analyst (not the document author)]
Software Developer/Engineer
UI/UX Designer
Project Manager
Director