3. Component Requirements, Constraints, and Acceptance Criteria
Most requirements take the form of "foo will do ...." or "foo will not support ...", although different words and sentence structure might be used. Adding functionality to your proposal is requirements creep (bad), unless listed below. Discuss major changes with your team first, and then open a "feature improvement" issue against this component.
This component will correctly reads a developers mind for intent and generate the right configuration file.
The generated config file will not support XML, but will provide an extension point in the API.
This component will use no more memory than twice the size of all data it contains.
This component will include a factory method.
This component will not allow subclassing. (i.e. when reviewed, we expect to see "final" keyword in code)
This component will only generate data exports strictly complying with RFC 12345.
This component will validate input data against formats supported by ZF component Foo.
This component will not save any data using Zend_Cache or the filesystem. All transient data will be saved using Zend_Session.
4. Dependencies on Other Framework Components
Zend_Exception
Zend_Service_Amazon_Abstract
Zend_Http_Client
Zend_Uri_Http
5. Theory of Operation
The component is instantiated with a mind-link that ...
6. Milestones / Tasks
Milestone 1: Write a prototype and publish to github "[DONE]"
Milestone 2: Write Unit Tests that cover all use cases.
7. Class Index
Zend_Service_Amazon_Ses
Zend_Service_Amazon_Ses_Exception
Zend_Service_Amazon_Ses_Email
8. Use Cases
UC-01 Statically Supplying AWS Credentials
UC-02 Verify an Email Address
UC-03 Deleting a Verified Email
UC-04 Sending an Email with the SendRawEmail action
You are viewing an old version of this page. View the current version.
Compare with Current |
View Page History