mod/techproject/view/screens/specifications

Index

Specification

Specification are descriptions that detail parts of the effective solution that will be constructed and that will form the real "product" or "technical system" the project focusses.

The specification phase is so called "system analysis" in which we design system architecture, organic segmentation, and intermodule communication techniques and standards. A deeply enough refined specification should tell what are fine-grain components in our system, and according to which protocols these components exchange with each-other.

Specification, just as requirements, can have a hierarchic organisation. Quite generic envelopes could be first defined, splitting the system into super-modules. i.e. : for a given software product, we could constitute a first title level as :

• Graphic buffer management
• Import/export library
• Filter framework
• Standard filter component
• GUI package
• Graphic files storing formats

Each of wich could be further refined, as resulting of such a questioning : "What would be sub-components of an import/export module ?" a system designer would proceed.

Monitoring and Viewing Specification

Specification are viewed as a heading content-collapsed tree. Any sublevel can be entirely collapsed if needed.

Each specification heading provides synthesis information, obtained by propagating indicators through associations from specifications to requirements and to tasks :

• Heading numbering (autonumbered)
• The specification caption
• The number of binded requirements (direct association/through sub-entries)
• The number of binded tasks (direct association/through sub-entries)
• The amount of specification completion, obtained through associated tasks, as a graphical bar-graph.

Each heading can be individually expansed for viewing a shorten content abstract and a full set of qualifying values.

Editing specification

Specification may not be editable by students. The teacher may choose locking such an entity.

A specification is a description that detail a part of the system to be constructed, a format or communication standard or any other technical description of an element the system needs to run. In its simplest form, a specification will be made of a caption and a free content buffer. The description content is a free HTML editable document that could be understructured as needed.

A specification may be qualified by :

• Severity : This is a measurement of the importance the element has for the project. It impacts risk calculation when such element is missing or is likely to fail when the project is to be delivered.
• Priority : This is a measurement of the pregnance of the element, and will impact the scheduling order of elements through the priority it propagates to tasks.

The specification screen allows constructing specifications through a continuous refinement process. Each specification can be splitted into subspecification that will describe some smaller parts of the system.

Pedagogical strategy

Specification could inquire a project team to construct defined "objects". These goals could be :

• setup by the teacher, and then could refined by students
• setup by teachers and locked. They will constitute final injonctions for the project. If requirements are unlocked, it would be such an exercice to get the students construct back what a customer could have first required, using customer's language. This exercice may be useful to teach the student to distinguish "functional language" from a more "technical description".
• editable by students, from an empty editor : students may having to perform the full system analysis job.