This one is a little longer, not really happy with the systems requirement spec.
Requirements gathering
1. Identify the methods you will use to gather the requirements for your software.
• One to one interviews: Predominately one of the most common ways for gathering requirements is to sit down with the potential client and conduct a one to one interview, typically these interviews should be planned out in advance when possible, these questions should be as specific as possible, when the primary functions have been considered it is recommend creating some open ended questions to allow for further avenues to be explored which may not have been considered when creating the original interview questions.
• Group interviews: Group interviews are in essence similar to one to one interviews, although generally there is a minimum of two people generally four, these types of interviews work well when the group is professionally on the same level or hold similar positions, Group interviews require a greater amount of preparation time than one to one interviews although if done correctly with a focused group they can yield a more robust set of requirements within a shorter period of time.
• Facilitated sessions: Facilitated sessions consist of five or more participants brought into a group for a common goal, in this regard it is similar to group interviews but done at a faster rate as the group common purpose, it should be noted however that facilitated sessions usually only cover the common purpose requirements of a project.
• Joint application development (JAD): JAD sessions are similar to facilitated sessions, the main difference is during a JAD session it will not be adjured until all objectives of the session have been completed and a requirements document has been finalized.
• Questionnaires: Questionnaires can be seen a less formal way to obtain requirements, it should be noted however that questionnaires are mostly used for stakeholder who will have minor input in the overarching requirements or stakeholders that are in remote locations.
• Prototyping: Prototyping is still a relatively new method for gathering requirements, with this method you gather the initial requirements for the project and build a basic version and show it to the client, whom will in return give additional requirements and repeat this cycle until the client is happy with the overall application or for an agreed upon number of meetings.
• Brainstorming: Brainstorming sessions are generally used in the purist of new ideas, this technique relies on the experience of the group, it should consist of at least three participants, topics covered in these sessions should generally cover possible technical difficulties and solutions, features that may be required at a later date, goals for the team to complete which will be translated into milestones for the project plan.
 
- Requirements:
Project brief
The local library within Kirkcaldy requires a digital catalogue, currently they still use a paper based system which does not inform the library of which books are currently on loan, this means books are often returned late or are misplaced due to the difficulty of having to manually check if the book is within the library or on loan by looking through large documents with repeating entries, the library would also like to allow for a fully automated system.
Project constraints
• Budget : £4,000
• Project deadline 4/7/16
Functional requirements
• Administrator login to allow for books to be added and removed from catalogue
• User registration
• User login
• Normalised 3rd form database minimum required tables:
o Books
o User
• SQL queries displaying all books and status of book, if book is on loan or is currently available for loan
• Up to date PHP server with most current version of PHP to be installed on the server
• SQL quires to detect books overdue currently out on loan
• Flood controls
• Prevent race conditions
Non-functional requirements
• All personal data should be encrypted with PHP blowfish
• Singleton pattern should be used to design user login and registering system
• W3C standards accessibility
• HTML developed to W3C standards
• CSS developed to CSS standards
• System layout should scale to all current devices I.E mobile, desktop, tablets, wide screens
• Clearly marked milestones for each stage of the project
- Conduct research into any technical or legal limitations around your software
Copyright grants protection for creators and authors, while allowing a civilization access to their works, this in essence encourages innovation, research and promotes growth of creativity. Legal flexibilities do however occur, in example of libraries which have the permission to make copies within its collection for the purposes of preservation, which was mandated by the UN in universal declaration of human rights, which dictates all have a right to the freedom of expression and a right to information.
- Consider how you as the software designer and developer will work with these limitations
When considering the responsive screen designs a developer could use jQuery matchMedia or CSS media quires, flexbox should be taken into consideration although this should only be used should the stakeholder agree to use a progressive enhancement approach as flexbox is still within its infancy and is not yet fully supported within all browsers. The developer should consider using sidebar navigations for mobile devises; this will allow users to navigate to their information without intruding on the flow of the screen.
- Write a short statement on the limitations and your proposed solutions to these
Primarily the main limitation will be data control, in example how a developer should prevent duplicate entries, update anomalies, delete anomalies or insert anomalies? A developer should use a process which is known as normalization to help prevent such instances from happening, at very least any developer constructing a database should conform to at least third normal for although boycode normal form is recommended.
