Key words to Indicate Requirement Levels
The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119.
Generguide will provide a
configuration file which specifies what content is to be incorporated
in a Project Guide.
Table 6. Configuration
| Id | Requirement | Implemented | Priority |
|---|
| rconfig1 | A user may specify a section in a configuration
file, then the section author may spawn new subsections. The
user will want to use the subsections without changing their
configuration file. The configuration shall allow a section to be included
and all subsections not specifically excluded will be included
as well. This is a black list filter. |  | High |
| rconfig2 | A user may want a limited subset of subsections. The
configuration file is to include only the specified sections
even after the extra sections are added to the Generic Guide.
A configuration shall
be able to specify only the subsections to include. This
is a white list filter. | | High |
| rconfig3 | Hopefully, generguide will be used to describe
processes from all sorts of industries. All industry processes
could be stored on the generguide site, however this will
force all industries to use the same development rules and
will hinder development of fringe processes. A
configuration shall be able
to reference sections from another namespace on the internet. |  | High |
| rconfig4 | In the configuration, it shall
be possible to specify which version of a section to use. The
version can be set to "head", "stable", or a
version number. The version number shall be of the form:
"x.x.x" where x is a number. | | High |
| rconfig5 | It is much easier to write a generic section if you can
specify variable names which are filled out by the user of the
section. For instance, "project_name",
"project_URL", etc. Generguide sections shall be able to use variable names
than can be edited in an external document by users of the
section. | | High |
Table 9. Documentation Contents
| Id | Requirement | Implemented | Priority |
|---|
| rdoccontents1 | Authors shall be
credited if they so desire. | | Medium |
| rdoccontents2 | Documentation shall
follow a standard format. | | Medium |
| rdoccontents3 | Generguide's target market is open source
developers who often don't have the money or the
inclination to buy software. Hence, tools that cost
money shall not be
recommended by the master generguide documentation.Sections
explaining cost-tools can be hosted on external sites and
advertised by these sites. Tools that provide a
free license for open source projects will be considered if
alternatives are not available. | | Low |
| rdoccontents4 | All things being equal, open source tools shall be recommended over no-cost
tools. | | Low |
Many potential generguide users will not be able to use
generguide unless they have a means to incorporate large amounts of
legacy documentation into the generguide framework. This means either
support standard formats or provide import utilities to import formats
into the generguide supported formats.
Source generguide documentation may be located at numerous
locations on the web. This means generguide tools will be faced with
logistical problems related to the reliability, speed and bandwidth
cost of the web.
Table 12. Bandwidth
| Id | Requirement | Implemented | Priority |
|---|
| rcaching1 | If all generconfig source documentation resides on the
local computer, then generconfig tools shall
be able to be executed without connecting to the web. | | Low |
| rcaching2 | Generconfig tools will be able to cache external source
documentation when executing. Subsequent execution of the tool
shall be able to execute and
produce the same results without being connected to the web. | | Low |