SE3 Assignment Report – Help Document 2022-23
What should I submit in my report? – A balanced workload perspective.
Section
1. Introduction
1.1 Project Background
1.2 Project Aims and Objectives
2 Requirements Engineering
2.1 Elicitation Activities
2.1.1 Individual Workshop 1
Plan (Problem Domain Understanding)
2.1.1.1 Rationale
2.1.1.2 Agenda/Tool Selection
2.1.1.3 Participant
Engagement Commitment
2.1.2 Group Workshop 1 Plan
(Problem Domain Understanding)
2.1.2.1 Rationale
2.1.2.2 Agenda/Tool Selection
2.1.2.3 Participant
Engagement Commitment
2.1.3 Workshop 1 Findings
(Problem Domain Understanding)
2.1.4 Individual Workshop 2
Plan (Problem Resolution and
Specification Formulation)
2.1.4.1 Rationale
2.1.4.2 Agenda/Tool Selection
2.1.4.3 Participant
Engagement Commitment
2.1.5 Group Workshop 2 Plan
(Problem Resolution and Specification
Formulation)
2.1.5.1 Rationale
2.1.5.2 Agenda/Tool Selection
2.1.5.3 Participant
Engagement Commitment
2.1.6 Workshop 2 Findings
(Problem Resolution and Specification
Formulation)
2.1.7 Workshop Observation
Critical Review
2.1.8 Other Problem Domain
research
2.1.8.1 Comparable
Software System Review
Content
Introduction to the report/business
An overview of the business, based original brief and findings from the
workshops. (Approximately 1 pages)
Formulated aims and objectives. (Approximately 1-2 pages)
This is the equivalent section to “problem domain investigation” that
we have done previously used, just using interviews.
An introduction of the elicitation activities you are going to run.
(Each workshop plan (rationale/agenda/engagement rules should be
approximately 2-3 pages)
The rationale for the workshop – What do information do you intend to
get from the workshop/why is this need.
The agenda for the event.
The participant engagement rules for the event.
(Each workshop plan (rationale/agenda/engagement rules) should be
approximately 2-3 pages)
The rationale for the workshop – What do information do you intend to
get from the workshop/why is this need.
The agenda for the event.
The participant engagement rules for the event.
Record the key outcomes/findings from the workshop – This only
needs to be a summary of key points – NOT A FULL TRANSCRIPT.
(Estimated page length – 2-4 pages)
(Each workshop plan (rationale/agenda/engagement rules should be
approximately 2-3 pages)
The rationale for the workshop – What do information do you intend to
get from the workshop/why is this need.
The agenda for the event.
The participant engagement rules for the event.
(Each workshop plan (rationale/agenda/engagement rules should be
approximately 2-3 pages)
The rationale for the workshop – What do information do you intend to
get from the workshop/why is this need.
The agenda for the event.
The participant engagement rules for the event.
Record the key outcomes/findings from the workshop – This only needs
to be a summary of key points – NOT A FULL TRANSCRIPT.
(Estimated page length – 2-4 pages)
A record of the critical review of the workshops you observed.
Typically, 1 pages of reflection for each workshop. Clearly label the
workshops you observed. (Estimated total length – 2 pages)
For this assignment, the only mandatory content should be a review
competitor software.
A review of other relevant systems (As taught in previous years) –
Suggested 3 competitors with a review at the end (Estimated total
 length 3 – 4 pages)
2.1.8.2 Development Optional – If you believe this is essential based on your client
Relevant Legislation interviews.
A formulation of the key functional requirements for the system. (Note
2.2 Requirements Specification the documentation does not require performance, commercial and
client constraints in this project. (You can include if you wish)
2.2.1 Problem Domain Introduction to the key business processes/problems within the current
Description system (Estimated 2 -3 processes – Estimated 2 -3 pages.)
2.2.1.1 Existing Business Overview of core current business processes (2 – 3 processes
Operation reviewed).
2.2.1.2 Summary of Existing
Business Limitations Summary of Existing Problems – (1-page maximum)
Functional requirements for core system functionality for RMS and
Client Website
2.2.2 Functional Requirements
Focus on the specification of the parts of the system that you intend to
develop. (Estimated 4-6 pages)
2.2.3 Proposed Prototype
Development Blocks/Priority of The functionality priority listing showing suitable blocks of
Development development. (1-page maximum).
Agile development, moves away from documentation development to
rapid build, so I do not expect pages and pages of analysis and design.
3 System Analysis & Design (Software
The techniques you use are up to you (based on what you have been
Development Block 1)
taught previously on the course) but do not go into too much detail.

(Estimated 3-4 pages)

Consider highlighting the components software that you have been able
to reuse from other sources and how these have been fitted together.
4 System Build and Technical Notes (A diagram works well – See appendix 1). Reference the sources of all
(Software Development Block 1) software you use. (See appendix 2 Example)

(Estimated 2-3 pages)

Provide a short overview description of the following: -
a) Ongoing test strategy used.
5 System Testing & Evaluation Strategy b) The final systems functional testing strategy
(Software Development Block 1) c) A proposed systems evaluation strategy (product trials)

(Estimated 2 pages) - This should be for your first sprint only

Comment on the project success/limitations, after the completion of
6 Conclusion
the first sprint only. (Estimated 1 page)

NOTE: Adding up the totals of pages = 35 - 50. (Approximately 50% of this work, for the workshops should
have already been completed as classwork or homework during the term).

CLIENT PRESENTATION: For this year, the final client presentation will be a physical. It should be a 10 minutes
demo of the software only. – You should describe the functionality that you have developed in your first sprint
and stress the positive features of the software only.

All the other business relevant considerations we normal address in client presentations do not need to be
included.

Consider a final slide that lists all the functionality you have produced, especially if you feel you didn’t have
chance to demo all the software features in the 10 minutes allocated.

Appendix 1
 Example – Simply diagram showing how different software components have been used to develop the
solution

Appendix 2

Types of content you should reference

Software resources reference list

- Libraries
- Plug-ins
- API’s
- Frameworks
- Source code from other developments (e.g. GitHub content)
- Source code that you have previously developed and used in your own assignments
- Packages
- Software Tools
- Etc.

Note: An experience programmer should be able to develop a simple solution for this project using many
previously developed content (including previous assignments) with, in many cases, just some simple
rebranding and attribute reworking.