Project Specifications Design and Prototype Project Title Student: first and last name (student number) Supervisor: first and last name This report is submitted in partial fulfillment of the requirements for the BSc (Hons) Business Information Systems School of Computer Science & Engineering

Date Table of contents Provide a table of contents, linking the report Sections and Subsections to page numbers. If you can, hyperlink the page numbers/sections. List of figures Provide a list of figures, linking figure numbers to page numbers. If you can, hyperlink the page numbers/figures. 1.Aim and Objectives 300 words The aim(s) describe, in a few sentences, the overarching purpose(s)/intention(s) of the software/application. What is the point of developing the software/application, what you wish to achieve? Objectives describe with some detail the individual steps you will take to fulfil the project aim(s). Examples of aims and objectives are: Aim: Evaluate knowledge discovery techniques for modelling weather patterns. Objectives:

• Identify and evaluate existing weather pattern modelling techniques.
• Identify data analytics approaches suitable for modelling weather patterns.
• Design and develop at least three techniques for modelling weather patterns.
• Compare and contrast the developed techniques with one another and existing

approaches to modelling weather patterns. Note how the objectives build towards the ultimate aim of the project. They also appear in approximately chronological order in other words, they identify the order in which you would expect to tackle the work. The objectives identified above still require further refinement. This is achieved through the application of the SMART technique Applying the SMART criteria:

• Is this specific? Does this provide us with enough idea of what we should be doing?
• Is it measurable? How can we measure progress on this objective? How will we know when the objective is completed? How much literature must we access in order to conclude that the literature search is complete?
• Is it appropriate? Is it an appropriate objective to have, bearing in mind the long term goal of our project?
• Is it realistic? In the time we have available can we realistically expect to complete this task?
• Is it time-related? Have we identified how long the task will take and when we expect to complete it by?

Use Gantt charts represent a projects activities to address project objectives as rectangles or nodes, and milestones by diamonds. In this case, however, the size (length) of an activitys node represents the duration of that activity. See an example below Risks. Include a list of critical risk factors and means of dealing with these risks should they occur. How might you reduce their impact or limit their chances of occurring in the first place? Perform SWOT/PEST if business related risk is identified. 2. Requirements The SDLC represents a generic model for software development and consists of a number of stages. These stages, are: requirements capture, design, build, and. All BIS development projects follow this generic model in one way or another and yours will do the same. In practice there is often some overlap and iteration between these stages. For example, if you develop a prototype you will be performing some requirements capture, some design and some building work simultaneously. You will then perhaps return to the requirements stage to redefine these in light of feedback from the prototype and repeat the design and build stages again. Build and test usually overlap significantly. For example, you might write some code (a module, object or function) and test it; you might then write some more code and test it; you might then integrate these two components and test this combined sub-system, and so on Requirements capture represents all activities that are performed to elicit the requirements from the users-stakeholders and the documents that are produced during this stage. We begin with a problem that needs resolving. While the users understanding of this problem is subjective (they may not fully understand the problem or all its corresponding issues), the problem itself in reality, is unambiguous. Unfortunately, the user is our only link to this problem they are the experts in this area.. The analyst (yourself) attempts, with the user, to define the problem and produce a preliminary definition of the users requirements what they require of the system. This stage of the process results in a Requirements Definition that is written in the users terms usually in natural language (i.e., English). Because this document The analyst must then take this document and rewrite it unambiguously to produce a Requirements Specification. This is a much more formal, structured document that is not open to interpretation. It forms a basis for a contract between the client and software developers and, consequently, it is important that it is properly and professionally produced. It states what the user is expecting the system to do. Having identified the requirements for the system with the requirements specification it is now the job of the analyst (yourself) to specify one system that will satisfy these requirements the Functional Specification. This document usually contains an introduction, a rationale for the system, project objectives, functional requirements and non-functional requirements. Functional requirements state what the system is required to do and the data and user-interface requirements. Non-functional requirements refer to various constraints, standards, limitations (costs, delivery dates, configuration, language, resources, etc.), performance requirements, and validation criteria (which form a basis for system testing after the system has been written and tested). You should be clear in your own mind as to the difference between functional and non-functional requirements as this will help you to understand how your project has fulfilled these requirements when it is complete. The functional specification should be an unambiguous document that states exactly what the system will do. 2.1 Stakeholders 100 words Describe people and, if relevant, organisations who will be administrating, using, and in general affected by your software/application. Use a relevant diagram, if necessary. 2.2 Gathering requirements 600 words Describe the techniques/procedures you used for gathering requirements. Results will be summarised in this section (use graphs, if necessary). Notes: Detailed results/raw data from the process of gathering requirements can be included in an Appendix 2.3 List of project requirements 200 words List of Functional and Non-Functional requirements of the software/application; you may classify them in Essential, Desirable and Luxury. 2.4 Modelling requirements and relevant diagrams 500 words + diagrams

• Context diagram
• Use case modelling - Use case diagrams and use case descriptions
• Activity modelling Actions and activity diagrams
• Class modelling classes, attributes, class diagrams
• Other

3. Preliminary Design and Prototype Link to video demonstrating a prototype that should minimally show a sample user interface and discuss your engagement with creating the design and intended functionality. In this video, also discuss your design documents as well as data preparation and planning. Having decided what, the system is supposed to do during requirements capture, it is now time to decide exactly how the system will achieve this. Design works on a number of levels and a number of issues. For example, systems can be designed as a series of modules (or objects) that are gradually brought together to produce a fully working system. Design can include flowcharts/ activity diagrams, database design and pseudocode that plan how certain functions within the program will operate. Object-oriented design techniques (for example, UML) can be used to build systems from a series of objects. Design can encompass interface issues human computer interaction (HCI), screen layouts, navigation between screens, and story boards. You should consult with your supervisor over the most appropriate design techniques to use for your project. A preliminary high-level system design and its mirror implementation/development, as part of an initial prototype at this stage is required. 4. References Include a list of cited in your text items (books, papers, websites, etc.). Use Harvard style for the purpose, or any other preferred standard referencing style. 5. Bibliography Include here a list of general reading items (books, papers, websites, etc.). List the items in alphabetical order, using Harvard style to describe them Appendix I Provide additional material, if appropriate, in separate appendices. Do not include any printed code as an appendix.