Some while ago I recorded how I refined some old projects. One of these was the WhitestarMediaLibrary. I recently found an old Javafx (script) for a media player. So I have decided to bring these into a new project WhitestarMediaCentre. This project will not have as much emphasis as the other projects currently running (Kup Assessments and RAW Rota). The main aim for the project is to provide music playback and a game library for my legacy game system.
In light of the above I shall adopt a concept from the martial arts world, referred to as the ‘economy of movement’ This means to strip out non essentials and take the most direct route to implementing the software. This does not mean to cut corners but to optimise the time spent developing essentials not superfluous elements of the system. e.g Artwork, fancy GUI interfaces etc.
3. The use of ‘Basic Authorisation’ and SSL
There must be some monitoring of any new threats/ compromises to this method of authentication. The issue of caching the usernames and passwords must be tackled. Initial solutions include offering an option of sending a request that sends a username and password of clear which the system then returns code such as 203 – Non-Authoritative Information
4. Ensure singleton for resources such as creating accounts, assessments is truly singleton
The databases are already account and assessment. If we added authentication with its own manager this would allow usernames and passwords to be separated from account and assessment. This also has the benefit of decoupling the authentication from the accounts in the system later moves to another authentication method .e.g OAuth2.
• Salted Hashes of Passwords, user data etc.
Hashing should not use MD5 but SHA256 from the java security library ref: https://www.youtube.com/watch?v=hNKfEwTO3AQ Salts should be kept in a separate database away from the password database. Salts should be kept in a separate database away from the password database.
• Security controls should be vetted and standardised
• Build training, testing and other activities around the security controls.
• Use OWASP Security Verification Standard (V3).
The basic level of standard shall be used. The system should not hold more information other than security questions, email address, username & password and assessments authored. This will also simplify GDPR legislation. If the amount of personal information changes then this the checklist should be reviewed in case further level of requirements need to be implemented.
1.1 Verify that all application components are identified and are known to be needed.
All the components would have been identified in the development process.
2.1 Verify all pages and resources by default require authentication except those specifically intended to be public (Principle of complete mediation).
Added to checklist for creating unit tests
2.2 Verify that all password fields do not echo the user’s password when it is entered
Added to the client testing checklist
2.4 Verify all authentication controls are enforced on the server side.
To be added as unit tests for the KUPfacade interface. And a set of tests using curl using a bash script.
2.6 Verify all authentication controls fail securely to ensure attackers cannot log in.
Added to unit tests for components requiring authentication.
2.7 Verify password entry fields allow,or encourage,the use of passphrases, and do not prevent long passphrases/highly complex passwords being entered.
Create a scheme that is enforced or encouraged by the client for minimum requirements there shall be a unit test to ensure the authentication manager enforces this. The is kept in the related post (KUP Assessments – Password Schema)
2.8 Verify all account identity authentication functions (such as update profile, forgot password, disabled/ lost token, help desk or IVR) that might regain access to the account are at least as resistant to attack as the primary authentication mechanism.
The project initially thinking it would use security questions. I have now decided that security questions are too weak a process and an email recovery service should be employed using the JavaMail API.
2.9 Verify that the changing password functionality includes the old password, the new password, and a password confirmation.
Added to unit test for authentication manager.
2.16 Verify that credentials are transported using a suitable encrypted link and that all pages/ functions that require a user to enter credentials are done so using an encrypted link.
This is completed using a bash script and curl.
2.17 Verify that the forgotten password function and other recovery paths do not reveal the current password and that the new password is not sent in clear text to the user.
Added to unit test for password recovery and authentication manager.
2.18 Verify that information enumeration is not possible via login,password reset, or forgot account functionality.
This shall be controlled by the hosting service and has been added to the ongoing threat assessment/ management.
2.19 Verify there are no default passwords in use for the application framework or any components used by the application (such as “admin/password”).
Shall be blocked by the password scheme in the system – common passwords.
2.20 Verify that request throttling is in place to prevent automated attacks against common authentication attacks such as brute force attacks or denial of service attacks.
This to be done by limiting bandwidth or another resource. Rate limit everything that could slow down or break the application. Use a simple counter kept in a quantised bucket
Decide on limit
Should not be too aggressive. Log if limits are reached and amend limits if required.
Bursting should not be required. Simple but different levels of limitting when authoring to participating
Decide identifier for limit
Must be an combination of IP address and username for authoring and IP address, browser and resource requested
Decide on exceptions for rules
Dynamic rating – all users. In this project no.
IP addressees – have exceptions for any monitoring tools or datacentre ranges (addresses that end web consumers should not be using). Also no limiting of yahoo, google etc.
2.22 Verify that forgotten password and other recovery paths use a soft token, mobile push, or an offline recovery mechanism.
Added to PasswordRecovery unit test.
2.24 Verify that if knowledge based questions (also known as “secret questions”) are required, the questions should be strong enough to protect the application
Secret questions are not used in this application.
2.27 Verify that measures are in place to block the use of commonly chosen passwords and weak passphrases.
Added to passwordschema unit test from general resource and privacy tests.
2.30 Verify that if an application allows users to authenticate, they use a proven secure authentication mechanism.
Basic authentication and ssl is to be used.
2.32 Verify that administrative interfaces are not accessible to untrusted parties
This is to be achieved via a bash script and unit test on authentication manager
3.1 Verify that there is no custom session manager, or that the custom session manager is resistant against all common session management attacks.
There are no sessions in the planned service.
3.2 Verify that sessions are invalidated when the user logs out.
There are no sessions in the planned service. However there is a dummy resource where passwords in a browser can be clear out of cache using username and password of 203 – Non-Authoritative Information. This has been added to the unit tests for authentication manager.
3.3 Verify that sessions timeout after a specified period of inactivity.
There are no sessions in the planned service.
3.5 Verify that all pages that require authentication have easy and visible access to logout functionality.
There are no sessions in the planned service. However there is a dummy resource where passwords in a browser can be clear out of cache using username and password of 203 – Non-Authoritative Information. This has been added to the unit tests for authentication manager.
3.6 Verify that the session id is never disclosed in URLs, error messages, or logs. This includes verifying that the application does not support URL rewriting of session cookies.
There are no sessions in the planned service.
3.7 Verify that all successful authentication and re-authentication generates a new session and session id.
There are no sessions in the planned service.
3.11 Verify that session ids are sufficiently long, random and unique across the correct active session base.
There are no sessions in the planned service.
3.12 Verify that session ids stored in cookies have their path set to an appropriately restrictive value for the application, and authentication session tokens additionally set the “HttpOnly” and “secure” attributes.
There are no sessions in the planned service.
3.16 Verify that the application limits the number of active concurrent sessions.
There are no sessions in the planned service. There will be throttling provided and added to use case for RequestThrottler.
3.17 Verify that an active session list is displayed in the account profile or similar of each user. The user should be able to terminate any active session.
There are no sessions in the planned service.
3.18 Verify the user is prompted with the option to terminate all other active sessions after a successful change password process.
There are no sessions in the planned service.
4.1 Verify that the principle of least privilege exists – users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege.
Added to the unit test for authentication manager.
4.4 Verify that access to sensitive records is protected, such that only authorized objects or data is accessible to each user (for example, protect against users tampering with a parameter to see or alter another user’s account).
Added to unit test of authentication manager.
4.5 Verify that directory browsing is disabled unless deliberately desired. Additionally, applications should not allow discovery or disclosure of file or directory metadata, such as Thumbs.db, .DS_Store, .git or .svn folders.
Should be managed by hosting service.
4.8 Verify that access controls fail securely.
Added to the authentication manager unit tests.
4.9 Verify that the same access control rules implied by the presentation layer are enforced on the server side.
Implemented in the password schema, password recovery and authentication managers via unit tests.
4.13 Verify that the application or frame work uses strong random anti-CSRFtokens or has another transaction protection mechanism.
This introduces a HMACsevice interface that take responsibility for generating tokens.
4.16 Verify that the application correctly enforces context-sensitive authorisation so as to not allow unauthorised manipulation by means of parameter tampering.
On unit test list for authentication manager and HMACservice
5.1 Verify that the runtime environment is not susceptible to buffer overflows, or that security controls prevent buffer overflows.
The java language has some protection as it is strongly typed, automatic bound checks and automatic memory management. Additionally account to OWASP.org java/j2ee is not affected as long as native methods or system calls are not invoked.
5.3 Verify that server side input validation failures result in request rejection and are logged.
Created new interface AssessmentValidator which checks the input of participant and author. Added to unit tests for AssesmentValidator .
5.5 Verify that input validation routines are enforced on the server side.
Added to AssessmentValidator unit test
5.10 Verify that all SQL queries, HQL, OSQL, NOSQL and stored procedures, calling of stored procedures are protected by the use of prepared statements or query parameterization, and thus not susceptible to SQL injection
Added to assessmentValidator interface unit tests
5.11 Verify that the application is not susceptible to LDAP Injection, or that security controls prevent LDAP Injection.
The system will not be using LDAP for user credentials or search filters.
5.12 Verify that the application is not susceptible to OS Command Injection, or that security controls prevent OS Command Injection.
Create JAX-RS filter or interceptor that filters all parameters in the uri’s Interface URIsanitiser created and added to unit test list. Additionally the service will not invoke Runtime.exec in order to call operating system commands
5.13 Verify that the application is not susceptible to Remote File Inclusion (RFI) or Local File Inclusion (LFI) when content is used that is a path to a file.
The URI sanitiser has added unit test that will not allow file extensions to proceed.
5.14 Verify that the application is not susceptible to common XML attacks, such as Xpath query tampering, XML External Entity attacks, and XML injection attacks.
Added to assessment validator unit tests
5.15 Ensure that all string variables placed into HTML or other web client code is either properly contextually encoded manually, or utilize templates that automatically encode contextually to ensure the application is not susceptible to reflected,stored and DOM Cross-Site Scripting (XSS) attacks.
The OWASP java-html sanitiser shall be used: https://github.com/OWASP/java-html-sanitizer if it is decided html will be used when submitting new assessments and submitting assessments. This shall be used as a composit part of the assessementValidator.
5.22 Make sure untrusted HTML from WYSIWYG editors or similar are properly sanitized with an HTML sanitizer and handle it appropriately according to the input validation task and encoding task.
Added the the AssessmentValidator interface.
7.2 Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable oracle padding.
Added unit tests to the passwordschema, HMACservice and athenticationManager. There will be no error for PAD error or MAC error returned to the user (added to unit test for authenticationManager). Timing attacks shall be countered by failing attacks to always take 5 seconds or other arbitatary length of time. Ref: https://www.youtube.com/watch?v=evrgQkULQ5U
7.7 Verify that cryptographic algorithms used by the application have been validated against FIPS 140-2 or an equivalent standard.
Added to unit tests for athentication manager.
8.1 Verify that the application does not output error messages or stack traces containing sensitive data that could assistan attacker, including session id, software/ framework versions and personal information.
Added to unit test for authentication manager and bash script using curl
9.1 Verify that all forms containing sensitive information have disabled client side caching, including autocomplete features.
Added to unit test for Client side application
9.3 Verify that all sensitive data is sent to the server in the HTTP message body or headers (i.e., URL parameters are never used to send sensitive data).
Added to the unit test for KUP_Facade
9.4 Verify that the application sets appropriate anti-caching headers as per the risk of the application, such as the following: Expires: Tue, 03 Jul 2001 06:00:00 GMTLast-Modified: {now} GMTCache-Control: no-store, no-cache, must-revalidate, max-age=0Cache-Control: post-check=0, pre-check=0Pragma: no-cache
Added to the unit test for KUP_Facade
9.9 Verify that data stored in clientside storage – such as HTML5 local storage, session storage, Indexed DB, regular cookies or Flash cookies – does not contain sensitive or PII).
Added to client application unit test
10.1 Verify that a path can be built from a trusted CA to each Transport Layer Security(TLS) server certificate, and that each server certificate is valid.
Added to bash script using curl
10.3 Verify that TLS is used for all connections (including both external and backend connections) that are authenticated or that involve sensitive data or functions, and does not fall back to insecure or unencrypted protocols. Ensure the strongest alternative is the preferred algorithm.
Added to bash script using curl
10.11 Verify that HTTP Strict Transport Security headers are included on all requests and for all subdomains, such as Strict-Transport-Security:max-age=15724800; includeSubdomains
Added to bash script using curl
10.13 Ensure forward secrecy cipher share in use to mitigate passive attackers recording traffic.
Bash script and curl to ensure elipitic curve or diffi-hellman key when exchanging keys during TLS – check with service provider
10.14 Verify that proper certification revocation, such as Online Certificate Status Protocol (OSCP) Stapling, is enabled and configured.
Bash script and curl – check with service provider
10.15 Verify that only strong algorithms, ciphers, and protocols are used, through all the certificate hierarchy, including root and intermediary certificates of yours elected certifying authority.
Bash script and curl – check with service provider
10.16 Verify that the TLS settings are in line with current leading practice, particularly as common configurations, ciphers, and algorithms become insecure.
Bash script and curl – check with service provider
11.1 Verify that the application accepts only a defined set of required HTTP request methods, such as GET and POST are accepted, and unused methods(e.g.TRACE,PUT,and DELETE) are explicitly blocked.
Added to unit test for KUP_Facade and bash script using curl
11.2 Verify that every HTTP response contains a content type header specifying a safecharacter set (e.g., UTF-8, ISO 8859-1).
Added to the unit test for KUP_facade
11.5 Verify that the HTTP headers or any part of the HTTP response do not expose detailed version information of system components.
Added to Bash script using curl and unit test for KUP_facade
11.6 Verify that all API responses contain X-Content-Type-Options:nosniffandContent-Disposition:attachment;filename=”api.json”(or other appropriate filename for the content type).
Added to KUP_facade unit test
11.7 Verify that the Content Security Policy V2 (CSP) is in use in a way that either disables inline JavaScript or provides an integrity check on inline Java Script with CSP noncing or hashing.
Added to KUP_facade and assessment validator unit tests
11.8 Verify that the X-XSS-Protection: 1; mode=block header is in place.
Added to KUP_facade unit test and bash script using curl
16.1 Verify that URL redirects and forwards only allow white listed destinations, or show a warning when redirecting to potentially untrusted content.
Added to KUP_facade unit test
16.2 Verify that untrusted file data submitted to the application is not used directly with file I/O command, particularly to protect against path traversal, local file include, file mime type, and OS command injection vulnerabilities.
Added to assessmentValidator
16.3 Verify that files obtained from untrusted sources are validated to be of expected type and scanned by antivirus scanners to prevent upload of known malicious content.
No files to be uploaded to the system only formatted text. Added to unit test for assessmentValidator
16.4 Verify that untrusted data is not used within inclusion, class loader, or reflection capabilities to prevent remote/local file inclusion vulnerabilities.
Only assessmentValidator can instantiate assessments which is only done from classess only in the sourcecode of the server and not defined by the text entered into the assessment. The assessment instantiation is only done after the assessment has been validated. Added to assessmentManager unit tests.
16.5 Verify that untrusted data is not used within cross-domain resource sharing (CORS) to protect against arbitrary remote content.
Only system schema and components implimenting the assessment interfaces are used – added to assessmentValidator.
16.8 Verify the application code does not execute uploaded data obtained from untrusted sources.
Added to unit test for assessmentValidator.
16.9 Do not use Flash, Active-X, Silverlight, NACL, client-sideJava or other client side technologies not supported natively via W3C browser standards.
Added to unit test for client application.
17.1 Verify that ID values stored on the device and retrievable by other applications, such as the UDID or IMEI number are not used as authentication tokens.
Added to unit test for HMAC service, Client application and KUP_Facade
17.2 Verify that the mobile app does not store sensitive data on to potentially unencrypted shared resources on the device (e.g. SD card or shared folders).
No App planned at this time.
17.3 Verify that sensitive data is not stored unprotected on the device, even in system protected areas such as key chains.
Added to client unit test
17.7 Verify that the application sensitive code is laid out unpredictably in memory(Forexample ASLR).
Using the JAVA platform negates this threat.
17.9 Verify that the app does not export sensitive activities, intents, content providers etc., for other mobile apps on the same device to exploit.
This is to be browser based and not needed at this time.
17.11 Verify that the app’s exposed activities, intents, content providers etc. validate all inputs.
This is to be browser based and not needed at this time.
18.1 Verify that the same encoding style is used between the client and the server.
Added to unit test for Client Application and KUP_Facade
18.2 Verify that access to administration and management functions within the Web Service Application is limited to web service administrators.
Added to athenticationManager unit tests
18.3 Verify that XML or JSON schema is in place and verified before accepting input.
Managed by JAX-RS
18.4 Verify that all input is limited to an appropriate size limit.
Added to new interface InputCheckFilterInterface
18.5 Verify that SOAP based web services are compliant with Web Services – Interoperability (WS-I) Basic Profile at minimum.
Not applicable for this project.
18.6 Verify the use of session – based authentication and authorization. Please refer to sections 2, 3 and 4 for further guidance. Avoid the use of static “API keys” and similar.
No sessions are to be used in this project. (REST)
18.7 Verify that the REST service is protected from Cross-Site Request Forgery.
HMAC already added to unit tests
19.1 All components should be up to date with proper security configuration(s) and version(s). This should include removal of unneeded configurations and folders such as sample applications, platform documentation, and default or example users.
A monthly review of security reports should be undertaken so new exploits can be mitigated or resolved.
For a list of terms (Glossary) please see post (KUP Assessments – Glossary)
Unit testing features of security
See the unit test post for resulting unit tests.
Independent review by a 3rd party. e.g a IT Security consultant.
Given this is going to be a desktop app and security is not going to be an issue on this project I have skipped to the security checklist. Below is the initial Class diagram for the project:
At this point I have selected the interfaces where I expect behaviour to change and base classes where I expect a specific functionality to remain the same (Open/Closed Principle). A factory pattern seems the best option for the generation of rotas. Note, all rotas are passed back to the user only those of a given fitness.
The project shall be developed under GPL 3 licence. The url of the project on GitLab is:
This being a restful service a facade pattern is the first obvious choice, This would suggest initial 3 classes behind the facade. These are Account, AssessmentCreator and AssessmentParticipant. I did think of removing the Account class but it would be better to have separate classes for accounts and the assessment creation. Strategy pattern could facilitate the creation and execution of custom built assessments.
Initial Class Diagram
Librarian class has been created because assessmentParticipant has a different view of the assessment to the assessment creator. I could just do this in the AssessmentParticipant class but I anticipate that the will be other functions the assessmentPaticipant class will be responsible for. In keeping with the strategy pattern the assessments are interfaces that that are implemented with a set if of IassessmentComponents.
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
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
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.
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.
