RAW Rota – Requirement Analysis

Posted on June 18, 2019 by Robert Worrall

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

KUP Assessments – Initial URL Endpoints

Posted on June 18, 2019June 4, 2019 by Robert Worrall

Initial URL endpoints identified from initial requirement analysis

Base URL: /KUPassessments/

End points:

account/create/

account/update/{account-id}

account/assessment/create/

account/assessment/{assessment-id}

account/assessment/update/{assessment-id}

account/assessment/delete/{assessment-id}

participant/assessment/{assessment-id}

KUP Assessments Requirement Validation

Posted on June 14, 2019June 4, 2019 by Robert Worrall

(From the initial use case diagram)

An ‘Assessment Creator’ Creates an Account

Criterion	Result
Necessary	There needs to be a method which an assessment has an owner who can administer their own work.
Verifiable	A user can create an account with user name, password and email for administration purposes. I an assessment creator should then able to login to the account (see next requirement). The accounts details should be stored salted and encrypted.
Attainable	Can be done using post request with SSL
Unambiguous	No
Complete	Yes
Consistent	Yes
Traceable	Yes
Allocated	An account manager can be created to meet this requirement with accounts class
Concise	Yes
Implementation free	Create a account manager for storing accounts
Standard constructs	checked
Unique identifier	KUP-r1

An ‘Assessment Creator’ Logs into Account

Criterion	Result
Necessary	There needs to be a method which an assessment has an owner who can administer their own work. To do so they must be able to log into their account
Verifiable	A user can login to the account. This is only for a request such as uploading an assessment, updating an assessment or updating a account details. This is not a session. This is in keeping with a restful system.
Attainable	Can be done using post request with SSL and Basic Authorisation.
Unambiguous	No
Complete	Yes
Consistent	Yes
Traceable	Yes
Allocated	Account Manager
Concise	Yes
Implementation free	An account manager to return okay if username and password correct
Standard constructs	checked
Unique identifier	KUP-r2

An ‘Assessment Creator’ Manages Account

Criterion	Result
Necessary	There needs to be a method which an account can be managed To do so they must be able to change there username, password, email and if they get locked out
Verifiable	Account creator can update account using username and password. Account creator can unlock account with security questions.
Attainable	Can be done using post request with SSL and Basic Authorisation.
Unambiguous	No
Complete	Yes
Consistent	Yes
Traceable	Yes
Allocated	Account Manager
Concise	Yes
Implementation free	An account manager to return okay if account changed.
Standard constructs	checked
Unique identifier	KUP-r3

An ‘Assessment Creator’ can Create an Asssessment.

Criterion	Result
Necessary	To create assessments that can be later completed by participants
Verifiable	Account creator can create an assessment that can retrieved in the form it was sent.
Attainable	Can be done using POST request with SSL and Basic Authorisation.
Unambiguous	No
Complete	Yes
Consistent	Yes
Traceable	Yes
Allocated	Account will store associated assessments An assessment database will store assessments
Concise	Yes
Implementation free	Assessment is received in a form e.g JSON, XML or DSL Assessment is checked by the Assessment Checker to ensure an assessment can be completed. If not assessment is marked as under development. Assessment database returns okay if assessment stored. Account manager to return okay if assessment associated with account. Service returns okay if created and associated.
Standard constructs	checked
Unique identifier	KUP-r4

An ‘Assessment Creator’ can update an assssment

Criterion	Result
Necessary	To update assessments
Verifiable	Account creator can update an assessment that can retrieved it to confirm it has indeed updated.
Attainable	Can be done using PUT request with SSL and Basic Authorisation.
Unambiguous	No
Complete	Yes
Consistent	Yes
Traceable	Yes
Allocated	An assessment database will update the store assessment
Concise	Yes
Implementation free	Assessment is sent to the Assessment Database which is updated and a confirmation it has been updated is returned.
Standard constructs	checked
Unique identifier	KUP-r5

An ‘Assessment Creator’ can Delete an assessment

Criterion	Result
Necessary	To remove assessments that are no longer wanted or are erroneous
Verifiable	Account creator can remove an assessment that can no longer be retrieved it to confirm it has been removed. Other Assessment Creator cannot remove the assessment.
Attainable	Can be done using DELETE request with SSL and Basic Authorisation.
Unambiguous	No
Complete	Yes
Consistent	Yes
Traceable	Yes
Allocated	An assessment database will remove the assessment
Concise	Yes
Implementation free	Assessment ID is sent to the Assessment Database which is updated and a confirmation it has been updated is deleted.
Standard constructs	checked
Unique identifier	KUP-r6

An ‘Assessment Participant’ Completes an Assessment

