mod/techproject/view/screens/requirements: Difference between revisions
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
[[mod/techproject/view|Index]] | [[mod/techproject/view|Index]] | ||
[[image:techproject_requirements_overall_ne.gif]] | [[image:techproject_requirements_overall_ne.gif|center]] | ||
== Project's Requirements == | == Project's Requirements == | ||
| Line 7: | Line 7: | ||
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. | 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 | 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 | 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 it processes graphic files | ||
| Line 17: | Line 17: | ||
* I want images can have size optimized | * I want images can have size optimized | ||
Each one of those can further be refined, as issue of such a | 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 == | == Monitoring and Viewing Requirements == | ||
| Line 23: | Line 23: | ||
Requirements are first viewed as an expanded tree of headers. Any sub-tree may be collapsed. | Requirements are first viewed as an expanded tree of headers. Any sub-tree may be collapsed. | ||
[[image:techproject_requirements_heading.gif]] | [[image:techproject_requirements_heading.gif|center]] | ||
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: | 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: | ||
Latest revision as of 07:37, 31 January 2008
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.
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".
