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. |
| 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. |
Allow Staff to be Added
| Criterion | Description |
| Necessary | Yes to allow rota to be created for various members of staff |
| Verifiable | Staff should be retrievable once added and should show on the rota. |
| Attainable | Yes using an embedded database |
| Unambiguous | Yes |
| Complete | functional |
| Consistent | Yes |
| Traceable | Yes |
| Allocated | New class StaffDatabase |
| Concise | Yes |
| Implementation free | Access to database required. |
| Standard constructs | Checked |
| Unique identifier | rawRota1 |
Staff must have facility for custom rules
| Criterion | Description |
| Necessary | All staff work at different days and times. Some will do certain shifts only at certain times. Therefore there must be a mechanism for checking this against the rota. |
| Verifiable | Yes if a number of rules can be created that can be applied to a given rota. |
| Attainable | Yes |
| Unambiguous | Yes |
| Complete | Constraint/ Functional |
| Consistent | Yes |
| Traceable | Yes |
| Allocated | New classes Staff and RotaRule |
| Concise | Yes – removed requirement ‘ Allow rules to be created. e.g James does not work same day as Joan. ‘ as this is the same requirement. |
| Implementation free | Rules are applied to a generated rota and generating a score the higher the score the better the fit. |
| Standard constructs | Checked |
| Unique identifier | rawRota2 |
Allow Events to be created
| Criterion | Description |
| Necessary | Yes there needs to be a method were dates are not filled for all staff or some staff this covers holidays, closures and training. Renamed from ‘Allow holidays to be entered’ |
| Verifiable | Holidays, Training and closures can be added to a Rota before shifts generated. |
| Attainable | Yes |
| Unambiguous | Yes |
| Complete | Functional/ Constraint |
| Consistent | Yes |
| Traceable | Yes |
| Allocated | New classes Rota and Event |
| Concise | Yes |
| Implementation free | Events must have a period of time of which they cover and who it covers. i.e which staff. |
| Standard constructs | Checked |
| Unique identifier | rawRota3 |
Generate Rota and Apply Rules
| Criterion | Description |
| Necessary | Yes main function of the application. |
| Verifiable | Should create a rota apply the events and generate shifts in the rota for the members of staff. |
| Attainable | Yes |
| Unambiguous | Yes |
| Complete | Functional |
| Consistent | Yes |
| Traceable | Yes |
| Allocated | Rota, RotaRule, Event, Staff and new class Shift |
| Concise | Yes |
| Implementation free | This can be done using AI search problem strategies. |
| Standard constructs | Checked |
| Unique identifier | rawRota4 |
Allow report of a shifts
| Criterion | Description |
| Necessary | Top scoring shifts can be reported with their fitness score |
| Verifiable | The user specified length rota shortlist must contain complete rotas with fitness scores |
| Attainable | Yes |
| Unambiguous | Yes |
| Complete | Functional |
| Consistent | Yes |
| Traceable | Yes |
| Allocated | new class RotaFactory |
| Concise | Yes |
| Implementation free | Suggests a factory pattern |
| Standard constructs | Checked |
| Unique identifier | rawRota5 |
Like this:
Like Loading...
Related
