Three- Reflective Journal
8/6/2020 Laureate International Universities
https://laureate-au.blackboard.com/webapps/blackboard/content/listContent.jsp?course_id=_89880_1&content_id=_8975602_1&mode=reset 1/5
MODULE 4MODULE 4
Visual representations of requirements and requirement
validation
Source:
https://www.modernanalyst.com/Careers/InterviewQuestions/tabid/128/ID/1804/What-
is-a-Swimlane-Diagram.aspx
Introduction:
8/6/2020 Laureate International Universities
https://laureate-au.blackboard.com/webapps/blackboard/content/listContent.jsp?course_id=_89880_1&content_id=_8975602_1&mode=reset 2/5
In Module 3, you learned use case diagrams and how they can used to
model what the system or a use can do. Module 4 continues to teach you
how to use visual diagrams to module di�erent aspects of the system. Apart
from what the system can do, what are the other aspects of the system that
are of interest to a requirement engineer? For example, as a requirement
engineer you may want to de�ne the boundary of the system, what are the
external entities that interact with the system. To model the boundary and
the interactive external entities, you will need a Context Diagram. You may
also want to understand the data models and their relationships. In this
case, you will need to draw an Entity Relationship Diagram (ERD). You also
need to understand business processes and the steps in each complex
business process. A Data Flow Diagram (DFD) and Swimlane Diagram are
designed for modelling that aspect of the system.
Visual representations of requirements modules complement requirements
written in text, but they are not replacements for the written requirements.
Both representations (visual and text) have their own advantages and
disadvantages.
Module 4 does not seek to teach all UML diagrams, rather it teaches a
sample of UML diagrams, including Swimlane diagram, State Transition
Diagram and dialog map. Other UML diagrams are (or will be) taught in
other Subjects, e.g. Context Diagram, DFD (MIS605) and ERD (MIS602). With
the foundation you learn in these Subject, you will �nd it much easier to
learn a new diagram and understand the aspect(s) of the system the
diagram seeks to model.
Module 4.2 primarily focused on requirement validation. Imagine you
engage a builder to build a residential house. After requirement elicitation,
analysis, design and construction, you �nally received the key to your new
house. Before you move in, you will conduct an inspection of the house. You
would like to check whether the builder has built a house in accordance with
what you told them during the requirement elicitation phrase and in
accordance with the requirement speci�cation that you signed o� a few
8/6/2020 Laureate International Universities
https://laureate-au.blackboard.com/webapps/blackboard/content/listContent.jsp?course_id=_89880_1&content_id=_8975602_1&mode=reset 3/5
months ago. This �nal check, i.e. verifying whether the end product meets
the stated requirements, is called requirement veri�cation.
You will agree that if at the veri�cation stage you �nd any errors in the
requirements, e.g. you did not mean to build a double story house, it is very
expensive to �x that error. Therefore, it is crucial to validate the
requirements before implementation to ensure they actually re�ect the
customer needs.
Module 4.2 will teach you how to perform requirement validation. For
example, what are the steps to follow in the requirement validation process.
What are the roles and responsibilities in this process? You learnt that
prototyping is an e�ective tool used in requirement elicitation. You will also
see how prototyping can also be adopted in the requirement validation
process.
This Module will cover:
Module 4.1 – Visual representations of requirements
Module 4.2 – Requirement Validation
This Module will help you achieve the following outcomes:
a) Evaluate methods of documenting, maintaining and measuring requirements to relate to business need.
b) Identify, select and develop requirements to maximise e�ectiveness in the enterprise and promote sustainable business practices.
Time Management:
Your workload expectation is 20 hours for this module.
8/6/2020 Laureate International Universities
https://laureate-au.blackboard.com/webapps/blackboard/content/listContent.jsp?course_id=_89880_1&content_id=_8975602_1&mode=reset 4/5
20 hours per module (two weeks): facilitated study: 3 hours / week. Personal Study: 7 hours / week.
3 hours facilitated study consists of attending class, responding to facilitator feedback.
You are to allocate 7 hours of personal learning. This includes essential time spent on pre-reading and viewing materials, assessment progression and learning activities.
Assessment Progression:
Assessment 2 is due by the end of this Module. You are required to write a
Software Requirement Speci�cation (SRS) document for a proposed system.
In the SRS, in addition to use case diagram (Module 3), you are required to
model other aspects of the system, for example, you are required to draw a
state transition diagram as well as a Swimlane diagram. Module 4.1 content
is closely relevant to Assessment 2.
Class Expectation:
You are expected to have worked through the essential learning resources and activities for this module before attending the facilitated session (face to face or online session) – this enables informed discussion and full participation in learning activities.
Participate in all scheduled facilitated sessions.
This time is intended to be used by you and your learning facilitator to work through activities and engage in discussion about the module content.
These sessions provide a space for you to raise questions about the module content and seek guidance on writing your assessments.
You will review, explore and discuss more deeply the information presented in the learning resources.
8/6/2020 Laureate International Universities
https://laureate-au.blackboard.com/webapps/blackboard/content/listContent.jsp?course_id=_89880_1&content_id=_8975602_1&mode=reset 5/5