Development will follow TDD type process from validated requirements. The process will be as follows:
- Valid Requirements using the following criteria:
| Criterion | Description |
| Necessary | Can the system meet prioritized, real needs without it? If yes, the requirement isn’t necessary. |
| Verifiable | Can one ensure that the requirement is met in the system? If not, the requirement should be removed or revised. Note: The verification method and level at which the requirement can be verified should be determined explicitly as part of the development for each of the requirements. (The verification level is the location in the system where the requirement is met (for example, the “system level,” the “segment level,” and the “subsystem level).1 |
| Attainable | Can the requirement be met in the system under development? |
| Unambiguous | Can the requirement be interpreted in more than one way? If yes, the requirement should be clarified or removed. Ambiguous or poorly worded writing can lead to serious misunderstandings and needless rework. Note: Specifications should include a list of acronyms and a glossary of terms to improve clarity. |
| Complete | Are all conditions under which the requirement applies stated? Also, does the specification document all known requirements? (Requirements are typically classified as functional, performance, interface, constraints, and environment.) |
| Consistent | Can the requirement be met without conflicting with all other requirements? If not, the requirement should be revised or removed. |
| Traceable | Is the origin (source) of the requirement known, and can the requirement be referenced (located) throughout the system? The automated requirements tool should enable finding the location in the system where each requirement is met. |
| Allocated | Can the requirement be allocated to an element of the system design where it can be implemented? If not, the requirement needs to be revised or eliminated.2 |
| Concise | Is the requirement stated simply and clearly? |
| Implementation free | The requirement should state what must be done without indicating how. The treatment of interface requirements is generally an exception. |
| Standard constructs | Requirements are stated as imperative needs using “shall.” Statements indicating “goals” or using the word “will” are not imperatives. |
| Unique identifier | Each requirement should have a unique identifying number that assists in identification, maintaining change history, and providing traceability. |
- Create the basic structure using SOLID and other design prinicples. Additionally since this project intended to be a resetful service initial URL endpoints shall be suggested and then refinded inline with changes to system structure.
- From this create the tests from the verification sections when validating the requirements above.
- Write test and implement using the RGR cycle
- Write a failing test (Red)
- Write the code so the test passes.
- Re-factor your code, improve, document
- Check Structure, remove complexity
- Legibility – e.g Method Extraction
- Check for Anti-patterns
- Check for coupling
- No local variables
- Methods should not be more than 10 lines of code.
- Where applicable use dependency injection
- Cycles should not be longer than 5 minutes or ten lines of code.
