srs document

Assessment Details and Submission Guidelines

Unit Code BN209

Unit Title Software Engineering

Assessment Type

Group Assignment

Assessment Title Assignment 2

Purpose of the assessment (with ULO Mapping)

This assignment assesses the Unit Learning Outcomes below; students should be able to demonstrate their achievements in them:

a. Determine system requirements through requirements elicitation and workshops.

b. Explain the process for, and execute, verification and validation of system requirements. c. Apply use case, data and process modelling techniques to specify system requirements. d. Compare and contrast different software engineering process models: waterfall, evolutionary, spiral, prototyping. f. Explain and properly utilise various types of software tests. g. Define system specifications including technical, economical and operational feasibility.

Weight 25%

Total Marks 100

Word limit 30 – 35 A4 pages

Due Date Week 11 Friday, 1st June 2018, (11:55 pm)

Submission Guidelines

 All work must be submitted on Moodle by the due date along with a completed Assignment Cover Page.

 The assignment must be in MS Word format, 1.5 spacing, 11-pt Calibri (Body) font and 2 cm margins on all four sides of your page with appropriate section headings.

 Reference sources must be cited in the text of the report, and listed appropriately at the end in a reference list using APA referencing style.

Extension  If an extension of time to submit work is required, a Special Consideration Application must be submitted directly to the School's Administration Officer, in Melbourne on Level 6 or in Sydney on Level 7. You must submit this application three working days prior to the due date of the assignment. Further information is available at: http://www.mit.edu.au/about-mit/institute-publications/policies-procedures-and- guidelines/specialconsiderationdeferment

Academic Misconduct

 Academic Misconduct is a serious offence. Depending on the seriousness of the case, penalties can vary from a written warning or zero marks to exclusion from the course or rescinding the degree. Students should make themselves familiar with the full policy and procedure available at: http://www.mit.edu.au/about- mit/institute-publications/policies-procedures-and-guidelines/Plagiarism- Academic-Misconduct-Policy-Procedure. For further information, please refer to the Academic Integrity Section in your Unit Description.

Prepared by: Samira Baho Moderated by: Dr Shaleeza Sohail April, 2018 Page 2 of 6

