Phase 2 requirements document

The onus of a phase 2 report is to depict to the reader all the planning required to implement the solution
i.e., bring it to fruition. This is accomplished using technical writing, and diagrams, to effectively
provide a blueprint of the solution.
This is given for the express reason to show you how we will be marking the reports and to give you
some tips to help you along the way. If used, you should have no problem achieving 75% plus on the
report. Before that, a few general notes:

• This is a technical report and must be written in the 3rd person. You should not treat this report
any differently than you would a design report. Since you will only be given an extension this
phase, we do not expect this to be fixed in one week, but it should be addressed in phase 3. In
other words, do not say ‘I’, ‘we’, ‘us’ etc. in phase 3. Use ‘the group’ or similar instead.
• This phase is about planning. You must show your planning. That is what is being assessed.
You must, in essence, provide us with a manual on how to completely replicate your program.
The caveat to this statement is the page limit. We are aware that the page limit restricts what
you are able to include and the completeness thereof. You must still however show us that you
have covered all your bases. Being succinct and efficient in your technical writing is part of
being an engineer or a technical person in general.
• Again, this is a planning phase for a software product. You must provide UML diagrams to
show your planning. This will save space and much more effectively convey your work.
• Make sure the content in your sections match the section headings. For example: do not provide
a solution to your problem in the introduction of your chapter (or in the overall report). If you
are writing in the “Introduction” section, contextualise and introduce your topic. When
providing your “Proposed Solution”, give your solution, do not continue to tell us why it is
necessary. A section, e.g. proposed solution, is only assessed in that section, having an
extension of that section in another section will not attract marks towards the former.
• Referencing and in-text citing is a crucial element of report writing in general. As an EECE
student you are required to using the IEEE referencing standard. This is a requirement provided
by the EECEs “Guideline to Report Writing” document, that details the standards to follow.
Referencing is REQUIRED. It provides the reader a source to further information and gives
credit to the original sources of the information. Correctly referencing protects you from
plagiarism infringements.
• Try to stray away from using throwaway sentences e.g. “With the advent of technology and the
internet…”. The internet is not new anymore. We have had it in SA for almost 30 years.
Throwaway sentences contribute little, and waste precious space.
• Proofread your work. Spelling mistakes should not be an issue at this level.
The general layout of the report is still as provided by Mr. Naidoo. The expectation of the reports
content is as follows.

1
 Team Assessment
Criterion Max Mark How to achieve it Max
Expectation Marks
Achievable
Abstract It is effective You must provide a concise overview of 5
and captures the everything covered in the document from start to
scope of the finish. Tell us exactly how the document is
work and its structured and what to expect in each section.
outcomes. Less than half a page.
Contents Effective with Just use MS Word to create a contents page. It 3
hyperlinked will auto hyperlink.
entries and page
1 starting at
the introduction
Introduction It creates a You must give context to your program and why 3
strong context it exists.
for the solution
Proposed It strongly Depict the integrated structure of your final 8
High-Level addresses the solution. Show us how the individual parts are
Solution topic at a high connected and function as a whole. Individual
level solution is discussed in individual sections. This
is HIGH-LEVEL.
Specifications Clearly and FUNCTIONAL AND NON-FUNCTIONAL. 8
comprehensively Functional specs tell us what your program does.
sets up Non-functional tell us how your program does
measurable what it does. Your functional specs are your
expectations minimum expected deliverables (what your
program must do). If you give us a program that
does not perform everything listed as a
functional spec, your implementation cannot be
considered complete. Examples:
Functional: The system shall allow for the
addition and removal of users.

Non-functional: Security – The credentials and

information stored on the database and any
information transmitted to client computers must
be secured and encrypted.

(do not copy these, they are for a different

project)
Task Well-balanced, ELO5!! This is vitally important for you to pass 5
Breakdown clear and ELO5. Every team member must show
appropriate competence in ELO5. To achieve this, each
identification of member must show that they have engaged with
tasks, skills and the topics of GUI, database, Objects, Inheritance
tools for each etc as stated in the Project Description
Document provided at the beginning. If you do
not show this, you have not met minimum specs
for ELO5.
Performance Criteria are Performance Criteria: Tell us how you will 8
Criteria and comprehensive make sure the program performs as expected.
Test and measurable. Verifying functional requirements is not
Procedures Procedures are performance testing. Performance metrics must

2
for well defined and be measurable (quantifiable and comparable on
integrated practical a scale) and include but are not limited to CPU
system and Memory usage, data retrieve times etc.
Performance metrics are highly dependent on
the topic. Include only relevant performance
metrics i.e. do not include network usage if you
are not transmitting data over the internet or
LAN.

Testing: Here you should tell us how you will

be measuring the above performance criteria.
What test conditions will you use to show a
range of performance. For example: how much
does your CPU usage change when retrieve 10
items from the DB vs retrieving 1000 items from
the DB (scalability). Additionally, including
information of how you will be doing
Functionality testing is beneficial (will you be
doing unit testing, regression testing, black- or
Whitebox testing etc.). Fair warning: do not say
you are doing a certain type of testing and then
not provide evidence for it in phase 3. You will
be penalised. Make sure you understand what
each testing methodology entails before
committing to it. Whitebox testing is not fully
encompassed by unit testing, as an example.
Conclusion It summarises This part of the report should wrap up the entire 5
and report, giving the reader a summary of what
contextualises they’ve read, highlighting all the significant
all significant outcomes of the work. Example: Did you
outcomes of the achieve the performance criteria? Then tell us. If
work not, provide context as to why not.
References Follows The groups list of references goes here. This 5
accepted should be a collation of all the references used in
systems with the report. If a reference is in this list, it must be
citation. Sources cited in-text somewhere in the report. The
are of a high references should also follow the IEEE standard,
quality. and be of high quality. Do not just give us “[3]
Oithuizen, 2005.”, we require all pertinent
information as set by the standard. Further,
ensure the citation is current and not outdated.

Individual Assessment
Criterion Max Mark How to achieve it Max
Expectation Marks
Achievable
Proposed It strongly Give detail as to how you will implement your 8
Low-Level addresses the part. This is your main planning area, use UML
Solution identified low- diagrams, GUI wireframes, flow charts etc. You
level problem must fully describe how you intend to solve the
problem. Make sure that you expose and explain
any important engineering design considerations
and decisions.

3
 Testing Procedures are Testing: Here you should tell us how you will 5
well defined and be testing your implemented work. What test
practical conditions will you use to show a range of
performance. For example: how much does your
CPU usage change when retrieve 10 items from
the DB vs retrieving 1000 items from the DB
(scalability). Additionally, including
information of how you will be doing
Functionality testing is beneficial (will you be
doing unit testing, regression testing, black- or
whitebox testing etc.). Fair warning: do not say
you are doing a certain type of testing and then
not provide evidence for it in phase 3. You will
be penalised. Make sure you understand what
each testing methodology entails before
committing to it. Whitebox testing is not fully
encompassed by unit testing, as an example.
References Follows In-text reference your collection of references. 2
accepted Do not include you own little “reference list” at
systems with the end of your section. Your references should
citation. Sources still be included at the end of the document, in
are of a high order. IEEE STANDARD
quality.

Report naming convention for P2: The PDF/MS-word file must be named as follows…. G?P2.pdf

Where ? represents your group number. For example, group 21 will produce a file named G21P2.pdf

Cover page: The report cover page must include the following…

• The topic
• The group number
• Names ad student numbers of group members