Scenario
You are acting as systems consultants for a real organisation. Your task is to investigate one area of the organisation’s operations, identify shortcomings in current processes (manual or poorly computerised), and propose a technology-supported solution that saves money, generates value, or improves operational efficiency.
Adopt a structured approach: review processes, select a focal process, gather requirements using multiple techniques, model the current state, evaluate opportunities for improvement, design the target system, and outline an implementation and testing plan.
3. Deliverables & Weighting (Total 50%)
Submit the following components as a single, professionally formatted report with appendices, plus supporting files as specified. All diagrams should be clear, labelled and referenced in the text.
| # | Deliverable | Key requirements (summary) | Weight |
| D1 |
Company Background |
– Brief overview: organisation, sector, customers/market, locations, strategy (if available). – Identify at least three processes that are not well supported by current IS/IT. – Explain terminology plainly for non- technical readers. Formative checkpoint: receive feedback before proceeding. |
5% |
|
D2 |
System Analysis |
– Select and justify the focal process/system (agreed with tutor). – Requirements collection using two or more techniques (e.g., interviews, observation, documents). You are not required to implement this just to suggest approaches and justify choices. – Stakeholders and roles in development and use. – Detailed tasks, inputs/outputs, expected reports/feedback, software/hardware needs. – Models: current-state Use Case diagram and ERD. – Project risk assessment (tabular). |
15% |
|
D3 |
Design & Final Documentation |
– Proposed solution Use Case diagram. –Data Flow Diagram (context + level(s) as appropriate). – Data storage design using a Class diagram. – System construction (implementation) architecture. |
15% |
|
D4 |
Python Prototype (Demo) |
Using the provided dataset (released in labs), build a small demonstrator that: – ingests/cleans data; extracts features; applies ML; evaluates results. Focus is on the range and correctness of techniques demonstrated rather than completeness. |
6% |
|
D5 |
Presentation | 15-20 minutes including demo 9% Brief company and requirements; focus on design rationale and prototype. Follow the Rule of 7 keep slides simple and readable. Assessed on content and delivery. |
|
4. Submission Package Format
- One consolidated report (DOCX or PDF) containing D1–D3 with diagrams embedded; include appendices as needed.
- A zipped folder with Python code, notebooks and a short README explaining how to run the prototype (D4).
- Slide deck used in the presentation (PDF or PPTX).
- Referencing: Harvard style for all sources; include in-text citations and a reference list.
- File naming: CN7039_GroupX_Report.ext, CN7039_GroupX_Code.zip, CN7039_GroupX_Slides.ext
- Formatting (guidance): 11–12pt font, 1.15–1.5 line spacing, numbered headings, page numbers, captioned figures/tables.
5. Assessment Guidance
Markers will consider the following across components:
- Clarity, coherence and professionalism of communication.
- Appropriate and correct use of analysis/design notations (UML, ERD, DFD).
- Quality of requirements elicitation and justification of design choices.
- Feasibility and completeness of plans (risks, implementation, testing).
- Technical breadth and correctness in the Python prototype and evaluation.
- Academic integrity and correct referencing.
6. Marking Descriptors:
A (Excellent): Outstanding, coherent work demonstrating full command of analysis and design techniques; models are correct and integrated; strong justification and professional presentation; prototype shows technical breadth and sound evaluation.
B (Very Good): Very strong understanding with minor issues; most artefacts correct and well-justified; good presentation; prototype demonstrates several appropriate techniques.
C (Good): Sound understanding of most facts and methods; some gaps in justification, modelling accuracy or organisation; prototype functional with limited breadth.
Pass (Satisfactory): Adequate grasp of key facts; incomplete documentation or weak justification; basic models and prototype with noticeable errors.
Bare Pass / Fail risk: Core requirements missing or unclear; modelling and prototype largely incorrect or incomplete; poor communication.
7. Academic Integrity
All work must be your group’s own. Turnitin is used to check originality. Keep drafts and versioned files as evidence of your development process. Suspected academic misconduct will be investigated under UEL regulations. Late submissions follow UEL policy.
8. Questions about the assessment:
- Only your lab tutor will be marking your report.
- Do not email the module leader as they will not be grading your work.
- Bring your work to the lab to collect feedback about your work.
- Email the lab tutor with questions and please allow three working days for them to reply.
- If you do not get satisfactory responds, please let the Module leader on fadi@uel.ac.uk