Purpose of the assessment: The purpose of this assignment is to prepare a consolidated version of Extended SRS Analysis and Design Document for your project (i.e., the same project that you have chosen for Assignment #1).

Task

Students to finalise SRS analysis and design document that they started in Assignment 1 and present their final

work in week 12 during the laboratory session.

Students submit 'Extended SRS Analysis and Design Document, which contains the following design elements (using UML notations):

1. Assignment #1 Progression: SRS document updates according to the changes in your ongoing project

2. Recommended software engineering process model for your project,

(waterfall/evolutionary/spiral/prototyping) and factors for selecting the process model

3. Select any requirement verification method, and verify the user requirements with stakeholder

4. Context Diagram for the complete overall system

5. Identify all the actors and use cases for your system

6. Fully developed use case description for any 2 use cases scenarios of your choice

7. Activity diagram for an any 2 scenarios of your choice

8. Sequence diagrams for any 2 scenarios of your choice

9. Class diagram for the complete overall system

10. Verify user requirements with stakeholder and report requirement verification process adopted for

your project

11. System Specification including technical, economical and operational feasibility

12. Software testing and acceptance criteria

13. Proposed deployment strategy

14. Final copy of the “Project Activity Journal” that shows weekly progress of team work

References and appendices

• Reference sources must be cited in the appropriate section of the document.

• All cited references must be in IEEE style

• List all the appendices

Team submission:

Prepared by: Samira Baho Moderated by: Dr Shaleeza Sohail April, 2018 Page 3 of 6

This is a group assignment, but only one member from a group will upload the ONE ZIP FILE on

MOODLE.

Submission guidelines:

The report should have a consistent, professional, and well-organised appearance.

1. Your report should include the following:

 The cover page must identify students’ (name and number), teaching staff, and assignment.

 The assignment must use 1.5 spacing, 11-pt Calibri (Body) font with appropriate section headings.

2. The assignment must be submitted in soft (electronic) copy under Moodle. The pages of the assignment must be clear on each page.

Marking criteria:

Sections Included in the Report Marks

Assignment #1 Progression: SRS document updates according to

the changes in your ongoing project

10

Recommended software engineering process model for your

project, (waterfall/evolutionary/spiral/prototyping) and factors

for selecting the process model

10

Context Diagram for the complete overall system 5

Use Case Diagram (Entire System)

5

Fully developed use case description for any 2 use cases scenarios

of your choice

10

Activity diagram (Any 2 scenarios) 5 + 5

Sequence diagram(s) (Any 2 scenarios) 5 + 5

Design Class Diagram (Entire system) 5

User requirement verification process 5

System Specification including technical, economical and

operational feasibility

10

Prepared by: Samira Baho Moderated by: Dr Shaleeza Sohail April, 2018 Page 4 of 6

Software testing and acceptance criteria 10

Final copy of the “Project Activity Journal” that shows weekly

progress of team work

10

Total 100

Prepared by: Samira Baho Moderated by: Dr Shaleeza Sohail April, 2018 Page 5 of 6

Marking Rubric for SRS document:

Grade/Mark

HD 80% -100%

D 70%-79%

C 60%-69%

P 50%-59%

Fail <50

Excellent Very Good Good Satisfactory Unsatisfactory

Assignment #1

Progression: SRS

document updates

according to the

changes in your

ongoing project

/10

Update all the

elements and

diagrams according to

the change in project

Most of the elements

and diagrams

update according

to the change in

project

Some elements

and diagrams

update according

to the change in

project

No update of

ambiguous changes

not relating with

project

Poor, not

acceptable

Recommended software engineering process model for your project /10

Good analysis of different software engineering models and selection criteria for recommended model clearly outlined

Most SE models are analysed and recommendation clear

Correct, with some deficiencies

No justification/explanati on for proposed software engineering process model

Poor, not acceptable

Context Diagram for the complete overall system /5

Diagram defines the boundary between the system and its environment, the entities that interact with it. All elements present. Diagram well designed.

Diagram defines the boundary between the system and its environment, the entities that interact with it. Most elements present. Diagram well designed.

Diagram defines the boundary between the system and its environment. Some elements are missing. Diagram not properly designed.

Diagram does not clearly define the boundary between the system and its environment. Some elements are missing. Diagram not properly designed.

Poor, not acceptable

Use Case Diagram

(Entire System)

/5

All actors and use

cases are defined

accurately with

proper notations

All actors and use

cases are defined

partly with

proper notations

All actors and

use cases are

defined partly

with wrong

notations

Missing few use

cases diagrams for

entire system.

Poor, not

acceptable

Fully develop use

case description

(Any 2 use cases)

/10

Both use cases with

all relevant elements

definitions

Both use cases with

partly relevant

elements

definitions

Both use cases

with few partly

relevant

elements

definitions

Both use cases

with ambiguous

relevant elements

definition

Poor, not

acceptable

Activity diagrams

(Any 2 scenarios)

/10

Both scenarios are

relevant with proper

defined activities

definition

Both scenarios are

partly relevant

with defined

activities

definition

Both scenarios

are relevant with

few partly

defined activities

definition

Both scenarios are relevant with ambiguous defined activities definition

Poor, not

acceptable

Prepared by: Samira Baho Moderated by: Dr Shaleeza Sohail April, 2018 Page 6 of 6

Sequence

diagram(s) (Any 2

scenarios)

/10

Both scenarios are

relevant with proper

defined sequence

definition

Both scenarios are

partly relevant

with proper

defined

sequence

definition

Both scenarios

are partly

relevant with few

partial defined

sequence

definition

Both scenarios are partly relevant with

ambiguous defined

sequence definition

Poor, not

acceptable

Class diagram

(Entire system)

/10

All classes are

defined accurately

with proper

relationship

notations

All classes are

defined

partly with

proper

relationship

notations

All classes are

defined partly

with wrong

relationship

notations

All classes are

defined ambiguously

with wrong

notations

Poor, not

acceptable

User Requirement

Verification

/10

Requirement validation technique followed; well explained and customer involvement and approval documented.

Requirement validation technique followed; clear and customer involvement mentioned

Requirement validation technique followed clear but customer involvement and approval not documented

Requirement validation technique followed clear, with some obvious shortcomings.

Poor, not acceptable

Software testing and acceptance criteria /10

Well defined and planned software testing and acceptance criteria clear

Software testing and acceptance criteria clear

Correct, with some deficiencies

Software testing criteria partly correct, with some obvious shortcomings.

Poor, not acceptable

Project Activity

Journal

/10

Developed

accurately with all

group members

participation

Developed partly

with all group

members

participation

Developed partly

with some group

members

participation

Developed

ambiguously

Poor, not

acceptable

Presentation

(In general and not

graded)

Mandatory

Excellent

presentation

, outstanding

Significant effort Good effort made

but not outstanding

Made some

effort, but only

acceptable

Poor, not

acceptable