[Sub-Project Name|[Sub-ProjectName] One Pager(template version 1.93)
1. Introduction |
| Revision # |
Date | Author |
Comments |
|---|---|---|---|
A SHORT description of this project suitable for use on dashboards and status rollups.
See below for a longer, more detailed technical description.
Note any risks, and assumptions that must be considered along with the proposal. Include technical risks.
What problem or need does this project solve?
Why is it important to do this project?
| Term | Definition |
|---|---|
This could be just a link to a set of JIRA enhancements, Accept 360 requirements, requirements documents or some external medium reflecting a high-level view of what the feature is supposed to do. If none of these available, then the requirements should be placed right here.
Notice the contrast with section 4.1 where low-level requirements are stated. For example, a high-level requirement, stated in JIRA possibly, might say "we need a way for the user to specify a port number". The low-level requirements might show how the CLI takes a port number, how console pages will be updated to include port number, how the code behaves when a port number is not specified, how the system behaves when a bind fails, given that the user specified a specific port, etc.
High-level requirements are not necessarily testable, while low-level requirements are.
Remember that this page will, in most cases, be exposed to individuals from various companies, organizations and interests. No proprietary information reflecting release plans or strategic long-term goals of any organization belong in this document. This should be considered carefully in the sections dealing with performance, packaging, dependencies and compatibility.
Notice the contrasts described above between high-level and low-level requirements.
Each separate requirement should be listed in its own subsection.
As much as possible, requirements should be stated in rigorous terms, using testable language. Teams writing tests, documentation and complementary software will use these requirements on which to base their assumptions about their own work.
Feel free to add diagrams and drawings as necessary for clarity
Don't be hesitant to nest subsections even deeper, if it helps.
Descriptions of user interface elements are allowed here if it aids in the flow of the description, but are more appropriate in the interface section below.
Remember to cover error cases, rather than just mainline functionality; these are the areas that are often most important to other teams interacting with your component.
To the extent known, how is this project going to be done? This information is used by the reviewer to get a feel for the
complexity and risk involved, and the architectural constraints that this project is working under. Try to present alternatives and show relationships to existing or proposed projects/standards.
Aspects that are in scope of this proposal if not obvious from above.
Aspects that are out of scope if not obvious from above.
Don't skimp here. Many misunderstandings can be averted by stating what is not being done.
Interfaces may be commands, files, directory structure, ports,
DTD/Schema, tools, APIs, CLIs, etc.
Note: In lieu of listing the interfaces in the one pager, providing
a link to another specification which defines the interfaces
is acceptable.
List new, public interfaces this project exports.
List private interfaces which are externally observable.
List existing public interfaces which will be deprecated or
removed by this project.
List any Documentation (man pages, manuals, service guides...) that will be impacted by this proposal.
How will this change impact the administration of the product?
Identify changes to GUIs, CLI, agents, plugins...
What new requirements does this proposal place on the High Availability or Clustering aspects of the component?
Does this proposal impact internationalization or localization?
How does this proposal interact with security-related APIs or interfaces? Does it rely on any Java policy or platform user/permissions implication? If the feature exposes any new ports, Or any similar communication points which may have security implications, note these here.
Incompatible changes to interfaces that others expect to be stable may cause other parts of application server or
other dependent products to break.
Discuss changes to the imported or exported interfaces.Describe how an older version of the interface would
be handled.
List any requirements on upgrade tool and migration tool.
An internal dependency is a dependency on a project, module,
component or product that is within the GlassFish project.
An external dependency is a dependency on a project, component
or product that resides outside of the GlassFish project.
List all internal dependencies this proposal has on other
software. Include component version requirements if necessary.
List all external dependencies this proposal has on other
software. Indicate if the software is open source, what
license terms the software is released under and the version
of the software that is being consumed by this project.
How will the new feature(s) introduced by this project be tested?
Do tests exist from prior releases (e.g. v2) that can be reused?
Will new tests need to be written? Can they be automated?
Will these features have a negative impact on the performance of some existing feature? If so, what is the acceptable impact when using these features - if any? If there are performance features, are there specific performance improvement goals? Even if no performance impact is expected, are there hints that you can provide to those analyzing the performance of this feature?
List of related documents, if any (BugID's, RFP's, papers).
Explain how/where to obtain the documents, and what each contains, not just their titles.
Indicate which milestones from the current schedule the project
will be:
Use this to identify an open issue. If this is simply a point of indecision, then articulate what decision needs to be made. If it is a point of disagreement, then make sure to objectively list the different points of view. Try to avoid editorial comments if possible - record just the facts.
Place each issue in a separate section.
The review period is not over until all open issues are resolved.
