Updates on Assessment 1¶

Requirements¶

What has changed, and why?¶

Based on feedback from the previous assessment, the entire requirements specification has been reworked and looked at.

Almost all requirements have been changed and updated
We have updated each requirement to make them more concise and objective, in order to reduce the “design pollution”. This involved objectively reviewing each requirement and ensuring that they precisely specified the function or behaviour of the game
The format has remained the same, as we still use the IEEE standard for system requirements
We standardised and corrected our definitions of functional and nonfunctional requirements, and used these as a basis for categorising all of the requirements in the document. From the feedback given we were made aware that our understanding of this was incorrect, so made have changes to correct these problems .
The idea and aims behind each of the requirements has remained largely unchanged
Any small changes to the description of individual requirements was due to re-evaluation of what that requirement was attempting to achieve.
The IDs of the requirements were modified to fit the changed categorisation
We continued to ensure the requirements referenced appropriate risks

Link to updated version: http://docs.lihq.me/en/2.0.0/Assessment2/ requirements.html

Link to version control diff: https://github.com/Brookke/Lorem-Ipsum/pull/116/files#diff-28d223c584badedf323df6c577820471

Methods¶

What has changed?¶

Although we as a group feel that sometimes change is necessary for a group to run smoothly, we have not had much change occur during the second assessment. However, we have agreed to change a few minor things, allowing us to operate more efficiently as a team.

We are coding exclusively in IntelliJ while still ensuring that it can be opened, modified and run in Eclipse.
The group leader has changed to Jason.
Rather than 3 sub-groups, we are now operating more as singular units, sometimes pairing up to do more complicated tasks.
As the process went on, we found it easier to think in terms of tasks we had to do, rather than spend valuable time deciding on S.M.A.R.T targets per person. The document has been changed to reflect that
Systematic plan for Assessment 3 was added.
Following feedback, we have added a greater focus on the methods we are using for software engineering, as such a large portion of the document has been rewritten or adapted to better fit the brief
Improved section on how we are conducting meetings and sprints

Why has it changed?¶

Due to team preference, no-one in our group is coding using eclipse. This is also in part due to it being easier to discuss problems to do with coding interface (such as not being able to import the project correctly at the start) as everyone will see the same UI.
In our group we have had two leaders so far Brooke and Jason. The group unanimously decided that we would alternate leaders so that no one got overworked.
Due to the nature of coding and the amount of code to write, for this assessment we decided to split the work more than previously discussed to get more done in the same time. By ensuring that all work is still checked, this will ensure that we have more time spent on each part of the assessment so we will end up with a higher quality end product.
As a group we have decided that we work well together and can decide on our own tasks and goals well so felt that S.M.A.R.T targets were unnecessary to help us construct targets for the sprint ahead
We have elaborated on how we are going about software engineering using the agile-scrum methodology, and discussed further what we plan to do in our meetings and sprints. This should help the document better fit the brief.

Link to updated version: http://docs.lihq.me/en/2.0.0/Assessment2/ methods.html

Link to version control diff: https://github.com/Brookke/Lorem-Ipsum/pull/116/files#diff-e0ebb380121eb0162b6d02872c6705b9

Risk Management¶

What has changed?¶

We feel that in the last assessment all major and minor risks were outlined well so we do not feel the need to add any more or change them in any way.

We did improve the introduction documentation to address points raised in the feedback we received. This included greater detail into the risk identification process.
We also introduced bullet points to aid with readability
We added an owner column to the risks table

Why has it changed?¶

This document has been updated to include this information as we felt that it did not show enough detail in some elements of risk management.

Firstly the document did not describe how we actually determined the risks outlined in the document, therefore we felt it necessary to describe how we went about this.

Also the risks document did not show who actually had responsibility for the risks that we identified. It is important to know who is responsible so that if the risk does occur we know who will know how to deal with it, for example if there were conflicts in Git we would know who knows how to deal with them to resolve the issue quickly and efficiently.

Link to updated version: http://docs.lihq.me/en/2.0.0/Assessment2/riskAssessmentandMitigation.html

Link to version control diff: https://github.com/Brookke/Lorem-Ipsum/pull/116/files#diff-0a977fd0f40fa7a9b531ba8b356ff907