微信客服：xiaoxionga100
微信客服：ITCS521
程序代写案例-CMT313
时间：2021-02-21
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:
学霸联盟
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:
学霸联盟
