mod/techproject/view/screens/requirements

Jump to: navigation, search

Note: You are currently viewing documentation for Moodle 2.3. Up-to-date documentation for the latest stable version is available here: mod/techproject/view/screens/requirements.

Index

techproject requirements overall ne.gif

Project's Requirements

Requirement entries for a project are constitutive of the customer's willing. They can be stored as a set of descriptions that formalizes in a written form what the customer told us he would like our project to solve.

Collecting customer's needs (sometimes end user's) is the starting point to any human realization. The more precise the customer can tell us about it's will, the more valuable our prescription should be. Writing progressively a detailed expression of what we have collected is so called a refinement process.

In the Techproject module, requirements can be organized in a hierarchic structure. Students may start expressing quite general requirements, titling sections that will be further refined. As an example: for expressing requirements of some sort of software, we could consider we have heard the following list of recommendations:

  • I want it processes graphic files
  • I want image bulks can be treated easily
  • I want some customizable filters
  • I want some scriptable filters
  • I want images can have size optimized

Each one of those can further be refined, as issue of such a questioning from a part of a consultant to its customer: "Could you ever be more precise, please ?".

Monitoring and Viewing Requirements

Requirements are first viewed as an expanded tree of headers. Any sub-tree may be collapsed.

techproject requirements heading.gif

Each requirement header shows some synthetic indicators, obtained by propagating attributes through the requirement hierarchy up and down, but also transversally through cross-entity mappings (mappings to specification for the closest neighborhood). Main information is:

  • The item numbering (autonumbered reference)
  • The requirement abstract
  • The amount of linked specifications (direct mapping/indirectly mapped through sub-intities)
  • The completion indicator1, as a bar-graph

Each header can be expanded or collapsed so that a complete information, including description and full report of attributes can be seen.

(1) Completion indicator is obtained by propagating completion indicators of all tasks linked to that requirement, through spécification mappings. These indicators may not be significants if entity mapping is not performed all along the project developement.

Editing Requirements

Editing requirements can be locked for students, depending on teacher's accessible options.

A requirement is a set of information describing a customer's will. In its simplest model, a requirement would be represented as a short abstract, associated to a text description. We choosed description ought to be a full HTML buffer in which a complete standalone structured document could fit.

A requirement can be qualified by a "strength" attribute. It will tell how "strong" (pregnant) the recomendation is from the customer's point of view.

The requirement editor allows managing a tree-shaped organization of requirements, issued of a progressive refinement activity. Each requirement may be divided in several sub-requirements.

Teaching Strategy

Requirements could be preset by the teacher to prepone the project team "objectives" to reach, describing "expected behaviour or effects" of the job. Description should only tell "which effects" are expected, and not how to obtain them, which is a specification activity.

These objectives may be :

  • preset by the teacher, and further modified by students
  • preset by teacher and locked. They are definitive objectives hard setup in the project.
  • editable by students, from a blank editor: students must learn how to collect recomendations from their "customers".