Criterion	Result
Necessary	To retrieve and then complete an assessment that can be scored.
Verifiable	Assessment Participant can retrieve a given assessment by ID then return it completed for scoring.
Attainable	Assessment can be retrieved with a GET request which then can be return with a POST request to the service.
Unambiguous	No
Complete	Yes
Consistent	Yes
Traceable	Yes
Allocated	Assessment database will retrieve the assessment by ID number. When Submitting the assessment the assessor returns Result
Concise	Yes
Implementation free	Assessment Database retrieves the assessment requested. Which returns a JSON, XML or DSL that describes the assessment, acceptable answers and any documentation on how to complete the assessment. Assessment is assessed by the Assessor which calculates the assessment returns the result and a copy of what was submitted in XML, HTML or JSON format.
Standard constructs	checked
Unique identifier	KUP-r7

An ‘Assessment Participant’ recieves a result which can be printed

Criterion	Result
Necessary	There needs to be a way of creating a record on the client side.
Verifiable	If the participant can print the result in the client application
Attainable	A basic application is required.
Unambiguous	No
Complete	Yes
Consistent	Yes
Traceable	Yes
Allocated	A result can be printed from a client application
Concise	Yes
Implementation free	Application written in Javascript and HTML5 that allows the result of an assessment to be printed.
Standard constructs	checked
Unique identifier	KUP-r8

An ‘Assessment Participant’ receives a result which can be emailed

Criterion	Result
Necessary	There needs to be a way of creating a record on the client side.
Verifiable	If the participant can email the result in the client application
Attainable	A basic application is required.
Unambiguous	No
Complete	Yes
Consistent	Yes
Traceable	Yes
Allocated	A result can be emailed from a client application
Concise	Yes
Implementation free	Application written in Javascript and HTML5 that allows the result of an assessment to be printed.
Standard constructs	checked
Unique identifier	KUP-r10

An ‘Assessment Participant’ receives a result which can be saved locally

Criterion	Result
Necessary	There needs to be a way of creating a record on the client side.
Verifiable	If the participant can save the result in the client application into system storage
Attainable	A basic application is required.
Unambiguous	No
Complete	Yes
Consistent	Yes
Traceable	Yes
Allocated	A result can be saved from a client application to host environment
Concise	Yes
Implementation free	Application written in Javascript and HTML5 that allows the result of an assessment to be printed.
Standard constructs	checked
Unique identifier	KUP-r11

An ‘Assessment Participant’ can rate an assessments

Criterion	Result
Necessary	There needs to be a way of creating a record on the client side.
Verifiable	If the participant can save the result in the client application into system storage
Attainable	A basic application is required.
Unambiguous	No
Complete	Yes
Consistent	Yes
Traceable	Yes
Allocated	A result can be saved from a client application to host environment
Concise	Yes
Implementation free	Application written in Javascript and HTML5 that allows the result of an assessment to be printed.
Standard constructs	checked
Unique identifier	KUP-r12

An ‘Assessment Participant’ can search for an assessment

Criterion	Result
Necessary	There needs to be a way of finding an assessment by keyword
Verifiable	If the participant can find an assessment that exists using a keyword that is in it’s title or description
Attainable	Assessment database should have a search facility
Unambiguous	No
Complete	Yes
Consistent	Yes
Traceable	Yes
Allocated	Assessment database can have a search function that accepts plain text.
Concise	Yes
Implementation free	Request could be keyword, type, author.
Standard constructs	checked
Unique identifier	KUP-r12

Refined Use Case Diagram

Project License

For this project the GLP3 license shall be used. This is to ensure future versions being distributed closed. For the full listing of the license please see Appendix A

RAW Rota Generator – Initial Development

Posted on June 14, 2019June 14, 2019 by Robert Worrall

Project Goal

To allow rota of group of staff with varying Shifts to be generated based off a set of rules.

Initial Requirement List

Allow staff to be added
Staff to have custom rules – e.g does not work Thursdays.
Allow rules to be created. e.g James does not work same day as Joan.
Allow holidays to be entered. -public holidays, company closed and Staff holidays.
Allow types of shifts to be created with associated rules
Allow report of a shifts done.

Target Technologies

Java
Javafx
Embedded Apache Derby

Initial Use Case Diagram

New Project – RAW Rota Generator

Posted on June 13, 2019June 13, 2019 by Robert Worrall

My day job requires me to create rotas for GP’s and Nurses. This is planned out of a spreadsheet which in turn counts the number of clinics, types etc onto a separate sheet.

For long time I have thought about creating software that would create the rota for me. Given the number of variables for a rota, there are no perfect solutions but only a best fit option.

This leads me to think that some AI search algorithms could be used to find the optimal solution.

This project can be done done some of my break time and can be done concurrently with the KUP Assessments Project.

KUP ASSESSMENT DEVELOPMENT

Posted on June 5, 2019June 4, 2019 by Robert Worrall

Project Goal

