Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Lesson Specification: Difference between revisions

From MoodleDocs
No edit summary
No edit summary
Line 1: Line 1:
Functional Specification Revisions:  
Functional Specification Revisions:  
:0.1 - 11/06/2008 - Jerome Mouneyrac - Draft Version from existing module in Moodle 1.9
:0.1 - 11/06/2008 - Jerome Mouneyrac - Draft Version from existing module in Moodle 1.9
:1.0 - XX/XX/XXXX - Jerome Mouneyrac - Final Version
:1.0 - XX/XX/XXXX - Jerome Mouneyrac - Final Version for 1.9


Audience: developers/designer/QA
Audience: user/implementer/QA


Status: module implemented
Status: approved/module implemented


Related Documents:
Related Documents:
Line 14: Line 14:


==Introduction==
==Introduction==
===Scope of this Functional Specification===
===Scope of this functional specification===
This document is about functional specification for Moodle lesson module.
This document is about functional specification for Moodle lesson module.
===Glossary===
===Glossary===
'''implementer'''
'''implementer'''
:The person or team who will turn this specification into a working product.
:The person or team who will turn this specification into a working module.
'''requirement'''
'''requirement'''
:A need or necessary condition of the finished product.
:A need or necessary condition of the finished module.
'''shall'''
'''shall'''
:Used in the Requirements section 'shall' means that the item is absolutely necessary as stated. Example: The product shall support at least one million master records.
:Used in the Requirements section 'shall' means that the item is absolutely necessary as stated.
'''should'''
'''should'''
:Used in the Requirements section 'should' means the item is desirable, but not required. Wishy-washy, but often unavoidable. Example: The product should maintain the same order of data entry fields as current system XYZ. These requirements will be implemented where feasible within the other constraints.
:Used in the Requirements section 'should' means the item is desirable, but not required. Wishy-washy, but often unavoidable.
'''TBD'''
'''TBD'''
:To Be Decided/Determined.
:To Be Decided/Determined.
'''user'''
'''user'''
:Person(s) who will deal with the completed product of this specification.
:Person(s) who will deal with the completed module of this specification.


==Requirements==
==Requirements==
Line 41: Line 41:


==Use Cases==
==Use Cases==
===UCXXX1 Create a lesson===
====Base scenario=====
====Pre conditions====
====Post conditions====

Revision as of 03:27, 11 June 2008

Functional Specification Revisions:

0.1 - 11/06/2008 - Jerome Mouneyrac - Draft Version from existing module in Moodle 1.9
1.0 - XX/XX/XXXX - Jerome Mouneyrac - Final Version for 1.9

Audience: user/implementer/QA

Status: approved/module implemented

Related Documents:

Lesson Manual User / Documentation
Lesson Smoke Test
Lesson Test Plan


Introduction

Scope of this functional specification

This document is about functional specification for Moodle lesson module.

Glossary

implementer

The person or team who will turn this specification into a working module.

requirement

A need or necessary condition of the finished module.

shall

Used in the Requirements section 'shall' means that the item is absolutely necessary as stated.

should

Used in the Requirements section 'should' means the item is desirable, but not required. Wishy-washy, but often unavoidable.

TBD

To Be Decided/Determined.

user

Person(s) who will deal with the completed module of this specification.

Requirements

Issues

User Interface

Creation page


Use Cases

UCXXX1 Create a lesson

Base scenario=

Pre conditions

Post conditions