000708229-md.mahmudur rashid-ise-1304-2011
DESCRIPTION
goof research paperTRANSCRIPT
A
COURSE WORK REPORT
ON
Clean Brite Company Limited (CBC) Ltd.
Submitted in
partial fulfillment for the
Award of degree of
BECHELOR OF SCIENCE
IN
BUSINESS INFORMATION TECHNOLOGY
(2011-12)
COURSE: COMP1304
INFORMATION SYSTEMS ENGENEERING
Submitted By:
MD. MAHMUDUR RASHID
Student ID: 000708229
Submitted to:
Mr. Phil Clipsham
Greenwich Coordinator
Information System Engineering University of Greenwich
Student declaration
I have read and understood UOG Policy on Academic Dishonesty and Plagiarism. I can confirm
the following details:
Student ID: 000708229
Name: MD. Mahmudur Rashid
Centre Name: Daffodil Institute of IT
Module Name: Information System Engineering (ISE)
Number of words:4,225
I confirm that this is my own work and that I have not plagiarized any part of it. I have also noted
the assessment criteria and pass mark for assignments.
Due Date: 14th Nov, 2011
Submitted Date:
14thNov, 201
B.Sc. Hon’s in Business Information Technology
Information System Engineering University of Greenwich
Table of Contents
Section Page
Introduction ------------------------------------------------------------------------------------------------------------- 7
Section-A: Rich Picture ------------------------------------------------------------------------------------------------- 8
A1: Rich Picture ----------------------------------------------------------------------------------------------- 8
A2: Discussion and Justification of Rich Picture ------------------------------------------------------- 9-11
Section-B: Use Case --------------------------------------------------------------------------------------------------- 12
B1.1: Use Case Diagram ------------------------------------------------------------------------------------ 12
B1.2 & B1.3 ------------------------------------------------------------------------------------------------ 12-14
B2 ----------------------------------------------------------------------------------------------------------- 15-18
Section-C: Critical Analysis ------------------------------------------------------------------------------------------ 19-21
Conclusion ----------------------------------------------------------------------------------------------------------------- 23
Bibliography -------------------------------------------------------------------------------------------------------------- 24
List of Figures
Figure-1 ------------------------------------------------------------------------------------------ 8
Figure-2 ------------------------------------------------------------------------------------------ 12
B.Sc. Hon’s in Business Information Technology4
Information System Engineering University of Greenwich
List of Tables
Table-1.1 ------------------------------------------------------------------------------------------ 13
Table-1.2 ------------------------------------------------------------------------------------------ 13
Table-2.1 ------------------------------------------------------------------------------------------ 14
Table-2.2 ------------------------------------------------------------------------------------------ 14
Table-3.1 ------------------------------------------------------------------------------------------ 15
Table-3.2 ----------------------------------------------------------------------------------------- 15
Tools used:
The following tools are used to develop this Internet banking system:
Rich Picture.
Use Case Diagram.
Use Case description.
B.Sc. Hon’s in Business Information Technology5
Information System Engineering University of Greenwich
Assumptions:
As the scenario suggests I assumed that, the new system would be a web based application that will
process all necessary activities to make an order and trace order. This facilities and functionalities of this
web application will follow the format used by many successful e-commerce sites such as ordering via
website, purchase via credit card, browse online catalogue and track orders online. The customer must
need to register before use these services and must be logged in to the system to do the order, cancel
order or track order activities which will validate by the system. Telesales staff can do the same work on
behalf of the customer by using this system internally.
B.Sc. Hon’s in Business Information Technology6
Information System Engineering University of Greenwich
Introduction:
This course work report is about a company named Clean Brite Company (CBC) which is one of the leading suppliers of cleaning products to different industry and commercial company. This company does not manufacture any cleaning product itself rather than it purchases products from different manufacturers, repackages them and sells them on.
In section-1 of this course work I have produced a Rich Picture which will clearly identify the whole environment of the company and illustrated all the necessary actors, data, processes etc laid in this problem domain. Then I made a short discussion and justify the picture based on my experience.
In section-2 I have represented a use case diagram with description including the actors and processes for the “Home Delivery Order Processing System” which I found from the appendix-A from of the given scenario. I also carried a discussion and justification for this use case diagram.
In section-3 I took a critical analysis of the tools I have been used to understand the requirements in the previous section based on my experiences.
B.Sc. Hon’s in Business Information Technology7
Key (In this rich picture)
External interested partyCrossed swordsMajor concernRelationship (Conflict area)
Think Bubble
Information System Engineering University of Greenwich
Section A - Requirements analysis using Rich Picture:
Figure-1: Rich Picture of the Clean Brite Company (CBC) Ltd.
B.Sc. Hon’s in Business Information Technology8
Information System Engineering University of Greenwich
Section-A2: Discussion and justification of rich picture
A2.1:
Actors are very essential part of a rich picture and it is more important to identify them accurately and
represent them clearly.
I have identified the key actors in the given environment by analyzing the roles that are participated in
many activities and sharing information within the environment. The major concern is to identify these
key roles to analyze that who are the stakeholders of the environment and by whom it could be affected
anyway (ex: by thoughts, roles or being silent). All these key actors are called problem owners of the
situation. They all have some expectation or thoughts or roles which is a part of this problem domain.
Their thoughts, beliefs and views are very important subjective fact for drawing this rich picture. I
searched all over the given environment carefully to identify and determine these. I also determined
that by whom or what the issues are arising in this environment. I looked out specifically by whom or
what conflictions occurred and worries are generated. Then I put these roles and their thoughts in a
bubble in the area of the environment where they are belong to in my rich picture.
For example while I studied the given problem domain I have found that Executive Board members has
some concerns and worries about the IT projects that are failed to meet company’s goals and worth a
lots of money. Then they performed a role by appointing a consulted to review the situation which
obviously made affect the situation. So they should call one of the key actors of this environment.
A2.2:
I have analyze the problem situation of the Clean Brite Company (CBC) Ltd. in the context of
conversation occurs between actors/stakeholders during the processes or operations to identify key the
issues and areas of conflictions. I have examined their worries, expectations and thoughts lied in the
environment and where these are co-related to make conflictions. I have identified the issues that are
responsible to create individual thoughts and behavior in such way where their opinion differs from
each other directly or indirectly. I also identified the areas where these kinds of issues occurred.
The review report (which I found in the given case study) of the Company generally and the I.S.
development functions specially undertook by an external management consultant appointed by the
executive board led me to chose the key issues and areas of conflict affecting the company’s
B.Sc. Hon’s in Business Information Technology9
Information System Engineering University of Greenwich
environment. I have exercised this review carefully to understand the problem situation within the
company as well as individual thoughts, concerns and beliefs in the working situation. Then I
demonstrated and draw the facts and issues on the rich picture that arise in this situation and turned
into social or political confliction. To represent and highlight these conflictions I used “Cross Swords”
icons. I look over the whole problem situation and dig out the issues from different areas of the problem
domain that causes confliction to the environment.
A2.3:
In general this rich picture is basically focused to create a pictorial view of a problem situation consists
of different cartoon-like figures and icons that describe the soft and hard facts of this organization from
an analyst’s point of view to make a medium that is easy to understand and represent between
stakeholders and developers. I have tried to highlighted the main focuses by demonstrate and draw
conceptual factors related with individuals, processes, communications within the environment. In this
picture more concentration has been given to understand the whole problem situation rather than the
exact problem. This is because to find out the root causes of problems from that these arises.
In more specifically to identify and represent the issues in different areas within the problem domain
that causes the failure of the IT projects of CBC Ltd as executive board concerned of and to clearly draw
the possible reasons of these issues are the main focus of my rich picture. It is also focused to highlight
the cultural issues, social values and individual thoughts to demonstrate the whole environment of the
CBC Ltd.
A2.4:
After analyzing the whole environment of the Clean Brite Company (CBC) Ltd I constructed my picture by
looking for elements of structure of problem area. Then I had find out the elements of processes and
built a relationship of these structure and processes that represents the climate of the situation.
I have identified the control of systems, data processing of the environment in my picture. These are
lying along with the communications line I drowned. The large bubbles and rectangular notations that I
used to indicate the top level management and user groups of the systems who are generally control
the system by their thoughts and behavior within the environment. Data of this environment lies in
different areas. These data are generally handled and processed during sales and purchase operations,
B.Sc. Hon’s in Business Information Technology10
Information System Engineering University of Greenwich
intercommunication between stakeholders and report generation processes. Although there is a data
storage which stores all necessary data needed by the company such as stock control data.
The primary task/goal of this company is to sale cleaning products to different industry and commercial
sector. To fulfill this goal there are many processes are take place in different areas of the environment.
This processes mainly lies in the product sales functionalities, purchase orders from the manufacturer,
repackages them and so on as I draw on the below of the picture. In the IS department the processes
lies mainly to provide different IS and IT services to the end user to assist their work as well as maintain
their internal staffs and contractors. This department is mainly distinct from the other departments as I
represent in the rich picture.
B.Sc. Hon’s in Business Information Technology11
Information System Engineering University of Greenwich
Section-B: Use Case Diagram
B.1.1 Use Case diagram for “Home Delivery Order Processing System”:
B.Sc. Hon’s in Business Information Technology12
Process Orders
Place New Order
View Catalogue
Select Product
Advice Initial Cost
Select Delivery Method
Show Final order Cost
Confirm Orders
Trigger purchase Order
Validate Customer
Shipping Agent
Generic User
Telesales Staff
Web Access Customer
<<uses>>
<<uses>>
<<uses>>
Check Availability
<<uses>>
<<extends>>
<<uses>>
Checks re-order level
<<uses>>
Check Status
<<uses>>
<<uses>>
<<extends>>Track order(s)
Show status
<<uses>>
Select order
Cancel Orders
Notify Agent
Information System Engineering University of Greenwich
Figure-2: Use Case Diagram for Home Delivery Order Processing System.
B-1.2: Primary Use Case Scenario-1:
Use case description
Use Case: Select Product(s).
Use Case ID: U001
Primary Actors: Web access customer, Telesales staff
Secondary Actors: None
Pre-conditions: User must be logged in to the system and validate.
Flow of Events:
1. The use case begin when the user select product and quantity to place a new order.
2. Check availability.
3. Advise the preliminary cost to obtain the product(s).
4. Select the method of delivery.
5. Display final order cost.
6. Confirm the order.
Secondary Scenarios: Product(s) not available.
Post-conditions: An order number will be given by the system.
Table-1.1: Primary scenarios for “Place new order(s)”.
B-1.3: Secondary Use Case Scenario-1:
Secondary Scenario: Product(s) not available
1. This secondary scenario begins after the stage 1 of the primary scenario.
2. In step 2, the product(s) is checked that it is available or not.
B.Sc. Hon’s in Business Information Technology13
Manufacturer
Information System Engineering University of Greenwich
3. After step 2, if the product is not available then the user informed that is unobtainable.
Post condition: The user will receive message that is available or not.
Table-1.2: Secondary scenario for “Place new order(s)”.
B-1.2: Primary Use Case Scenario-2:
Use Case Descriptions:
Use Case: Track Order(s)
Use Case ID: U002
Primary Actors: Web access customer, Telesales staff
Secondary Actors: None
Pre-conditions: User must be logged in to the system and validate.
Flow of Events:
1. This use case begins when the user choose to track outstanding order(s).
2. Show order’s statuses with all necessary information about the ordered products
(dispatched, are in the process of being dispatched and are unobtainable).
3. Show the shipping agent used and the type of delivery.
4. Show delivery method selected.
Secondary Scenarios: Cancel Order.
Post-conditions: All outstanding order made by the particular customer will be displayed.
Table-2.1: Primary scenario for “Track order(s)”.
B-1.3: Secondary Use Case Scenario-2:
Secondary Scenario: Cancel Order.
1. This secondary scenario begins when the user choose to cancel an order.
2. Select order to cancel.
B.Sc. Hon’s in Business Information Technology14
Information System Engineering University of Greenwich
3. Check status.
4. Confirm cancel.
Post condition: The user will receive a message that order has been cancelled successfully or not.
Table-2.2: Secondary scenario for “Track order(s)
B1.2 Primary Use Case Scenario-3:
Use Case Descriptions:
Use Case: Notify Agent.
Use Case ID: U003
Primary Actors: The system itself
Secondary Actors: None
Pre-conditions: Order not confirmed.
Flow of Events:
1. This use case begins after the user confirms order to obtain.
2. Send order details to the shipping department.
3. Select appropriate agent.
4. Notify agent.
Secondary Scenarios: Confirmation cancelled.
Post-conditions: The user will receive a message that notification 4sent or not.
Table-3.1: Primary scenario for “Notify Agent”.
B-1.3: Secondary Use Case Scenario-3:
Secondary Scenario: Order not confirmed.
1. This secondary scenario begins during the stage 1 of the primary scenario.
2. In step 2, display a message box containing a message “confirm order” with ok and cancel
B.Sc. Hon’s in Business Information Technology15
Information System Engineering University of Greenwich
button.
3. After step 2, if the user clicks on cancel button then the process reverse to previous step and no
notification will send to the shipping agent.
Post condition: The user will receive a message that order has not been confirmed.
Table-3.2: Secondary scenario for “Notify Agent”.
Section B2: Discussion and justification of final Use Case Diagram:
B2.1
I have chosen the actors because of:
Actors are those roles that playing an active part in the operation of a system. It may be a particular
person’s role, perhaps a job description (clerk) or a relationship (customer). It also could be other
external system having behavior to the system. The system under design also could be an actor itself, a
special one. The system need to initiate and perform its goal via some kind of actor. Actors are not part
of the system; they supply input to and receive output from, to the system. They are very important to
identify because actors collectively define the environment of the system.
They are key to the system because without actor performing or operating a use case it has no existence
within the system. The roles that carried out by these actors have some significant impact on the
system. As they give input to the system and receive output from, the functionality relies heavily on
their input and action they have taken to get expected output.
B2.2
I have chosen the “Select Product” Use Case scenario to demonstrate the answer for this sub-section.
At first I have identified the primary actor/actors by whom this use case will initiate and operate. For this
use case these primary actors are: web access customer and telesales staff. Then I have identified the
secondary actor/actors. This use case has no such secondary actor/actors. After that I find out the pre
condition that needs to be met before the Use Case begins. For this use case the precondition is that the
user must be logged in to the system and validate. Then I include the basic functionalities and the
normal flow of events for this use case to meet its goal. This flow of events consists of three key
B.Sc. Hon’s in Business Information Technology16
Information System Engineering University of Greenwich
activities or actions; they are: an interaction, a validation or a stage change. I have included all these key
activities step by step in its flow of events section. Then I identify secondary scenario for this use case
which would be initiated in situation of any condition take place during the normal flow of events. For
this scenario it may occurs while a selected product is not available. I also determine the alternative flow
for this secondary scenario of this primary scenario in a distinct table below of primary scenario. At last I
identify the post condition that is represent the situation or output after that use case’s normal flow has
been completed. All of these key activities I have identified by analyzing the scenario and determined
the key activities by how and what could be happened in all of potential situation in operation of this
scenario. It is an iterative manner to identify key activities to include.
B2.3
In general Use Cases complete successfully when its goal is satisfied after completing its normal flow of
events. But there may alternate flow of events to meet its goal as well as sequences. These alternate
flows may cause system failure to complete the service if any exceptional behavior or error occurs. I
have identified all the alternative options available, depending on input from the Actor such as invalid ID
or password input. I also identified the business rules that may come into play in any step of the normal
flow of events such as checking availability while customer selects products to order. It is also expected
to arise any error during the normal situation that may interrupt the normal flow of events. I carried an
iterative development of these scenarios to identify alternative uses to produce the secondary
scenarios. I examined each possible scenario to determine whether it is relevant to this use case, which
demonstrates that it can actually happen, and that it is distinct from other scenarios. I removed
redundant or unnecessary scenarios, and then start concentrating on the more important ones.
B2.4:
To make further assumption for the proposed system and clarify requirements I need to ask some
particular question in the area to select actors and use cases. The use case diagram and description
would be produced based on these questionnaires.
The following questions can helps to identify the actors of the system
(Schneider and Winters, 1998):
• Who uses the system? B.Sc. Hon’s in Business Information Technology
17
Information System Engineering University of Greenwich
• Who installs the system?
• Who starts up the system?
• Who maintains the system?
• Who shuts down the system?
• What other systems use this system?
• Who gets information from this system?
• Who provides information to the system?
• Does anything happen automatically at a present time?
Then, the scenario-based requirements elicitation process continues by asking what outwardly visible,
measurable result of value that each actor desires. The following questions can be asked to identify use
cases, once the actors have been identified
(Schneider and Winters, 1998):
• What functions will the actor want from the system?
• Does the system store information? What actors will create, read, update or delete this
information?
• Does the system need to notify an actor about chances in the internal state?
• Are there any external events the system must know about? What actor informs the system
of those events?
I would ask these questions mainly to the business analyst who are responsible analysis the whole
business situation and knows the business rules.
B.Sc. Hon’s in Business Information Technology18
Information System Engineering University of Greenwich
Section-CCritical analysis of the tools used:
Understanding the user requirements for a developer in the system development process is one of the
most critical and important issue at the same time. Any systems success heavily depends on
understanding of the needs and requirements of the users. All the successful system focused to this
point at the beginning of the development. Users are the core basis of a system as well as the
development process. So developer always should be aware of their requirements that will reflect by
the developed system.
To understand the full requirements of a system isn’t an easy work for a developer due to some
particular problems those faced during the requirements analysis. I have identified some useful
outcomes while I used the rich picture and use case tools during requirement analysis of this scenario
which helps me to overcome the problems.
Based on the experiences gathered from above sections of this course work I feel a wide range of
necessity of using a range of tools to understand the full requirements of a system. Systems aren’t come
alone for development. It is the users who are responsible for developing a system to meet their
particular needs/requirements. The system’s ultimate goal is achieved by integrating and eliciting these
requirements successfully as users wants. As it is difficult to understand the requirements mentioned
above, developer could use a range of tools to do this. One tool may not appropriately illustrate the full
requirements in an understable form in a particular situation. Then there should be options for
understand the requirements by using another tools.
Based on my experience from section A and B I have been realize that to understand different areas of
user requirements needs a range of different tools. I used rich picture to understand the given problem
B.Sc. Hon’s in Business Information Technology19
Information System Engineering University of Greenwich
situation and environment of the system in section A of this coursework. It is a tool to generate
discussion both in order to reach an understanding and to tease out relevant issues for systemic
investigation. One of the purposes to drawing a rich picture diagram is to avoid “design before analysis”.
By using this tool I tried to demonstrate the climate of the situation, structure of the problem domain,
clarify the actors or stakeholders thoughts, social roles and interrelationship within the environment,
draw out the processes it needs to operate, identify interfaces, boundaries, the control of resources. The
analyses of such factors are not contained in other tool but are of importance in systems development.
Rich pictures enable me to draw simple figures of thoughts and speech bubbles linked which help me to
show particular problem areas that may lead to new user requirements. Rich picture is not a tool to
specify requirements but it helps to understand and point out the areas in where these requirements lie
hidden within the environment. I have found this tool so helpful in the area of understanding the
problem domain as well as user requirements of the system and what need to do to eliminate the
conflictions occurs. This rich picture could help me to find out the possible areas of the environment
that should be focused during the development. Personnel thoughts and expectations made it easier to
assume the requirements and their behavior and roles that should be reflected by the potential system
can be determined. This rich picture can be a suitable and an easy to understand medium to analyze
user requirements which could be used to communicate with the project owners and stakeholders. I
have already gathered much practical knowledge about the environment and the problem domain
which will help me to elicit and prioritize user requirements. The root causes for any confliction and
problem could be identified by using this picture. In a word this tool helps me to make a clear and robust
understanding about the environment which will obviously affect and help me for developing any
proposed system.
Although rich pictures are very useful tool to use; it has some weakness.
Because there is no standard for symbols and icons to use in rich picture so it seems difficult for
developers in remembering the meaning of the symbols. It can easily possible to understand by the
stakeholder and the analyst of the environment for which the picture drowned but it is quite difficult to
understand by any third party if necessary. Readers of the pictures might mistake and misconstrue
meaning. Motivate and encourage stakeholders to discuss their personal opinions and thoughts often
difficult because if it puts negative impacts on the organization they work for. Sometimes management
wants to avoid political issues that could arise. So the process of requirements gathering of rich picture
B.Sc. Hon’s in Business Information Technology20
Information System Engineering University of Greenwich
become lengthy and analyst engage unwillingness to produce it. It is also difficult to produce
computerized drawing because non standard symbols are difficult to draw using graphics software. So
rich pictures not well used as DFD, ERD etc.
Another tool that I have used in section B is use case diagram and descriptions. I found that tool is very
useful to produce the goal of a system by a set of interactions between external actors and system
under consideration. This use case diagram and use case description I carried, allowed me to know
about the system’s requirements that are what needs to system to do according to particular actor’s
interactions. I have tried to do the entire necessary task that this modeling tool recommends in section
B and it seems very helpful to me to understand the full requirements of the system. I illustrated the
basic functionalities and actors co-operation during the system runtime. I produce the normal flow of
events as well as the alternative path that could fulfill the goal alternatively of a particular process
causes for a predefined condition or error. This kind of alternative paths also applied for carry out some
business rules in a particular situation. For example, while a customer chooses to cancel his/her order
the system should check the order status that it has been sent for shipping or not. If the order has been
sent then the customer can not cancel this particular order as the business rules recommend.
By using this too I have identified two types of actors who are involved with the system: primary actors
and secondary actors. These actors are responsible for initiating a use case with a particular goal in mind
and complete successfully when this goal is satisfied. This tool particularly helps me to realize the core
requirements of the system and document these requirements in a communicative form for further
analysis. I have identified the pre-conditions for a use case that should be met before any operation
begins and the expected results as post conditions by using this tool. This tool greatly helped me to
understand and observe the whole situation and technical issues of a particular functionality. It was
clearly demonstrated the actor’s interactions and the processes step by step in its normal flow of events.
I could define the specific input and outputs that the system need for proceeding to get some results.
I have found some weaknesses of use cases based on my experience of work in section B, and these are:
Any commonality/variability across products in a product line or family could not be reflected by use
cases. However it is tough to fulfill many non-functional requirements in use cases. Perhaps these non-
functional requirements are possible to fulfill by a conjunction of use cases and that isn’t so easy to do.
It is difficult for developers to decide on the appropriate level of abstraction to which to take the use
B.Sc. Hon’s in Business Information Technology21
Information System Engineering University of Greenwich
cases, and experience an uncontrolled and time-consuming proliferation in their use cases. It may be
that a more traditional list of core functions and differentiating features is more succinct, though I have
seen such documents can also expand into hundreds of pages!
There are so many tools available to do the same work. In practice it is very useful and productive to use
different tools in different areas of development. The challenge for the developer is to identify and apply
the most useful and suitable tools in his/her development or design of a particular system. One tool is
particularly expertise in solving problems of a particular area.
B.Sc. Hon’s in Business Information Technology22
Information System Engineering University of Greenwich
Conclusion:
I have gathered a great deal of experience by using the tools to eliciting requirements from a given
scenario during this course work. I realize the necessity of using various kinds of tools in system
development lifecycle. Regardless the drawbacks of those tools I seem they are pretty much essential
and helpful to understanding user requirements. Sometimes it could be difficult to use such tools due to
user’s lack of knowledge and if they do not cooperate properly.
B.Sc. Hon’s in Business Information Technology23
Information System Engineering University of Greenwich
Bibliography
David Avision, Guy Fitzgareld 2006, Information Systems Development, 4th edn, The McGraw-Hill, Shoppenhangers Road, Maidenhead, Berkshire.
Bredemeyer, RMAD 2001, bredemeyer.com/pdf_files/NonFunctReq.PDF, viewed 18 October 2011, <http://www.bredemeyer.com/pdf_files/NonFunctReq.PDF>.
Kurt Vonnegut, Use Cases-A review,2004,jhebley.com/downloads/03-Use%20Cases.pdf,viewed 19 October 2011,
< http://www.jhebley.com/downloads/03-Use%20Cases.pdf>
Tessa Berg & Rob Pooley, Contemporary Iconography for Rich Picture Construction, viewed 19 October 2011,
< www.macs.hw.ac.uk:8080/techreps/docs/.../HW-MACS-TR-0085.pdf>
B.Sc. Hon’s in Business Information Technology24
Information System Engineering University of Greenwich
B.Sc. Hon’s in Business Information Technology25