System/Application Requirements Template
By You
OpenACS docs are written by the named authors, and may be edited
by OpenACS documentation staff.
-
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,
@@ -11,35 +11,35 @@
everywhere, write clearly and precisely; for requirements
documentation, write at a level that any intelligent layperson can
understand.
-
Very broadly, describe how the system meets a need of a business,
group, the OpenACS as a whole, etc. Make sure that technical and
non-technical readers alike would understand what the system would do
and why it's useful. Whenever applicable, you should explicitly state
what the business value of the system is.
-
System/Application Overview
+
System/Application Overview
Discuss the high-level breakdown of the components that make up
the system. You can go by functional areas, by the main transactions
the system allows, etc.
You should also state the context and dependencies of the system
here, e.g. if it's an application-level package for OpenACS 4, briefly
describe how it uses kernel services, like permissions or subsites.
-
Use-cases and User-scenarios
+
Use-cases and User-scenarios
Determine the types or classes of users who would use the
system, and what their experience would be like at a high-level.
Sketch what their experience would be like and what actions they would
take, and how the system would support them.
-
Optional: Competitive Analysis
+
Optional: Competitive Analysis
Describe other systems or services that are comparable to what
you're building. If applicable, say why your implementation will be
superior, where it will match the competition, and where/why it will
lack existing best-of-breed capabilities. This section is also in the
Design doc, so write about it where you deem most appropriate.
-
Include all pertinent links to supporting and related material,
- such as:
Include all pertinent links to supporting and related material,
+ such as:
The main course of the document, requirements. Break up the
requirements sections (A, B, C, etc.) as needed. Within each section,
create a list denominated with unique identifiers that reflect any
@@ -74,11 +74,11 @@
suited to handle combinations of inputs.
Flowcharts - easy to draw and understand, suited for event and
decision driven systems. UML is the industry standard here.
Entity-Relationship diagrams - a necessary part of Design
documents, sometimes a high-level ER diagram is useful for
- requirements as well.