Student Project Brief Template: Scope, Evidence and Review

実際の状況を定義します。

プロジェクトの対象者と学習者が何を作成する必要があるかを説明します。実装の詳細をすべて指定しなくても、意思決定の指針となるようにコンテキストを明確に保ちます。学習者の開始知識と利用可能な時間 (使用できるリソースなど) に範囲を合わせます。

レビュー基準を可視化します。

学習者が学習を開始する前に、作業がどのように評価されるかを述べます。必須の結果とオプションの拡張を区別します。例は基準を説明するのに役立ちますが、プロジェクトでさまざまなアプローチを許可することを目的としている場合は、1 つの例を唯一の許容可能な解決策にすることは避けてください。

サポートと考察を計画します。

学習者が終了する前に自分のアプローチについて話し合うことができるチェックポイントを組み込みます。最終的な出力とともに決定事項と制限事項について説明するよう依頼します。提出を学習活動の終わりとして扱うのではなく、復習を利用して次に何を練習すべきかを特定します。

Scope a project around evidence of learning

Choose a problem appropriate to the learners’ current knowledge and the available time. Describe the intended user, the useful outcome and the constraints. Separate required functionality from optional extensions so learners can plan a complete first version.

Specify the evidence to submit: working output, explanation of decisions, tests or a demonstration of the method. Plan an early checkpoint for scope review and a later checkpoint for feedback on work in progress. Explain permitted tools, collaboration and use of external assistance. For group work, agree how individual reasoning is made visible. Finish by checking that the assessment criteria measure the intended learning rather than presentation polish alone.

A student project brief that can be reused

Write the brief in language learners can act on. Include a sample deliverable description without giving away the solution.

• Context: the problem, intended audience and why the proposed output is useful.
• Learning purpose: the skills the project is intended to demonstrate.
• Scope and constraints: essential tasks, exclusions, time, tools and available materials.
• Deliverables: output, setup instructions, decision explanation and supporting evidence.
• Checkpoints: scope approval, progress review, feedback and final submission.
• Assessment: criteria, individual contribution evidence and rules for permitted assistance.

Avoid hidden requirements and unrealistic scope

A brief that appears small may depend on unfamiliar deployment, data or integration work. Review those prerequisites before assigning it. Provide fictional data or an approved practice environment instead of expecting learners to collect sensitive records.

Do not change the assessment criteria halfway through without explaining the effect. Keep optional features from silently becoming essential to a satisfactory result. Where projects vary, use criteria that can be applied fairly to the agreed scope of each one.

Should learners all build the same project?

Either a shared problem or a choice of projects can work. A shared brief makes comparisons easier, while choices can support different interests. In both cases, confirm comparable learning objectives, manageable scope and assessment evidence before the work begins.

ILLUSTRATIVE PLANNING EXAMPLE

Example: a campus event application

Ask learners to build a small event-registration journey for a defined audience. State the required user actions, available time and permitted tools. Specify the deliverables, such as a working prototype, setup instructions and a short explanation of design choices. Include an early checkpoint to catch an unrealistic scope.

Give reviewers criteria before work begins. For a group project, define how individual contributions and decisions will be explained alongside the shared output.

FURTHER READING

Official resources to explore

Explore the related official guidance below. The templates and examples are practical starting points to adapt to your own project.

• Carnegie Mellon Eberly Center: learning objectives