Cardiff School of Computer Science and Informatics Coursework Assessment Pro-forma Module Code: CMT313 Module Title: Software Engineering Module Leader: Helen Phillips Assessment Title: Business Case & Requirements Assessment Number: 1 Date Set: Friday 27th November 2020 Submission Date and Time: Friday 19th February 2021 – 9:30am Return Date: Monday 19th March 2021 This assignment is worth 50% of the total marks available for this module. If coursework is submitted late (and where there are no extenuating circumstances): 1 If the assessment is submitted no later than 24 hours after the deadline, the mark for the assessment will be capped at the minimum pass mark; 2 If the assessment is submitted more than 24 hours after the deadline, a mark of 0 will be given for the assessment. Your submission must include the official Coursework Submission Cover sheet, which can be found here: https://docs.cs.cf.ac.uk/downloads/coursework/Coversheet.pdf Submission Instructions Prior to handing in make sure all documentation has been collected. The Team Report front page should indicate your team number and the Student ID of each team member that contributed. Each deliverable should show the Student ID’s of each team member that contributed. If you have any difficulties submitting via Learning Central you MUST e-mail the module leader Helen Phillips (PhillipsHR@cardiff.ac.uk) at least half an hour before the deadline time. A nominated team member should submit the following files via Learning Central no later than 9.30am on Monday 19th February 2021. Description Type Name Cover sheet Compulsory – one per team member One PDF (.pdf) file [StudentNumber].pdf Business Case, using Template Compulsory – Only submitted by nominated team member One word or .pdf file BusinessCaseTeam[Team_number].pdf or BusinessCaseTeam[Team_number].docx Spreadsheet Optional One .xslx or .pdf file AppraisalTeam[Team_number].xslx or AppraisalTeam[Team_number].pdf Requirements document Compulsory – Only submitted by nominated team member One word or .pdf file RequirementsTeam[Team_number].pdf or RequirementsTeam[Team_number].docx Evaluation Compulsory – one per team member One word or .pdf file [StudentNumber]Evaluation.pdf or [StudentNumber]Evaluation.docx Any deviation from the submission instructions above (including the number and types of files submitted) may result in a mark of zero for the assessment or question part. Staff reserve the right to invite students to a meeting to discuss coursework submissions Team Working Module: During CMT313 Software Engineering you will be working as part of a team. The team portfolios will be made up of work undertaken by the team during the module. You are required to read the documents ‘Guidelines for Student Group Projects’ and ‘Code of Conduct for Student Team Projects’. Your team will also be required to produce a Team agreement. What tasks to do when: At the end of each contact session you will be given specific sections of the portfolio to focus on next. There will be specified opportunities for teams to obtain formative feedback on draft versions of most elements of the portfolio, either from the teaching team in contact sessions or in specially agreed sessions. Assignment This assessment covers the Autumn semester content for CMT313 Software Engineering. which involves developing the business case and requirements for a project. The cohort has been provided with 2 different scenarios and you have been placed in teams according to the scenario you selected. It covers the following main module learning outcomes: Develop a Business case that considers the commercial / economic issues and risks of a project. Determine requirements for a new system to meet business needs, demonstrating an appreciation of the external factors influencing systems requirements (such as ethics, legal issues, and design issues). PRODUCT DELIVERABLES 1. Teams will develop a Business Case using the template provided including the sections Executive Summary, Project Purpose, Options, Benefits, Costs, Financial Appraisal, Timescale and Risks. All Team members are expected to contribute to each section of the Business Case. 2. Teams will document Requirements for the new system including a Top-level Use Case Diagram to show key features/services, Use Case Descriptions or User Stories with Acceptance Criteria to specify key features/services and a list of important non- functional requirements for the system. Please make sure to cite any references used in the assessment using the Cardiff University Harvard System. https://intranet.cardiff.ac.uk/intranet/students/documents/libraries/Citing-and- referencing-in-the-Cardiff-Harvard-style-for-the-College-of-Physical-Sciences-and- Engineering.pdf 1. Business case The business case should show the purpose of the project and align this to University Strategy, outline a range of options for the project and provide a detailed appraisal of costs, benefits, timescales and risks for the chosen option. Teams should refer to The Way Forward: Education and Students strategy to add richness to their business case. They should use the Business Case template provided and address all the sections. These can be found in the supporting documents for this assessment. Teams can use a spreadsheet for the investment appraisal if they prefer. The business case front page should indicate your team number and the student ID of each team member that contributed. Each section should show the student ID of each team member that contributed. 2. Requirements Documentation Teams will create a set of requirements for their proposed system. These requirements will be stored in GitLab and will be used to track the progress of your project next term. Your team should create a project in the School’s GitLab. The project name should identify your team number and the project that you are working on: Team[Team_number][ProjectName] Make sure all your team members and all the members of the teaching team are given Maintainer permission to your project on GitLab. Create a Requirements Document for your project. This should include: As a Team, develop a top-level Use Case diagram showing what you consider to be the most important transactions/services that the system will provide. Each Use Case should be named appropriately from the client/users’ point of view. Each member of the team will take responsibility for specifying one of the key Use Cases. Each team member will need to choose a different Use Case. This can be written either as a use case description with clear steps showing the main flow of events or as a user story with clear acceptance criteria. These should be written so they are testable. Each Use Case Description or User Story with Acceptance Criteria should be written as a separate issue in GitLab. The requirements document will provide a table with working links to the appropriate issues in Gitlab. It should use the following format: Use Case Name Student ID Link to GitLab Issue As a Team provide a comprehensive set of software product quality requirements for your system. These should be written so they are testable. The Requirements Document front page should indicate your team number and the student ID of each team member that contributed. Each section should show the student ID of each team member that contributed. Weightings The following weightings are allocated for the different components of the assessment: Component Weighting 1. Business Case 60% 2. Requirements Document 40% CONTRIBUTION OF TEAM MEMBERS This is a team project and this assignment is assessed as a team, apart from the individual mark for the supporting evidence for each team members’ service. Each team member is expected to contribute to EACH component of the Business Case and Requirements Documentation. You will also be asked to submit a team evaluation form. You will evaluate the contribution of each team member and your own contribution to the deliverables. Normally every member of the team will receive the same mark for each component except in the case where a team member’s contribution and/or quality of work falls significantly below that of the rest of the team, in which case the marks will be adjusted accordingly. Please inform the module leader if there are any problems with any team members not engaging in team tasks or missing team meetings. The teaching team will check on the engagement of the team members in the contact session and review meetings. Students should therefore inform the module leader (and the other team members, if appropriate) if circumstances arise that are likely to affect their engagement with their work and/or attendance at weekly meetings with the rest of the team. The teaching team will provide formative feedback during contact sessions. Your team should also meet regularly outside of these. Learning Outcomes Assessed Develop a Business case that considers the commercial / economic issues and risks of a project. Determine requirements for a new system to meet business needs, demonstrating an appreciation of the external factors influencing systems requirements (such as ethics, legal issues, and design issues). Criteria for assessment The criteria and feedback sheets used for marking are provided so you can see how your coursework will be marked against the stated criteria. Feedback and suggestions for future learning Feedback on your coursework will address the above criteria. Feedback and marks for the team will be returned by Monday 19th March via Learning Central using the marking sheet that follows. You will also receive verbal formative feedback from the teaching team in the contact team meetings. Feedback for this assignment will be useful for the second piece of assessment and your dissertation. CMT313 Assignment: Team: Deliverable 1: Business Case Executive Summary Distinction Comprehensive and insightful executive summary that provides effective presentation of all key information. show clarity of expression without going into unnecessary detail Merit The executive summary provides a clearly written overview of most of the key information without going into unnecessary detail. Pass The executive summary includes several areas of key information however the explanation is unclear and or difficult to follow. Fail The executive summary includes limited key information. Project Purpose Distinction Provides an insightful project purpose with strong justification for the project to take place. Provides strong clear linkage of the scenario with Cardiff University Strategy, using other sources to add richness to the justification. Merit Provides a clearly written project purpose with valid reasons for the project to take place. Provides clear linkage of the scenario with Cardiff University Strategy, effectively utilising relevant information. Pass Provides a project purpose with appropriate but weak reasons for the project to take place. Provides some linkage with Cardiff University Strategy, however the strategy could have been used further. Fail Provides a poor project purpose with little/no appropriate reasons for the project to take place. Provides little/no linkage with Cardiff University Strategy Options Distinction Provides effective explanations for a range of highly relevant set of options that clearly considers scope, development approach and quality Provides effective and insightful overviews of key risks, costs and benefits of each option Gives clear and convincing justification for selecting the chosen option Merit Provides competent explanations for a range of options that considers scope, development approach and quality Provides competent overviews of key risks, costs and benefits of each option Gives clear reasons for selecting the chosen option, with justification. Pass Provides descriptions for at least three options Provides adequate overviews with sufficient consideration of risks, costs and benefits of each option Gives adequate reasons for selecting the chosen option, justification however is limited. Fail Provides inadequate/inappropriate descriptions of options Provides inadequate/inappropriate overviews of risks, costs and benefits Gives inadequate/inappropriate reasons for selecting the chosen option. Benefits Costs Distinction Provides a comprehensive range of significant tangible and intangible benefits and dis-benefits Clear measurement criteria are provided for most benefits and dis-benefits Highly appropriate justifications provided for most benefits and dis-benefits Provides a comprehensive range of relevant costs demonstrating insight and enhancing the accuracy of the analysis. Reasonable estimates are provided for most costs Highly appropriate justifications are provided for most costs Merit Has identified a mix of appropriate tangible and intangible benefits and dis-benefits Relevant measurement criteria are provided for many benefits and dis-benefits Clear justifications provided for most benefits and dis-benefits Costs included making the analysis relevant and consider the specific option selected. Reasonable estimates are provided for many costs Good justifications are provided for most costs Pass Benefits have been provided but linkage to the scenario is limited No correct dis-benefits have been included. Relevant measurements are provided for some benefits / dis-benefits Reasonable justifications provided for at least half of the benefits / dis-benefits Provides a limited range of relevant costs, reducing the accuracy of the analysis. Reasonable estimates are provided for at least half of the costs Reasonable justifications are provided for at least half of the costs Fail Provides an inadequate/inappropriate range of benefits and dis-benefits Little/no appropriate measurements are provided for most benefits and dis-benefits Little/no justifications provided for at least half of the benefits and dis-benefits Provides an inadequate/inappropriate range of costs, resulting in an unhelpful analysis. Little/no appropriate estimates are provided for at least half of the costs Little/no justifications are provided for at least half of the costs Investment Appraisal Distinction A highly effective cost benefit analysis has been carried out that comprehensively considers the main costs and benefits to clearly determine whether the chosen option can deliver sufficient value Merit A competent cost benefit analysis has been carried out, which covers the core relevant costs and benefits to determine whether the chosen option can deliver sufficient value Pass A cost benefit analysis has been carried out, which covers sufficient costs and benefits to provide a reasonable indication of whether the chosen option can deliver sufficient value. However, including additional costs and benefits would have enhanced this analysis. Fail Inappropriate or insufficient application of cost benefit analysis gives a poor indication of whether the chosen option can deliver sufficient value to the company Project Timescale Distinction A comprehensive and feasible high-level plan has been produced for the project with sensible estimates for timescales for each of the key stages Merit A feasible plan has been produced for the project with sensible estimates for timescales for most of the key stages Pass A reasonable plan has been produced for the project with adequate estimates for timescales for at least half of the key stages Fail Plan provides too few activities and inappropriate timescales for the project Risks Distinction Provides a comprehensive and insightful assessment of important risks for: Legal Issues Ethical Issues Project Issues Technical Issues Provides clear and highly appropriate actions for mitigating most risks. Merit Provides an assessment that includes relevant and important risks for: Legal
Issues Ethical Issues Project
Issues Technical Issues Provides appropriate actions for mitigating most risks. Pass Provides an assessment that identified only some important risks for: Legal
Issues Ethical Issues Project
Issues Technical Issues Provides appropriate actions for mitigating at least half of these risks. Fail Provides an inadequate/inappropriate assessment of risks for: Legal
Issues Ethical Issues Project
Issues Technical Issues Provides little/no actions for mitigating at least half of these risks. Deliverable 2: Requirements Documentation Top-Level Use Case Diagram Distinction The model is highly relevant to the project scenario and no important information is missing. The model clearly follows UML modelling conventions with no errors in syntax. Provides a comprehensive set of user-focused use cases that demonstrates insight into understanding user/client needs Merit The model is relevant to the project scenario with little of the important information missing. The model is a competent attempt at following UML modelling conventions and contains a few errors in modelling syntax. Provides a set of user-focused use cases that demonstrates competence in understanding of user/client needs Pass The model has some relevance to the project scenario but some important information is missing. The model is a reasonable attempt at following UML modelling conventions and contains some errors in modelling syntax. Has an adequate set of use cases to address user/client needs, but the naming of several of the use cases are system focused. Fail The model has little relevance to the project scenario and much of the important information is missing The model does not follow UML modelling conventions and has many errors in modelling syntax. Many of the use case names are system-focused and show little understanding of user/client needs Specifying the Requirements for the Use Cases Distinction Provides comprehensive and highly relevant specification of the requirements for the use case which clearly shows how the steps of the main flow / acceptance criteria can be fulfilled Use Case: 1 2 3 4 5 6 7 The Use Case Description / User Story with Acceptance Criteria clearly follows appropriate conventions and contains no errors Use Case: 1 2 3 4 5 6 7 Use case clearly addresses an important user/client need and is expressed well so that validation is obvious Use Case: 1 2 3 4 5 6 7 Merit Provides a competent specification of the requirements for the use case but with some minor errors or omissions in the steps of the main flow / acceptance criteria Use Case: 1 2 3 4 5 6 7 There is a competent attempt at following conventions for the Use Case Description / User Story with Acceptance Criteria, but it includes some minor errors or omissions. Use Case: 1 2 3 4 5 6 7 Use case clearly addresses a user/client need and is expressed so that validation is achievable Use Case: 1 2 3 4 5 6 7 Pass Provides an adequate specification of the requirements for the use case but with some major errors or omissions in the steps of the main flow / acceptance criteria Use Case: 1 2 3 4 5 6 7 There is an adequate attempt at following conventions for the Use Case Description / User Story with Acceptance Criteria but it includes some major errors or omissions. Use Case: 1 2 3 4 5 6 7 Validation of user / client’s needs would be challenging. Too much focus on technical detail. Use cases should concentrate on ‘what’ not ‘how’. Use Case: 1 2 3 4 5 6 7 Fail Provides an inadequate specification of the requirements for the use case due to too many errors or omissions in the steps of the main flow / acceptance criteria Use Case: 1 2 3 4 5 6 7 There is little/no attempt at following conventions for the Use Case Description / User Story with Acceptance Criteria Use Case: 1 2 3 4 5 6 7 Little focus on user / client needs. Too much technical detail for this stage of development. Use Case: 1 2 3 4 5 6 7 Software Product Quality Requirements Distinction Provides a highly appropriate and comprehensive set of software product quality requirements Validation is obvious for most requirements Merit Provides a competent set of software product quality requirements Validation is achievable for at least half of the requirements Pass Provides an adequate set of software product quality requirements Validation is achievable for some of the requirements Fail Provides an inadequate set of software product quality requirements Comments: Component Maximum Mark Team Mark Business Case 60 Requirements Document 40 Total: Justification for any adjustments to the Team Mark for Individual Students:
