CSIT114 - System Analysis

Enterprise Resource Planning (ERP)

This software manages businesses' activities. It combines business departments, acting as a central location to enable each department to share information, data and processes with the rest of the company. It facilitates collaboration and tracks all the businesses' information and data. Although it can be tailored to an organisation's needs, it can be expensive and difficult to do so.

SDLC

1. Identify the problem or need and obtain approval,

2. Plan and monitor the project,

3. Discover and understand the details of the problem or the need,

4. Design the system components that solve the problem or satisfy the need,

5. Build, test, and integrate system components

6. Complete system tests and then deploy the solution

1 of SDLC

Identify the problem or need and obtain approval

(a) Identify the Problem,

(b) Quantify Project Approval Factors,

(c) Perform risk and feasability analysis,

(d) Review with the client and obtain approval

2 of SDLC

Plan and monitor the project,

(a) Establish the Project Environment,

(b) Schedule the work,

(c) Staff and allocate resources,

(d) Evaluate work processes,

(e) Monitor progress and make corrections

What is a successful project?

Completed on time, within the budge, on scope requirement

What is a challenged project?

One area failed, being late, over the budget, scope reduction

What is a failed project?

Cancelled, not being used

What are reasons for a failed project?

• Manager not managing properly,

• Poor IT management and procedures,

• Inadequate executive support,

• Inexperienced project managers,

• Unclear business needs and project objectives (related to communication),

• Inadequate user involvement.

So projects usually fail with poor managing skills and/or lack of executive involvement but never with poor programming skills.

Project Management

The process of organising and directing other people to achieve project or a planned result within a schedule and budget where everything is planned, then monitored and controlled

Project Manager Internal Responsibilities

• Develop project schedule,

• Recruit and train team members,

• Assign work,

• Assess project risk and

• Monitoring and controlling project deliverables and milestones

Project Manager External Responsibilities

• Reporting the project's status and progress,

• Working directly with the client (funds the project) and other stakeholders and

• Identifying resource needs and obtaining resources

External Stakeholders

Client, oversight committee, users; Those outside the organisation’s control and influence

Internal Stakeholders

Development team, subcontracters (from the client's company) and technical staff; Those within the organisation who interact with the system or have a significant interest in its operation or success

Technical Staff (Stakeholder)

Familiar with the project but not part of the development team which makes them good members to join the testing team

Client (customer)

A person or group that funds the project. The project approval is needed from them; Those outside the organisation’s control and influence

Oversight (steering) committee

This group is made out of clients and managers who have a vision of the organisation's strategic direction and have a strong interest in the project's success. They review the progress and direct the project externally through the project manager.

Users

An individual or group of people who will use the new system and so they provide information regarding the functions and operations needed

3 of SDLC

Discover and understand details,

(a) Gather detailed info,

(b) Define requirements,

(c) Prioritise requirements,

(d) Develop user-interface dialogs,

(e) Evaluate requirements with users

Ceremony (level of formality)

How formal the project's decision-making process is i.e. the amount of documentation made and specification traceability

3 Reasons Why Projects Are initiated?

(1) Responding to opportunities (market share and/or new market),

(2) Resolving a problem and

(3) Responding to an external directive

What does the System Vision Document Contains?

(1) Problem Description,

(2) System Capabilities and

(3) Business Benefits

Problem Description

What the problem is and idea for the solution

System Capabilities (System Vision Document)

The required capabilities of a new system

Business Benefits

Tangible and intangible business/organisation benefits

Cost/Benefit Analysis

The process of comparing costs and benefits to see whether investing in a new system will be beneficial

Break-even point

When the money earned equals the money spent on a project

Payback Period

The length of time before the break-even-point, which is how long it takes for the money earned from the project to equal the money spent on it

Tangible Benefit

A benefit that can be measured or estimated using money

Intangible Benefits

A benefit that can't be measured quantitively or estimated accurately i.e. increased levels of server and customer satisfaction and survival

Examples of Intangible Costs

Reduced employee morale, loss of productivity, lost of customer or sales

System Requirements

All the things a new system needs to do and support and the rules it needs to follow

Functional Requirements

The activities that the system must perform i.e. the business process and uses the system will be applied to. Identifying and describing these can take lots of time because the list of business functions and what they depend on can be very complex.

Non-functional Requirements

These are the characteristics of the system that are not activities it must perform or support. It usually has to do with usability, reliability, performance and security.

FURPS

• Functional

• Usability

• Reliability

• Performance

• Security

Usability Requirements

Describes the operational characteristics related to the users and usually has something to do with user interfaces.

Reliability Requirements

Describes the dependability of a system and how often there is unreliable behaviours i.e. outages and incorrect processing and then how it detects and recovers from those problems

Performance Requirements

Describes operational characteristics related to the workload i.e. response times.

Security Requirements

Describes how the data will be controlled and protected during storage and transmission.

User Story

A short sentence in the user’s or stakeholder’s everyday language that states what a user does as part of his work and describes what goal they want to achieve when using the system e.g. standard temple is “As a <role played>, I want to <goal or desire> so that <reason or benefit>”

Acceptance Criteria

This indicates the features that the system needs to have for the user to be satisfied with how the system has been implemented, focusing on the functionality rather than the user-interface design.

Use Case

An activity the system performs because a user requested for it to happen. The techniques to identify this is (1) user goal technique and (2) event decomposition technique

User Goal Technique Steps

This identifies use cases:

1. Identify all users for the new system

2. Classify user by their functional role and by organisational level

3. Interview each user type to determine the specific goals they have for the new system and how the system will improve the user’s performance and productivity.

4. Encourage the users to imagine innovative functions that would be helpful beyond the boundaries of the way they currently do their jobs

5. Create a list of use cases organised by user type

6. Resolve inconsistencies and remove duplicates with similar use cases

7. Identify where different user types need the same use cases

8. Review completed list with each user type and then the interested stakeholders.

Elementary Business Process (EBP)

A task that is performed by one person in one place as a response to a business event that adds business value and leaves the system and its data in a stable and consistent state.

Event

Something that occurs at a specific time and place, can be described and should be remembered by the system as they drive or trigger all the processing that a system does

External Events

An event that occurs external to the system usually initiated by an actor

Actor (external agent)

Person or organisational unit that supplies or receives data from the system

Temporal Events

An event that occurs as a result of reaching a point in time but does not have to occur on a fixed date and can occur after a defined time period has elapsed

State Events

An event that occurs when something happens inside the system that triggers the processing need

Perfect Technology Assumption

The assumption that a system runs under perfect operating and technological conditions

System Controls

Checks or safety procedures put in place to protect the system’s and data’s integrity.

Event Decomposition Technique Steps

1. Consider external events in the system environment that require a system response

2. Identify and name the use case that the system requires for each external event

3. Consider temporal events that require a system response

4. Identify and name the use case that the system requires for each temporal event

5. Establish the point of time that will trigger the use case

6. Consider state events that the system might respond to

7. Identify and name the use case that the system requires for each state event

8. Define the state change

9. Check to see if events and use cases are required as part of the analysis by using the perfect technology assumption

Use Case Diagram

Unified Modeling Language (UML) model used to visually illustrate use cases and their relationship to users as it depicts the use cases and how they are organised.

Unified Modeling Language (UML)

The standard diagram set and model constructs used in system development

Automation Boundary

This defines the border between the computerised part of the application and the people operating the application. It is represented by a rectangle surrounding the use case.

<<includes>> relationship (<<uses>> relationship)

A relationship between uses cases where one use case is stereotypically included within the other use case (function inside another function); one use case uses or includes another use case

Developing a Use Case Diagram Steps

1. Identify all the stakeholders and users who would benefit by having a use case diagram

2. Determine what each stakeholder or user needs to review in a use case diagram

3. Select the use cases and actors to show and draw the use case diagram

4. Name each use case diagram and note how and when the diagram should be used to review use cases with stakeholders and users.

Detailed Work Schedule

This lists, organises and describes the dependencies of the detailed work tasks

Project Iteration Schedule

The list of iterations and use cases or user stories assigned to each iteration.

Work Breakdown Structure (WBS)

The list or hierarchy of activities and tasks of a project; used to estimate the work to be done and to create a detailed work schedule

Project Management Body of Knowledge (PMBOK)

• Project Integration Management

• Project Scope Management

• Project Time Management

• Project Cost Management

• Project Quality Management

• Project Human Resources Management

• Project Communications Management

• Project Risk Management

• Project Procurement Management

• Project Stakeholder Management

Gantt chart

A bar chart that portrays the schedule by the length of horizontal bars superimposed on a calendar

Retrospective

A meeting held by the team at the end of an iteration to determine what was successful and what can be improved.

Event Decomposition Technique

This starts by identifying all the business events that the system responds to with each of these events leading to a use case.

Elementary Business Process (EBP)

A task that is performed by one person in one place as a response to a business event that adds business value and leaves the system and its data in a stable and consistent state.

Event

Something that occurs at a specific time and place, can be described and should be remembered by the system as they drive or trigger all the processing that a system does

External Events

An event that occurs external to the system usually initiated by an actor

Actor (external agent)

Person or organisational unit that supplies or receives data from the system

Temporal Events

An event that occurs as a result of reaching a point in time

State Events

An event that occurs when something happens inside the system that triggers the processing need

System Controls

This checks for safety procedures put in place to protect the system’s and data’s integrity.

Perfect Technology Assumption

The assumption that a system runs under perfect operating and technological conditions

Brief Use Case Descriptions

Usually one sentence description that provides a quick overview of a use case which is usually expanded to record more details when the developers are designing and implementing the use cases

Use Case Diagram

Unified Modeling Language (UML) model used to visually illustrate use cases and their relationship to users as it depicts the use cases and how they are organised.

Automation Boundary

This defines the border between the computerised part of the application and the people operating the application. It is represented by a rectangle surrounding the use case.

<<includes>> relationship (<<uses>> relationship)

A relationship between uses cases where one use case is stereotypically included within the other use case (function inside another function); one use case uses or includes another use case; called a subroutine

Operational Stakeholders

Those who regularly interact with a system in the course of their jobs or lives

Executive Stakeholders

Those who do not interact directly with the system, but who either use information produced by the system or have a significant financial or other interest in its operation and success

Open-ended questions

A discussion usually starts with these questions as they encourage discussions or explanation which enables a large number of requirements to be uncovered fairly quickly

Closed-ended questions

A discussion usually shifts gradually to these questions that elicit specific facts or confirm specific details of a business process

Problem Domain

The specific area of the user’s business that is included within the new system’s scope.

Brainstorming Technique

A technique that is used to identify problem domain classes where developers work with users to identify different types of things that they use in their work

Noun Technique

A technique used to identify things in the problem domain by finding and classifying the nouns in a dialog or description

Attributes

The descriptive pieces of information about things or objects

Identifier or Key

An attribute the value of which uniquely identifies an individual thing or object

Compound Attribute

An attribute that consists of multiple pieces of inofrmation but is best treated in the aggregate.

Association

A UML term that describes a naturally occuring relationship between specific things

Relationship

A database management term that describes a naturally occurring association between specific things

Cardinality

A measure of the number of links in a particular relationship between a thing (database data entity) and one or more other things (data base entities). This can be one-to-one or one-to-many

Multiplicity

In UML, a measure of the number of links in a particular association between a thing (object) and one or more other things (objects). This is established for each direction of the association

Multiplicity Constraints

The actual numeric count of the constraints on things (UML objects) allowed in an association

Binary Associations

Associations between exactly 2 distinct type of things

Unary Associations

An association between 2 instances of the same type of thing

Ternary Association

An association between exactly 3 distinct type of things

N-ary Association

An association between n distinct type of things

Class

A category or classification of a set of objects or things

Domain Classes

Classes that describes objects from the problem domain

Domain Model Class Diagram

A class diagram that only includes classes from the problem domain

Camelback or camelcase notation

When words are concatenated to form a single word and the first letter of each embedded word is capitalised

0..1

Zero or one (optional)

1

One and only one (mandatory)