A service that allows/ precipitates the creation and sharing of assessments of any kind from risk assessments to simple checklists. Assessments can scored using different schemes including secondary and primary contributory factors. These could then be assessed using Bayes theorem.

Initial Requirement List

Manage users
Users can create edit and amend own assessments
Users can create documentation for their assessments
Users can access documentation on how to create assessments.
Assessments can use a number of different scoring schemes.
Non users can use assessments and email/ print/ save results

Suspected Target Technologies

JAX-RS
MySQL
HTML5
JavaScript

Initial Use Case

KUP Assessments

Posted on June 4, 2019June 4, 2019 by Robert Worrall

It has been a while since I have posted anything. Work commitments have kept me distracted, however I have still managed to do some programming. I have started a new project titled “KUP Assessments”. For the next several posts I will outline the development process of the service.

The projects main goal is to allow users to create assessments that can be completed by other users. This assessments can be shared and not have to be recreated needlessly.

Refactoring Desktop Snowfall

Posted on December 18, 2018December 18, 2018 by Robert Worrall

Using the refactoring checklist I will attempt to improve the design of my Desktop Snowfall project

Can the code be Tested? – The application is GUI based application with not a huge amount going on underneath. Also some of this is subjective ie is the snow realistic? So it is impossible to test for. The current class diagram looks likes this:

Do you need a seam?
- extract methods using protected not private that use the seam.

Create Tests

To create the tests I will need to extract the GUI from the other logic e.g generation of the snow. I started by creating an Environment package and an Environment interface that can store the environmental variables, screen size etc. This is then injected into the snowfall class. Additionally a factory pattern could be used for creating the items in the weather. Hence as weather factory interface could created and injected into the snowfall class. For future flexability objects that fall are defined by a Map held by the environment. Keys in the map are the class names of the objects and the int is the percentage occurrence in the environment. Therefore the amount of objects created is still controlled by the user through the variable renamed from amountOfAnow to theAmountOfWeatherObjects.

I then created implementations and tests for them and I then integrated them into the design.

Start with the deepest branch to shortest branch – Refactored
Keep changes small and consistently retest. – Refactored
Remove complexity – Refactored
Methods should not have more than 10 lines of code – Refactored with a couple of instances where a method is 12 lines of code.
Replace conditionals with strategy pattern. – Refactored – achieved with introduction of weatherObjects, WeatherFactory and Enviroment interfaces.
Remove local variables – Refactored
Remove comments – use descriptive method names. – Refactored
Remove cryptic or clever code, – Refactored
Remove abbreviated code – Refactored
Refactor with dependency injection – Refactored used with implementing strategy pattern.
Refactor using SOLID
- Single Responsibility Principle (SRP)
  - All classes now have singular responsibilities
- Open Closed Design Principle
  - Up to this point I have amended, restructured the program to fit in with design principles. One I have completed this list. I will hold to this more strictly. Which begs the question. Should it have come first or last.
- Liskov Substitution Principle (LSP)
  - implemented with the WeatherFactory, Environment, WeatherObject and Weather classes.
- Interface Segregation Principle
  - At present the interfaces are basic and largly singular in purpose. e.g Environment interface only for retreiving details about the weather.
- Dependency Inversion Principle
  - Achieved by making Environment, Weather and WeatherFactory dependent on abstractions.
Refactor using other design principles
- Encapsulate what changes.
  - Reviewed – no further changes needed.
- Don’t Repeat Yourself (DRY)
  - Reviewed. No further changes needed
- Don’t look for things. Ask for things. (Dependency Injection)
  - Reviewed. No further changes needed.
- Favor Composition over Inheritance
  - Reviewed. No further changes needed
- Program to the Interface not to the Implementation
  - Reviewed. No further changes needed
- Delegation Principles
  - Reviewed. No further changes needed

Now the structure of the program now looks like this:

I will update the source forge and the projects page in the coming days.

Refactoring – Interface Segregation Principle (ISP) Applied To JobMan

Posted on November 16, 2018November 16, 2018 by Robert Worrall

This could be applied to the Database class. In particular the replication storage may not be required of later a multi user interface may be required instead of an embedded database. There is also a benefit to extracting the database out to an interface as it will allow other databases to be developed. e.g mysql.

Refactoring – Liskov Substitution Principle (LSP) Applied to JobMan

Posted on November 16, 2018November 16, 2018 by Robert Worrall

In the previous article I introduced 2 base classes Job and SpawnableJob. Their purpose was to forfill the closed open principle. However, as a side effect when all jobs are returned from the database spawnablejobs was also returned. This breaks the LSP as it is not intended that SpawnableJobs are substutable for Jobs and to do so would violate the single responsibility principle.

So to fix this. Spawnable will change so it has a filed of jobToBeReplicated which will hold an instance of Job and will no longer inherit from Job.