000708229-MD.Mahmudur Rashid-ISE-1304-2011

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


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


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.



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.



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.


Key (In this rich picture)

External interested partyCrossed swordsMajor concernRelationship (Conflict area)

Think Bubble


Section A - Requirements analysis using Rich Picture:

Figure-1: Rich Picture of the Clean Brite Company (CBC) Ltd.



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



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,



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.



Section-B: Use Case Diagram

B.1.1 Use Case diagram for “Home Delivery Order Processing System”:


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


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.


Manufacturer


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


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)”.


Secondary Scenario: Cancel Order.

1. This secondary scenario begins when the user choose to cancel an order.

2. Select order to cancel.



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


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”.


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



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



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


• 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.



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



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



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



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.



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.



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>


http://www.bredemeyer.com/pdf_files/NonFunctReq.PDF

www.macs.hw.ac.uk:8080/techreps/docs/.../HW-MACS-TR-0085.pdf

http://www.jhebley.com/downloads/03-Use%20Cases.pdf

000708229-MD.Mahmudur Rashid-ISE-1304-2011

Documents

Transcript of 000708229-MD.Mahmudur Rashid-ISE-1304-2011