| Prev | Chapter 6. Engineering Standards | Next |
|---|
+
Briefly explain to the reader what this document is for, whether it records the requirements for a new system, a client application, a toolkit subsystem, etc. Remember your audience: fellow programmers, @@ -47,21 +47,21 @@ leave generous gaps on the first writing of requirements (e.g. 1, 10, 20, 30, 40, etc.) because you'll want to leave room for any missing key requirements that may arise. -
10.0 A Common Solution
+
10.0 A Common Solution
Programmers and designers should only have to learn a single system that serves as a UI substrate for all the functionally specific modules in the toolkit. -
10.0.1
+
10.0.1
The system should not make any assumptions about how pages should look or function. -
10.0.5
+
10.0.5
Publishers should be able to change the default presentation of any module using a single methodology with minimal exposure to code.
For guidelines writing requirements, take a look - at the quality standards, along with a good example, such as OpenACS 4.5 Package Manager Requirements. + at the quality standards, along with a good example, such as OpenACS 4.6 Package Manager Requirements.
Besides writing requirements in natural language, consider using the following techniques as needed: @@ -81,6 +81,4 @@ pre-existing system or prototype first, and thus you may want to write some thoughts on implementation, for aiding and guiding yourself or other programmers. -