BID SPECIFICATION FOR SELECTION OF SOFTWARE DEVELOPMENT … C 1 RFP... · rfp for selection of software development of legal aid sa page 1 bid specification for selection of software

RFP FOR SELECTION OF SOFTWARE DEVELOPMENT OF LEGAL AID SA Page 1

BID SPECIFICATION

FOR

SELECTION OF SOFTWARE DEVELOPMENT

OF

LEGAL AID SOUTH AFRICA

29 De Beer Street, Braamfontein

Johannesburg, 2017, South Africa

Private Bag X76, Braamfontein,

2017

Tel: +27 11 877 2000

Fax: +27 11 877 2222

www.legal-aid.co.za


Table of Contents

Abbreviations .................................................................................................................................. 5

Definitions ........................................................................................................................................ 6

1 INTRODUCTION .................................................................................. 7

2 PROJECT GOALS AND BENEFITS ................................................... 7

3 PROJECT SCOPE ............................................................................... 7

3.1 The Current System (As-IS) ..................................................................................................... 8

3.1.1 Organisational Structure ................................................................................................. 8

3.1.2 Wide Area Network Infrastructure ................................................................................. 9

3.1.3 nSystem Context Diagram (as-is) .................................................................................. 10

3.1.4 Key Service Areas (current) ........................................................................................... 12

3.1.5 Current system functions .............................................................................................. 12

3.2 Proposed system ................................................................................................................... 15

3.2.1 Context Diagram ........................................................................................................... 15

3.2.2 New/Additional service needs ...................................................................................... 16

3.2.3 Functional Requirements .............................................................................................. 17

3.3 Integration requirements...................................................................................................... 19

3.3.1 Business Intelligence (BI) .............................................................................................. 19

3.3.2 Human Resource Management System (SAP) .............................................................. 19

3.3.3 Financial System (Syspro) .............................................................................................. 20

3.3.4 Microsoft Exchange Diary ............................................................................................. 20

3.3.5 Integrated Justice System ............................................................................................. 20

3.4 Non-functional Requirements .............................................................................................. 20

3.4.1 Performance.................................................................................................................. 20

3.4.2 Proactive error alerts .................................................................................................... 21

3.4.3 Security ......................................................................................................................... 21

3.4.4 Audit Trail ...................................................................................................................... 21

3.4.5 Validation Checks .......................................................................................................... 21

3.4.6 Database Management System .................................................................................... 21

3.4.7 Recoverability................................................................................................................ 22

3.4.8 Maintainability .............................................................................................................. 22

3.4.9 Scalability ...................................................................................................................... 22

3.4.10 Browser compatibility ................................................................................................... 22

3.4.11 End-User Device Independent ...................................................................................... 22

3.5 Technical Requirement Specifications .................................................................................. 22


3.6 System Migration Requirements. ......................................................................................... 23

4 REQUIREMENTS FROM BIDDERS ...................................................23

5 PAYMENT TERMS AND SCHEDULE ................................................24

6 PROCESS TIMELINES OF THE RFP ................................................25

7 FUNCTIONAL EVALUATION CRITERIA ...........................................25

8 COSTING ............................................................................................26

9 GENERAL TERMS AND CONDITIONS .............................................27

9.1 Proposal Submission Form .................................................................................................... 27

9.2 Language of the Proposal ..................................................................................................... 27

9.3 Technical Proposal Content .................................................................................................. 27

9.3.1 Project experience ........................................................................................................ 27

9.3.2 Proposed methodology for software development ..................................................... 27

9.3.3 Key Personnel ................................................................................................................ 28

9.3.4 The Financial Proposal .................................................................................................. 28

9.3.5 Currencies of Proposals ................................................................................................ 28

9.3.6 Project Timelines ........................................................................................................... 28

9.4 Joint Venture, Consortium or Association ............................................................................ 28

9.5 Alternative Proposals ............................................................................................................ 29

9.6 Proposal Validity ................................................................................................................... 29

Annexure A: Costing ................................................................................................................... 30

Annexure B: Resources CVs ..................................................................................................... 34

Annexure C: Technical Proposal ............................................................................................. 37

Annexure D: Use Cases .............................................................................................................. 38

UC 1: Apply for Legal Aid online.............................................................................................. 40

UC 2: Capture LA 1 Form ........................................................................................................... 41

UC 3: Approve application for Legal Aid ............................................................................... 41

UC 4: Appeal for rejected application for Legal Aid ........................................................... 42

UC 5: Judicare Registration ...................................................................................................... 42

UC 7: Assign Judicare ................................................................................................................ 43

UC 8: Update MAR ....................................................................................................................... 44

UC 9: Print LA 2 Form ................................................................................................................. 45

UC 10: Monthly Report (Legal Manager) ................................................................................ 45

UC 11: Matter Finalisation ......................................................................................................... 46

UC 12: Bulk Transfer ................................................................................................................... 46

UC 13: Pro-bono Allocation ....................................................................................................... 47


UC 14: Pro-bono Closure ........................................................................................................... 47

UC 15: Linking of co-accused ................................................................................................... 48

UC 16: Judicare Payment Verification .................................................................................... 48

UC 17: Taxation ............................................................................................................................ 49

UC 18: Quality Self-Assessment .............................................................................................. 50

UC 19: Supervisor Rating .......................................................................................................... 51

UC 20: Allocate Matter – Internal (Proposed) ....................................................................... 52

UC 21: Cancellation of legal aid ............................................................................................... 53

UC 22: Maintenance of Judicare Practitioner – Vendor ..................................................... 53

UC 23: Maintenance of Judicare Practitioner – Decision Suspend ................................ 54

UC 23 : Maintenance of Judicare Practitioner – Suspend................................................. 55

UC 24: BAC Procurement .......................................................................................................... 56

UC 25: Asset Procurement Module ......................................................................................... 57

UC 25: Asset Procurement Module ......................................................................................... 57

UC 26: Validate vendor (creditors) tax status ...................................................................... 58

List of Figures

Figure 1: Organisational Structure .......................................................................................................... 9

Figure 2: Ad-Infinitum (AI) As-Is Context Diagram................................................................................ 10

Figure 3: Proposed System Context Diagram ...................................................................................... 16

List of Tables

TABLE 1: SERVICE DELIVERY POINTS ........................................................................................................ 9

TABLE 2: CURRENT SYSTEM SERVER’S CAPACITY ............................ ERROR! BOOKMARK NOT DEFINED.

TABLE 3: THE LIST OF LEGAL FUNCTIONS IN THE CURRENT SYSTEMS: ........................................... 13

TABLE 4: ACCOUNTS PROCESSING FUNCTIONS ...................................................................................... 14

TABLE 5: ROADMAP OF THE SOFTWARE IN THE CURRENT AI SYSTEM. ............................................ 22

TABLE 6: REQUIREMENTS FROM BIDDERS ................................................................................................ 23

TABLE 7: PAYMENT SCHEDULE ..................................................................................................................... 24

TABLE 8: RFP TIMELINES ................................................................................................................................. 25

TABLE 9: EVALUATION CRITERIA ................................................................................................................... 26


Abbreviations

Term Meaning

AI Ad-Infinitum

OEM Original Equipment Manufacturer

NO National Operations

ISSC Information Systems Steering Committee

BASM Business Application Software Manager

PPU Post Payment Unit

HCUM High Court Unit Manager

CA Candidate Attorney

PA Professional Assistant

SPA Supervisory Professional Assistant

JCE Justice Centre Executive

ROE Regional Office Executive

COTS Commercial-Off-The-Shelf

CAS Criminal Application System

ISCCJ Inter-Sectorial Committee for Child Justice

LA 1 Application for legal aid

LA 2 Instruction to legal practitioner

LA 9 Refusal to provide legal aid

IJS Integrated Justice System (IJS).

AD Active Directory


Definitions

Term Meaning

Accreditation A process whereby a legal practitioner who has applied to be put on the

Legal Aid SA’s Directory of Accredited legal practitioners has been

evaluated to comply to the accepted code of practise

Integrated

Justice System

(IJS).

The members of the Justice cluster are Home Affairs, National Prosecuting

Authority, Department Of Justice, South African Police Service, Social

Development, Correctional Services and Legal Aid SA. Integrated Justice

System (IJS) projects ensures that the participating departments systems

are integrated and opens the way for greater co-operation, speedier

access to data and reduce duplication of processes and information.

Judicare Provision of legal aid through instructing private legal practitioners to

represent individual legal aid clients


1 INTRODUCTION

Legal Aid South Africa is an independent statutory body established by the Legal Aid

Act (1969) as amended. The objective of Legal Aid South Africa is to render or make

available legal representation to indigent persons with the strategic approach outlined

in the Legal Aid SA Strategic Plan 2015-2020. The core business requirements are

informed by the Legal Aid Guide 2012 and further defined primary principles outlined

in the IT policies, IT Strategic Plan 2015-2020, and IT Architecture 2015.

This RFP seeks proposals from potential bidders for development and implementation

of a software application of the core delivery service of Legal Aid SA which will meet

the required functional and technical requirements intended for identified service

requirements. The proposed software application should be a new write.

2 PROJECT GOALS AND BENEFITS

The goal of this project is to bring about improved efficiencies of operations of Legal

AID SA through writing of a new software application of the core delivery service. The

new system is to incorporate current workflow practices, add newly identified services,

expand client and stakeholder services, as well as integrate to key ERP systems and

other key systems.

The project bring about effectiveness of business processes of Justice Centres,

Regional Offices and National office in the functional areas of legal operations, legal

development, as well as procurement and payment of Judicare practitioners. It

ensures integration of data between the core system and ERP systems and other key

systems; and foster for a holistic Management Information and Decision Support

System for practitioners, managers, Executives and the Board of Legal Aid SA. The

project is thus leverage through technology meant to strengthen legal aid service to

clients and stakeholders and defines service delivery channels which includes new

delivery channels e.g. remote client and Judicare updates and access.

3 PROJECT SCOPE

The Current System (As-IS): This section outlines the current (as-is) business processes that relate to the AI system.


Proposed system: The proposed system will either be developed using the technologies listed below:

Table 0: development technology breakdown

User Interface K2 Smartforms

Business Logic C#

Workflow Processes K2 BlackPearl

Backend data storage MS SQL 2012

Documents Management System SharePoint 2013

3.1 The Current System (As-IS)

This section describes the current system artefacts which among others must be taken

into consideration in developing the new system.

3.1.1 Organisational Structure

The Legal Aid SA organisational structure is in figure 1 below as at 30 October 2015.


Figure 1: Organisational Structure

3.1.2 Wide Area Network Infrastructure

The Legal Aid SA has 135 service delivery points as per Table 1 below. These points

are all connected directly to the head office computer centre where all the present

system computing is done via Wide Area Network (WAN) VPN/MPLS. All

communication to and from the Internet is via the head office.

Table 1: Service Delivery Points

REGION

Regional Office Justice Centres Satellite Office Region Total

EC 1 10 11 22

KZN 1 10 11 22

FS - NW 1 13 6 20

GP 1 10 4 15

WC - NC 1 12 15 28

LIM – MP 1 9 17 27

National 1

TOTAL 6 64 64 135

This infrastructure enables connectivity to more than 2895 users (legal and non-legal)

with a computer desktop complement of 2339 pc as at 30 October 2015


3.1.3 nSystem Context Diagram (as-is)

The System Context Diagram is used to display how system inter operates at a very

high level or how systems operate and interact logically. The present system context

diagram is presented in figure 2 below.

Figure 2: Ad-Infinitum (AI) as-is context diagram

With reference to figure 2 above, the servers’ capacities are further described in table 1

below.


Table 2: Current system server’s capacity

Environment

Type Description Operating System Memory

Hard

Drive

Virtual Machine Application Server

Microsoft Windows Server 2008

R2 (64-bit) 6 Gig 100Gig

Virtual Machine Data warehouse Server


(64-bit) 49 Gig 780Gig

Virtual Machine DHCP



Virtual Machine DNS Server



Virtual Machine DNS Server



Virtual Machine

Microsoft Exchange

Server


(64-bit) 49 Gig 2,1TB

Virtual Machine

Microsoft Exchange

Server


(64-bit) 49 Gig 2,1TB

Virtual Machine SAP


R2 (64-bit) 32 Gig 1,2TB

Virtual Machine

K2 BlackPearl

Server(primary)



Virtual Machine

K2 BlackPearl

Server(secondary)



Virtual Machine Domain Controller



Virtual Machine Domain Controller



Virtual Machine Core Database Server


R2 (64-bit) 64 Gig 4,32TB

Virtual Machine Core Database Server


R2 (64-bit) 64 Gig 3,73TB

Virtual Machine Database Server


R2 (64-bit) 64 Gig 12,47TB



R2 (64-bit) 64 Gig 3,18TB



(64-bit) 32 Gig 1,86TB




Virtual Machine

VMware Site Recovery

Manager



Virtual Machine SYSPRO Database Server



Virtual Machine VMware vCenter Server



Physical Machine Application Server




3.1.4 Key Service Areas (current)

The Objective of the project is to meet key functional requirements and standard level

of business processes in response to current and new /additional service needs. The

organizational requirements and service needs (existing and additional) as raised

formed a basis for identification of Functional Needs and System Requirements for the

new system. Key functional modules include:

a) Applications and Appeals for Request for Legal Aid, Matter Search and Matter

finalisation and outcomes and their subsidiary modules, all activities thereof lies

at Justice Centre levels and are used by internal practitioners and

administrators;

b) Cancellations of legal aid instructions (which include reallocation of instructions

between internal practitioners, Judicare practitioners, probono and Agency

Agreement), bulk transfer , legal quality reviews (self, supervisory and

management), Matter Activity Report and Petitions and their subsidiary

modules;

c) Accreditation processes, Provision of legal aid through Judicare, and Agency

agreement allocations and their subsidiary modules, all being business process

needs in sourcing the services of external practitioners;

d) Vendor creation and related processes, Judicare Practitioners accounting

processing functions including processes of Judicare as creditors and their

subsidiary modules; all administered by Justice Centres and national Office

Finance Department; The Vendor management process should be integrated

with the supplier database that Legal-Aid suppliers are registered on for the

creation of already registered suppliers on the database

3.1.5 Current system functions

The AI system has presently functions that are used by various systems

stakeholders.

a) The functions relating to legal processes are listed in table 3 below and further

described in Annexure D.


Table 3: The list of legal functions in the current systems:

Legal Functions Performed by

Request Legal Aid –Application

Apply for legal aid : Complete LA 1 Paralegal/Admin Officer

Link co-accused (if any) Paralegal/Admin Officer

Evaluate Legal Aid Application Admin Officer

Provide Legal Aid Admin Officer

Reject Legal Aid Application: Print LA 9 Admin Officer

Print Referral Letter Admin Officer

Request Legal Aid –Appeal

Index Appeal Letter Admin Officer

Evaluate Appeal Recommendation Justice Centre Executive (JCE)

Cancel Legal Aid Provide Process

Select Instruction to Cancel JCE

Reallocation of instruction JCE

Issue Cancellation Letter JCE

Update Court Details JCE

Matter Search All

Matter finalisation and outcomes Attorney(CAs, PAs, SPAs)

Bulk Transfer SPA/JCE

Perform MAR Attorney(CAs, PAs, SPAs)

Petitions

Matter finalisation and outcomes Admin Officer, SPAs

Internal Practitioner Maintenance Admin Manager

Service Unit Maintenance JCE,HCUM,SPA

Pro bono Module

Pro bono Allocation JCE,HCUM,SPA

Pro bono Closure Attorney(CAs, PAs, SPAs)

Quality

Self-review(during finalisation process) Attorney(CA,PA,SPA)

Supervisory review SPA/ JCE

JC Management Review SPA/ JCE

ROE Review ROE

Legal Quality Assurance Unit Review Internal Audit

b) The function relating to accounts processing are listed in table 4 below and

further described in Annexure D.


Table 4: Accounts Processing Functions

Accounts Functions Performed by

Accreditation Process

Capture Practitioner Details Admin Officer

Accreditation of Practitioners JCE

Determine Impact JCE

Suspension of Practitioner: Temporary/Permanent Regional Operations Executive/Data Unit Manager

Agency Agreement Allocation JCE, HCUM, SPA

Judicare Process

Prepare/verify Judicare account checklist Admin Officer

Judicare Justification JCE

Maintaining a Judicare practitioner record. JCE

Judicare Authorisation ROE

Allocation of Instruction: Practitioner BEE Ranking High Court Unit Manager(HCUM), JCE,SPA

Offer Option Feedback: Send/Receive SMS Judicare Practitioner

Print LA 2 Admin Officer

Judicare Verification PA,SPA,JCE

Agency Agreement Allocation JCE, HCUM, SPA

Payment Processing Unit (PPU)

Verify Payment History PPU

Tax Account PPU

Post Payment Verification PPU

Create Commitments PPU

Purchase Order Creation Admin Officer

Finance functions (Syspro Interface)

Bid Adjudication Committee Procurement Admin Officer

Asset Procurement Admin Officer

Tax Clearance Certificate Validity Admin Officer

Authorise Requisition Admin Officer

Cancel Requisition Admin Officer

Create Purchase Order Admin Officer

Create Vendor Admin Officer

Modify Vendor Admin Officer

Authorize Vendor Admin Officer

Reject Vendor - Notification Admin Officer

Capture BEE Info Admin Officer

Update BEE Info Admin Officer

3.1.6 AS-IS Document

Bidders to take note that AS-IS Document would also serve as a base of validating AS-

IS system. Bidders are encouraged to attend a compulsory briefing where a

demonstration of the current system will be done by Legal Aid SA.


3.2 Proposed system

The proposed system must include all functionalities described as current system (As-

Is) in section 4 and new required functionalities described in this section and further

described in Annexure D.

3.2.1 Context Diagram

The System Context Diagram is used to display how system inter operates at a very

high level or how systems operate and interact logically. The proposed system context

diagram is presented in figure 3 below.


Figure 3: Proposed system context diagram

External

Websites

Financial

System

(SYSPRO)

Legal Aid System

Internal Users

HR System

(SAP)

Authenticating

System (Active

Directory)

SMS ServiceWork Flow

(K2 BlackPearl)

Electronic

Document Storage /

Knowledge

Management

System

MS-

Exchange

Diary

Module

Document

Scanning System

(Descriptiff)

Civil Module

(HotDocs)

Supplier

Registration

System

3.2.2 New/Additional service needs

New functional modules identified will include,

a) external websites for clients, Judicare, agencies and co-operations to cater

for external users;

b) the Civil Merit assessment modules and their subsidiary modules;

c) Purchase Order modules for processing of Judicare accounts; and

d) Civil enhancements.

e) SAP/ AD Synchronization

f) Walk-in Client Registration


Detailed functional requirements for each of the identified service areas (existing and

new) are defined hereunder.

3.2.3 Functional Requirements

The current functions of the AI system need to be included in the proposed system.

Additional functional requirements will thus respond to new services identified under

3.2.2. Above.

a) External Judicare Portal

External Judicare portal should be developed and hosted on internet to facilitate easy

access for our external accredited practitioners to interact with the electronic Legal Aid

administration system. The portal should allow Judicare practitioners, Agency

Agreements and Co-ops to perform the following functions amongst others:

Sign in and out

Reset password with forgotten password reminder

change their contact details

view instructions allocated to them

accept/decline instructions allocated to them

view/print LA1 and LA2

submit their account online

administrator to activate/deactivate practitioner’s access to the portal

b) The Civil Merit assessment modules

The Merit Report is primarily for civil matters. When a client applies for legal

assistance for civil matters, the completed application is granted and allocated to

a practitioner. The practitioner then assesses the case by contacting the client and

evaluating the merit of the case, by assessing the feasibility of proceeding with the

case. Based on the outcomes of the assessment a merit report will be generated

indicating if the case has merit or not. If the case is found not to have merit, it is


then declined. Conversely, if the case has merit the Practitioner may proceed with

the case

c) Purchase Order modules

I. Cancellation of purchase orders

When a purchase order is cancelled for Judicare accounts, the system

needs to ensure the requisition is also cancelled on the financial system

(Syspro). In certain cases, where an account is sent back to the Justice

Centre by PPU, the system must ensure the previous purchase order is

cancelled.

II. Commitments

When a matter is being paid, the system would need to confirm that

corresponding value of the initial commitment done in the financial system

is also reduced. The system will generate alerts for any commitment that

are not reducing on the financial system.

III. Requisitions

At creation of a requisition, the system should allow for users to capture the

details of the quotes received.

IV. Taxation

Purchase orders should not be in Payment Processing Unit beyond the

expected time limits. The workflow for this module needs to ensure strict

time limits are enforced from the time a purchase order is initiated at the

Justice Centre to the payment phase.

d) Civil enhancements

I. Multiple Applicants

Civil Matters with more than one applicant, the system should allow for

multiple applicants to be included in one matter. An example of this would

be an estate matter that has more than one child.


II. Apply for Legal Aid Function Enhancements

The function must include Administration of Estates, Curatorship (litigation

or monetary related), Alternative Dispute Resolution (mediation), Hague

Convention Cases, Mental Health Care Act Users and Conveyancing.

e) SAP/ AD Synchronization

When SAP HR system is updated, the changes should reflect on the Active

Directory (AD), in real time or within the specified period.

f) Walk-in Client – clients may require legal advice, but not legal representation.

Currently information about these clients is kept in a stand-alone system. The

proposed system should incorporate this functionality, such that if a client

qualifies for legal representation, they can be promoted to Request Legal Aid

(LA1).

3.3 Integration requirements

The new system need to integrate seamlessly with the existing systems at Legal Aid SA

and its external partners.

3.3.1 Business Intelligence (BI)

Legal Aid SA has an operational Business Intelligence solution (inclusive of legal,

finance and HR). The proposed system (service provider) should provide Business

Intelligence solution for BI Legal environment and must work with the BI Specialist to

ensure that the current ETLs are updated to reference the correct fields in the new

database. Also Service Provider should provide the detailed database dictionary of

their proposed solution for assisting in data mapping, data migration and enhancing

up-to-date information from the core System, SYSPRO and SAP.

3.3.2 Human Resource Management System (SAP)

SAP as a system need to be integrated to the core system of legal Aid SA in order to

have one entry / input for personnel data such as recruitment, training and staff

attendance/Leave information.


3.3.3 Financial System (Syspro)

Improve integration with Syspro to cater for two way data sharing in order to eliminate

data duplication.

3.3.4 Microsoft Exchange Diary

The system must update practitioners and his/her manager diary for matters assigned

to the practitioner.

3.3.5 Integrated Justice System

Integration with IJS applications that contribute to the information needs of the

organisation and the justice cluster. The data received from IJS should be used to

populate the LA1 and flag the used records from the IJS data.

3.3.6 HotDocs (Civil Module)

Integrate the system with the HotDocs system to cater for two way data sharing in

order to reduce time generating customized legal documents.

3.3.7 Tools and Equipment Register/Assets

The system should have a capability to identify tools and equipment from Asset based

the correct combination of amount and GL Code during procurement process, and

populate the tools and equipment register under the value of R5000.

3.3.8 BAC

When BAC contracts are awarded, the system should have the capability to ring-fence

total budgeted amount such that it can only be used for that project, and furthermore,

allow users to divide the budget according to the contract duration.

3.4 Non-functional Requirements

The overall quality and attributes of the system are defined by the non-functional

requirements. The non-functional requirements include performance, security, external,

database software, interface as well as input and output.

3.4.1 Performance

It is important to ensure the system can process a required number of transactions

within a specified time limit and handle a high number of concurrent user sessions. The


system needs to be able to process any type of input it receives. If it receives

unexpected input, it should be able to respond to input errors in a user-friendly manner,

where errors are handled in gracefully and descriptive enough for users.

3.4.2 Proactive error alerts

The system should have a way to monitor errors as they occur on the interfaces that

communicate with other modules. The errors should then be sent to the person that

initiated the transaction as well as to the IT Support team to allow for immediate

attention.

3.4.3 Security

The system needs to ensure only authorised users may work on the system. The system

access should be done through Active Directory. The definition of roles is done through

Active Directory (AD). It is very crucial that AD is updated regularly to reflect the current

employees as referenced on the SAP HR system. This will ensure the system is

protected from malicious intrusion.

3.4.4 Audit Trail

The application software should provide proper audit trail for any change made in the

data. The software should be capable to store date and other identities of the applicant

entering online data. The system should maintain proper logs of any changes made in

the data.

3.4.5 Validation Checks

The application software should incorporate proper validation checks so that garbage

data is not stored in the database. The validation checks should be able to minimize

data entry mistakes and business rules violations.

3.4.6 Database Management System

Any maintenance performed on the database system needs to be performed outside

the system’s operational hours to reduce system unavailability. Planned maintenance

is communicated with business stakeholder through a maintenance calendar shared

with business. However, emergency maintenance is not included in the maintenance

calendar; this is also communicated to the stakeholders warning them of the possible

unavailability of the system


3.4.7 Recoverability

Since AI is a crucial system for the organisation, disruptions to systems relating to

availability and functionality should be minimised. Should the system go down, the IS

department should have a recovery process. The recovery process should stipulate the

recovery timescales; if these timescales are exceeded then a system hosted at an

alternative site needs to be initiated. Core to recoverability is the availability of the latest

backups. The current recoverability of the AI system needs to be reviewed.

3.4.8 Maintainability

The system needs to conform to good design principles. The principles include amongst

others; architectural, design and coding standards. The current system is not adequately

designed. The design and coding of the systems functions is based on old procedural

style of design. Coding does not adhere to any coding convention as a result making

maintenance a time-consuming exercise.

3.4.9 Scalability

The system must be scalable to accommodate future business needs and changing

business environment.

3.4.10 Browser compatibility

The application user interface should provide full system functionality across multiple

internet browsers among others Internet Explorer, Firefox, Safari (iPad’s Tablet) and

Chrome (Android’s Tablet).

3.4.11 End-User Device Independent

The application user interface should be device Independent, that is it must able to

interface with different operating system used in desktops, laptops and tablets.

3.5 Technical Requirement Specifications

The proposed solution should be in line with the technologies detailed in the Legal Aid

SA’s IT strategy. In developing the new system, the existing technology and skill base

of Legal Aid SA should be taken into cognisance. The present system software

technology environment is presented in table 5 below:

Table 5: Roadmap of the software in the current AI system.


Component Current

Proposed

Framework ASP.Net(2.0) K2 Smart forms

Integrated Development

Environment (IDE)

Visual Studio 2010 Visual Studio 2013/2015

Development Language C#.Net C# 4.5 or higher

Documents Repository SharePoint 2007 SharePoint 2013 or higher

Workflow K2 BlackPearl 4.5 Latest version of K2 BlackPearl

ERP (Finance) SYSPRO 6.1 SP2 SYSPPRO 7.0 or higher

ERP (HR) SAP HCM 6.0 SAP HCM 6.0 or higher

Scanning Tool Descriptiff v2.4 SharePoint Compatible Scanning Tool

Business Intelligence Microsoft BI Tools Microsoft BI Tools

Integration tool Dcom WCF/Web Services

Database MS-SQL 2008 MS-SQL 2012 or higher

Operating System (Server) Windows 2008 Windows 2012 or higher

Operating System (Desk Top) Windows 7 Windows 7, 8 ,10

Web Browser Internet Explorer 9 Browser Independent

End user device( Operating

System)

Workstations running Microsoft operating system

Device Independent (Work station, Laptop,

Tablet and Smart Phone)

User Authentication MS- Active Directory (AD) MS- Active Directory (AD)

E-mail MS-Exchange 2010 MS-Exchange 2013 or higher

Bids should respond with parameters of the software application in table 5 above or

motivate the benefits of their proposed deviation.

3.6 System Migration Requirements.

The migration to the new system has to be a phased approach. Bids must supply a

migration plan to the new system that includes among others data migration, change

management and user training.

4 REQUIREMENTS FROM BIDDERS

The primary Supply Chain Management (SCM) documents providing bidders

requirements are in terms of the PPPFA and the Standard Bid Documents (SBD).

Bidders are in addition also required to cover requirements in table 6 below:

Table 6: Requirements from bidders

STAGE 1 (Pre-requisite for consideration of bid)

1.1 Attend compulsory briefing session on the RFP on 25 November 2015 at 10:00 am


1.2 Company profile: Company certification to ISO 9001:2008, EOM certification relevant to the bid, directors, staff

component- focussed skills & capacity and location

1.3 Proposed solution including Change Management Plan and structured migration strategy. Change Management needs

to be based on the agreed resource rates and bidders to outline their approach in their proposals. User training needs

to be stated.

1.4 Provide a project plan at the time of bidding. Bidders need to ensure that the activities listed are all completed within

the proposed project timelines.

1,5 Costing using format in Annexure A in a separate sealed envelope marked with bidder’s particulars and the bid

reference details.

STAGE 2 (After bid award)

2.1 Signing of Vendor Contract and Service level Agreement

2.2 Provide a study report that will be based on the initial analysis done on the system (a base document will be provided

for validation). The study report must include a broad outline of the systems architecture, providing further details on

the software and the hardware requirements. This document should include the software design methodology to be

adopted.

2.3 Provide a detailed Functional Requirements Specification, software test plan and a software quality assurance plan.

The conditions of these plans will be binding to the bidder, and any failure to achieve the items in this section will result

in negative consequences for the bidder.

2.4 A detailed description indicating how the bidder will facilitate the post implementation phase.

2.5 Develop and document the required software solution as per the Functional Requirements Specification

2.6 Testing should consist of functional, integration and regression.

2.7 User acceptance and sign off to be done and documented after completion of each module as per test plan.

2.8 Bidder to ensure the replication service is set up between the Production and the Pre-Prod environment.

2.9 A structured migration process followed from the Ad-Infinitum System to the new system to be confirmed. The software

developer to state their structured migration strategy at the time of bidding.

2.10 Deploy the solution to the Production environment.

STAGE 3 (Post implementation)

3.1 New solution run for next six months (preferably parallel run)

3.2 Incorporating amendments and enhancements were required.

3.3 Affirmation/sign off /validation of new solution by users. Legal Aid SA reserve right to have the solution certified that it

is fit for purpose by its Internal Audit Department and/or by third party.

3.4 Ad-Infinitum system to be decommissioned.

3.5 Bidder must provide a warranty that the deliverables provided, as detailed in the functional specification, will operate

and function as designed for a period of no less than one (1) year from the date of system acceptance. The warranty

shall require the bidder to correct, at its own expense, the legal aid application so that it functions according to the

organisation’s requirements.

3.6 Final application software along with source code and licences of any other third party software used. The Intellectual

Property obtained in the development of the system will vest with Legal Aid SA.

5 PAYMENT TERMS AND SCHEDULE

The payment will be based on stages completed as described in Table 6 above

and Table 7 below. Request for Payment Terms be submitted to the Legal Aid

Project Manager with supporting documents with proof delivery for his/her

approval before payments can be processed.

Table 7: Payment schedule


Stage Outputs Percentage Condition for Payment

1 Returned bid documents 0% 30 days after signoff and invoice received. 2.1 to 2.3 Detailed

1. Functional Requirements Specification

2. software test plan 3. Software quality assurance plan. 4. Post implementation plan.

10%

2.4 to 2.6 1. User acceptance and sign off divided into 4 work streams.

15% per work stream completed.

2.7 to 2.9 1. Deployed solution in Production environment.

20%

3 1. Source code and software licencing documents.

2. Post implementation review document.

10%

6 PROCESS TIMELINES OF THE RFP

Anticipated process timelines are listed Table 8 below for the purposes of clarifying

the RFP process to be followed. Legal Aid SA reserves the right to make changes to

dates given hereunder.

Table 8: RFP Timelines

No Activity Date

1 Place Advertisement at Government Printers for placement on Friday 13th

Nov 2015 Tender Bulletin.

06th November 2015

2 Issue the RFP 16 November 2015

3 A mandatory briefing session to be held at Legal Aid House, 29 De Beer

Street, Braamfontein, Johannesburg and the session is for clarity of

process and not technical specification requirements. The questions are to

be deposited into external portal on our website (Legal Aid SA will provide

format)

N.B. Only bidders that have attended the briefing session will be

eligible to respond to the RFP

Wednesday 25th November 2015

4 Questions raised by bidders by (electronic communication with bidders) 01st December 2015

5 The RFP closing date 11h00, 12th January 2016

7 FUNCTIONAL EVALUATION CRITERIA

The criterion for evaluation of proposals is in Table 9 below. Bidders, who score less

than 80% of the 100 points for functionality will be disqualified, and will not be evaluated

further.

The bids that would have achieved 80% or more from the Functionality Evaluation will

be further evaluated on the 90/10 points system where 90 points are for Pricing, and 10

points are for preferential procurement requirements.


Preferential points will be awarded in terms of the B-BBEE Status Level of contribution

which must be substantiated as follows (please refer to Form SBD6.1 for more details):-

Bidders must submit a valid B-BBBEE status level verification certificate, which must be

issued by a Registered Auditor approved by IRBA or a Verification Agency accredited

by SANAS.

Table 9: Evaluation Criteria

1 Expertise of the Firm 15%

ISO 9001:2008 and OEM certification. Organisational capability/resources, and experience of organisation, the list of projects/contracts (both completed and on-going, both domestic and international) which are related or similar in nature to the requirements of the RFP.

2 Methodology: 15 %

Its appropriateness to the condition and timeliness of the Implementation Plan. The proposed methodology should clearly delineate what the Bidder expects the solution to do, thus making it a basis for defining project scope. The bidder should provide a detailed description of the essential performance characteristics proposed and demonstrating how the proposed methodology meets or exceeds the specifications

3 Technical Proposal 60%

Bidders proposal as per this RPF in meeting the following:

1. As-Is requirements; 2. New functional requirements; 3. Integration requirements; 4. Non-functional requirements; 5. Technical requirement specification; and 6. System migration requirements.

4 Management Structure and Qualification of Key Personnel 10%

The Bidder must provide details regarding management structure of the organisation, qualification of resources, detailed CV of a team leader with a precise description of educational background, professional experience including previously implemented projects (please list all the projects - at least 2 projects are required). CV(s ) of QA (Quality Assurance) specialist(s) with ISTQB (International Testing Software Qualification Board) certificate (at least 1 specialist is required)

TOTAL 100%

8 COSTING

All bids received should reflect costing on two levels; the high-level costing and the

detailed cost using the forms in Annexure A. The costing schedule must be presented

in separate sealed enveloped marked with bidder’s particulars and the bid reference

details.


9 GENERAL TERMS AND CONDITIONS

Bidders must meet the following general terms and conditions:

9.1 Proposal Submission Form

Bidders shall submit their proposals using the “Proposal Submission Form” furnished

in Annexure C of the RFP.

9.2 Site visit

The bidder must arrange for a site visit by Legal Aid SA to at least 3 client reference where similar technology was deployed. Site visit dates will be communicated with prospective bidders.

9.3 Language of the Proposal

The Proposal, as well as all related correspondence exchanged by the bidders and

Legal Aid SA shall be written in the English language.

9.4 Technical Proposal Content

The Bidder shall structure the Technical Proposal to meet the evaluation criteria, as follows:

9.4.1 Project experience

Descriptions of software development projects in .Net for K2 Smartforms, K2

BlackPearl workflow, C# systems previously implemented by company (at least 3

projects and 3 client references)

9.4.2 Proposed methodology for software development

The proposed methodology should clearly delineate what the Bidder expects the

solution to do, thus making it a basis for defining project scope.

The bidder should provide a detailed description of the essential performance

characteristics proposed and demonstrating how the proposed methodology meets or

exceeds the specifications.


9.4.3 Key Personnel

The Bidders must provide: names and qualifications of the key personnel that will

perform the services, namely: team leader, developers and at least one QA (Quality

Assurance) specialist with ISTQB (International Testing Software Qualification Board)

certificate using the form in Annexure B. Detailed CV of a team leader with a precise

description of educational background, professional experience including previously

implemented projects (please list all the projects - at least 2 projects are required).

The bidders will only be allowed to substitute a resource with an equivalent skilled

resource or better at the equal bid price and with the approval of Legal Aid SA project

manager.

9.4.4 The Financial Proposal

The Financial Proposal shall be prepared using ONLY the attached forms in Annexure

A. No other pricing approach is accepted.

9.4.5 Currencies of Proposals

All prices shall be quoted in the South African Rand currency.

9.4.6 Project Timelines

Project milestones and the implementation timetable must be well-defined.

9.5 Joint Venture, Consortium or Association

If the Proposer is a joint venture, consortium, or association, all of the parties shall be

jointly and severally liable to Legal Aid SA for the fulfilment of the provisions of the

Contract and shall designate one party to act as a leader with authority to legally bind

the joint venture, consortium, or association.

The leader or lead entity, composition or the constitution of the joint venture,

consortium, or association shall not be altered without the prior consent of Legal Aid

SA. The description of the organisation of the joint venture/consortium/association

must be clearly defined in the course of establishing the eligibility of the Proposer, by

defining the expected role of each of its component/member firm in the course of

performing the services defined in the RFP.


9.6 Alternative Proposals

The proposal to be accepted is only about the development of the new system based

on the technology outlined on Table 0, No alternative technology shall be considered.

9.7 Proposal Validity

In exceptional circumstances, prior to the expiration of the proposal validity period,

Legal Aid SA may request bidders to extend the period of validity of their Proposals.

The request and the responses shall be made in writing, and shall be considered

integral to the Proposal.

10 BID CONDITIONS

10.1 Bidders may be requested to attend a meeting where they will be given the opportunity to present their proposal to the bid evaluation committee.

10.2 Bids must be submitted in line with detailed specifications and requirements. Failure to bid accordingly shall invalidate the bid.

10.3 Legal Aid SA reserves the right to award the bid to one or more service providers.

10.4 Legal Aid SA reserves the right to award the bid in whole or only partially.

10.5 The General Conditions of Contract as stipulated by National Treasury will be applicable.

Note: Legal Aid SA reserves the right not to award.


Annexure A: Costing

High-level costing

For milestones listed in item 5 bidders should indicate the cost associated with

providing the deliverable listed using Form 1 below.

Form 1: High level costing

Task Description Duration Cost

2.1 to 2.3

Solution definition

Solution design

Technical document

Stage 2.4 to 2.6

Module development,

integration and deployment

Testing (Unit Testing and

UAT)

Conduct Developer and

Administrator training

Change management

End-User training

Stage 2.7 to 2.9

Scheduled replication to Pre-Prod

platform

Data migration

Solution Deployment


Stage 3

Document post-implementation

reviews

Total

VAT

Total Cost (Inc. VAT)

Software Cost

Quantity Cost

Scanning Software

Development Tool

Integration

Data Migration Tool

Total

VAT



Detailed costing

Bidder should specify the technical skills that will be used for the project. The proposals

should reflect the costing Form 2 below:

Form 2: Detailed costing

Task Description Resource Quantity Duration Cost

Stage 2.1 to 2.3

Solution definition Lead

Architecture

Solution

Architecture

Business

Analyst

Solution design Lead

Architecture

Solution

Architecture

Technical

document

Technical

Writer

Business

Analyst


Stage 2.4 to 2.6

Module

development,

integration and

deployment

Testing (Unit

Testing and UAT)

Conduct

Developer and

Administrator

training

Change

management

End-User training

Stage 2.7 to 2.9

Scheduled replication

to Pre-Prod platform

Data migration

Solution Deployment

Stage 3

Document post-

implementation

reviews

Business

Analyst


Total

VAT


.

Annexure B: Resources CVs

Bidders must submit CVs for each resource that will be working on the project and the

summary for each resource using the format in Form 3 below. The bidders will only be

allowed to substitute a resource with an equivalent skilled resource or better at the

equal bid price and with the approval of Legal Aid SA project manager.

Form 3: Resource skills

Name

Resource Title

(e.g. Senior

Developer)

Cost Per Hour

Skill Skill Level

(Entry/Interme

diate/advanced

/expert)

Years’

Experience

Last Date

Used

Programming Languages

C#

C ++

VB.Net

ASP.Net

Java applet & servlet


JavaScript & Ajax

Visual Studio.Net

ASP/VBScript

(specify)

Other (specify)

Platforms/architecture

.Net Framework 2.0,

3.5, 4.5

J2EE

Google Android

.Net Remoting

EJB/RMI

Other (specify)

System Integration Technologies

XML

Web Services

EDI

CORBA

K2 Connect

SharePoint

Databases

SQL Server 2012 or

higher (specify)

Operating Systems

Windows Server

2012 or higher


(specify)

Workflow

SharePoint

K2 BlackPearl 4.5 or

higher

K2 Smartforms

Other Business Software

SYSPRO

SAP

Active Directory

HotDocs


Annexure C: Technical Proposal

The Bidder shall structure the Technical Proposal to meet the evaluation criteria, as follows:

Form 4: Proposal Submission Form

1. Company Profile –Nature of business, field of service, accreditation, quantity of personnel and their qualifications.

The Bidders must provide: names and qualifications of the key personnel that will perform the services, namely: team leader, developers and at least one QA (Quality Assurance) specialist with ISTQB (International Testing Software Qualification Board) certificate; b).

Detailed CV of a team leader with a precise description of educational background, professional experience including previously implemented projects (please list all the projects - at least 2 projects are required);

CV(s ) of QA (Quality Assurance) specialist(s) with ISTQB (International Testing Software Qualification Board) certificate (at least 1 specialist is required)

2. Expertise of Firm/Organization

The Bidder must provide details regarding management structure of the organisation, organisational capability/resources, and experience of organization/firm, the list of projects/contracts (both completed and on-going, both domestic and international) which are related or similar in nature to the requirements of the RFP.

3. Expertise of Firm/Organization

The Bidder must provide details regarding management structure of the organisation, organizational capability/resources, and experience of organisation/firm, the list of projects/contracts (both completed and on-going, both domestic and international) which are related or similar in nature to the requirements of the RFP.

4. Descriptions of software development projects using K2 Smartforms within .NET framework previously implemented by company (at least 3 projects and 3 client references)

5. Proposed methodology for software development

The proposed methodology should clearly delineate what the Bidder expects the solution to do, thus making it a basis for defining project scope. The bidder should provide a detailed description of the essential performance characteristics proposed and demonstrating how the proposed methodology meets or exceeds the specifications in this RFP document

6. Bidders proposal as per this RPF in meeting the following:

1. As-Is requirements; 2. New functional requirements; 3. Integration requirements; 4. Non-functional requirements; 5. Technical requirement specification; and 6. System migration requirements.

7. Project Timelines

Project milestones and the implementation timetable


Annexure D: Use Cases

Use case is a list of steps, typically defining interactions between a role (known in UML

as an "actor") and a system, to achieve a goal. The use case specification also

provides the details of the functionality that the system will support and describes how

the actors will interact with the system. The actor can be a human or an external

system.

Please note that the following use cases are for informational purposes and can differ

from the final one that should be approved in system design.


USE CASE NAME Use Case Name/Title

UC 1 Apply for legal aid online

UC 2 Capture LA 1 Form

UC 3 Approve application for Legal Aid

UC 4 Appeal for Rejected Application for Legal Aid

UC 5 Judicare Accreditation

UC 6 Judicare Verification

UC 7 Assign a Judicare

UC 8 Update MAR

UC 9 Print LA2 Form

UC 10 Monthly Report (Legal Manager)

UC 11 Matter Finalisation

UC 12 Bulk Transfer

UC 13 Pro-bono Allocation

UC 14 Pro-bono Closure

UC 15 Linking of Co-accused

UC 16 Judicare Payment Verification

UC 17 Taxation

UC 18 Quality Self-Assessment

UC 19 Supervisor Review

UC 20 Allocate Matter – Internal

UC 21 Cancellation of legal aid

UC 22 Maintenance of Judicare Practitioner – Vendor

UC 23 Maintenance of Judicare Practitioner – Suspend

UC 24 BAC Procurement

UC 25 Asset Procurement Module

UC 26 Validate vendor (creditors) tax status


UC 1: Apply for Legal Aid online

Use Case Name UC- 1 Apply for legal aid online

Description A process whereby a client applies for legal aid for

either a criminal or a civil matter

Actors Paralegal

Preconditions Client needs legal aid.

Main Success Scenario 1. Paralegal consults with client and determines if client qualifies for legal aid by assessing through the means test using the system.

2. Paralegal evaluates the input received from the website and SMS.

3. Details of online form submitted will be confirmed with the client.

Post condition The LA 1 form has been completed in full indicating the

type of matter to be covered (criminal or civil).


UC 2: Capture LA 1 Form

UC 3: Approve application for Legal Aid

USE CASE NAME UC 2: Capture LA 1 Form

DESCRIPTION Process Application captured on the system and processed

ACTOR Admin Officer

PRE-CONDITION Client needs legal aid.

BASIC FLOW

1. CA/PA/SPA submit LA1 forms to admin for capturing 2. Admin officer completes the LA1 form on behalf of the client, based on client input. 3. Generate a reference number for matter 4. Client is requested to confirm the details captured, and if satisfied sign the LA1 form.

POST CONDITION Reference number

USE CASE NAME UC 3: Approve application for Legal Aid

DESCRIPTION Application has been rejection and print LA 9 form

ACTOR Admin Officer

PRE-CONDITION Applications form for Legal Aid has been captured

BASIC WORK FLOW

1. The system apply means rest 2. System makes a recommendation 3. The system recommendation is evaluated. 4. If rejected the reasons for refusal are selected

POST CONDITION 1. Application is approved; or 2. Application is rejected and the LA 9 form is printed

and given to the client


UC 4: Appeal for rejected application for Legal Aid

UC 5: Judicare Registration

USE CASE NAME UC 4: Appeal for rejected application for Legal Aid

DESCRIPTION Appeal for rejected application for Legal Aid

ACTOR JCE and ROE

PRE-CONDITION 1. Appeal for application rejection 2. LA 9 form available

BASIC WORK FLOW

1. Applicant states the reason for reconsideration of application 2. Justice Centre scans the appeal letter to ROE 3. ROE considers application rejection and motivation for reconsideration

POST CONDITION 1. The matter is sent back to evaluation to be assigned to a practitioner; or

2. Application rejection is upheld.

USE CASE NAME UC 5: Judicare Accreditation

DESCRIPTION Approval process for external legal practitioner (Judicare)

ACTOR JCE, Data Unit Manager

PRE-CONDITION Advocates 1. Admission Certificate 2. Good law society of SA stand 3. External mediator is registered with a recognised

professional body/bar 4. Right of appearance in court 5. Valid tax clearance certificate supplied 6. ID copy

Attorneys 1. Fidelity fund certificate 2. Letter of good standard 3. Tax clearance 4. ID Copy 5. Right of appearance in court

BASIC FLOW

1. Admin officer captures personal details 2. Admin officer captures firm details 3. Admin officer captures Tax details 4. JCE approves the documentation 5. ROE approves the Judicare 6. Documents sent to finance with vendor forms to create vendor number 7. Vendor reference generated by SYSPRO 8. Admin officer captures Judicare information on system 9. Data Unit Manger do BEE rating for the Judicare practitioner

POST CONDITION Judicare vendor accredited by Legal Aid to represent their clients


UC 6: Judicare Verification

UC 7: Assign Judicare

USE CASE NAME UC 6: Judicare Verification

DESCRIPTION A process whereby the principals (PA, SPA), Admin Manager or JCE validates the Judicare practitioner has received the LA2 and has signed it.

ACTORS PA, SPA, JCE, Admin Manager

PRE-CONDITIONS LA 2 has been signed by the Judicare practitioner.

BASIC FLOW

1. Admin Officer sends the practitioner an SMS providing the matter reference number, matter type and court details.

2. SPA, PA, JCE or Admin Manager confirms to have received a signed LA2 from Judicare practitioner.

POST CONDITION Verified LA2.

Exception/Alternate

course

Data Unit Manager has override functionality to execute the

Judicare verification module on behalf of Justice Centre.

USE CASE NAME UC 7: Assign Judicare

DESCRIPTION Case assigned to an external representative

ACTOR SPA/Manager/Principal attorney

PRE-CONDITION Judicare authorisation granted

BASIC FLOW

1. Matter is evaluated 2. Decision to allocate to Judicare is made 3. Reason for allocation selected 4. Systems ranks using district, level of experience, language, SARS tax standing

and BEE rating 5. Send instruction via SMS 6. Response (accept/deny)

POST CONDITION Matter allocated to a Judicare practitioner

EXCEPTION/ALTERNATE

COURSE If no response is received within 48 hours, practitioners are in the Judicare practitioner list are rotate and a notification is sent to 4 other random practitioners.


UC 8: Update MAR

USE CASE NAME UC 8: Update MAR

Continuous update of matter progress until finalised

ACTOR CA/PA/SPA(allocated/replacement attorney)

PRE-CONDITION Matter assigned to CA/PA/SPA

WORK FLOW

1. Practitioner updates daily progress and time spent as per allocated instruction worked on.

2. Practitioner updates next court appearance date on instruction worked on central diary.

3. The system update practitioner diary on Microsoft Exchange.

POST CONDITION Updated practitioners MAR and calendar on Microsoft Exchange. (Practitioner and Manager)


UC 9: Print LA 2 Form

UC 10: Monthly Report (Legal Manager)

USE CASE NAME UC 9: Print LA 2 Form

DESCRIPTION Confirms case has been allocated

ACTOR Admin Officer, JCE

PRE-CONDITION Case accepted by practitioner

BASIC WORK FLOW

1. Signs 2 LA forms, 1 kept for audit 2. JCE & Judicare signs 3. Practitioner collects client files from Justice Centre

POST CONDITION Judicare represent client in court.

USE CASE NAME UC 10: Monthly Report (Legal Manager)

DESCRIPTION Practitioner supervision

ACTOR SPA

PRE-CONDITION All the necessary data have been captured

WORK FLOW

1. Awaiting trial Prisoner (ATP) – progress and outcome

Interaction with Presiding Officer (Judge or Magistrate)

Report on meetings with a stakeholder

Cash flow Management Meetings

Children awaiting trial

Court orders

Judicare reviews

Litigation against government departments

Independent prison visitors

Increase fees

Pending matters exceeding turnaround times

Legal training

High court roll

Appeal monitoring

Complaints register

CA Court readiness & pre-admission program

POST CONDITION Quality and progress reports


UC 11: Matter Finalisation

UC 12: Bulk Transfer

USE CASE NAME UC 11: Matter finalisation

DESCRIPTION Finalise and close instructions

ACTOR CA/PA/SPA

PRE-CONDITION A judgement must be passed by a court (guilty, not guilty, withdrawal).

BASIC WORK FLOW

1. Practitioner enters matter reference number. 2. Practitioner selects the option to record the matter outcomes. 3. Practitioner indicates if the outcome concerns a case with an individual or a

case that has co-accused. 4. If the matter is for an individual, the practitioner records the outcomes on the

system. 5. If the matter has co-accused, the practitioner needs to record the outcomes for

all the individuals linked to the matter. 6. Practitioner capture minor charges and outcome per applicant (where

applicable) 7. Complete self-assessment (where applicable). 8. Close instruction.

POST CONDITION Matter closed

USE CASE NAME UC 12: Bulk Transfer

DESCRIPTION Allows you to transfer processes/tasks in bulks

ACTOR PA/SPA

PRE-CONDITION Status of the matter or practitioner changes e.g. resignation, transfer, court rotation or the contract of the CA has expired

BASIC WORK FLOW

1. Transfer instruction to an active practitioner on condition it is the same JC and functional unit are the same, with previously allocated practitioner

2. Change the court number (where applicable)

POST CONDITION Successful transfer of matters.


UC 13: Pro-bono Allocation

UC 14: Pro-bono Closure

USE CASE NAME UC 13: Pro-bono Allocation

DESCRIPTION A process whereby the JCE can indicate to which entity type a case should be assigned to. This is an additional type (i.e. Pro-Bono)

PRIMARY ACTORS JCE

PRECONDITIONS Allocation can only be made for Request Legal Aid process, cancel instruction process and appeal against refusal process.

BASIC FLOW

1. The following should be captured: 2. Type of case (civil or criminal). 3. District that matches the district where the Pro-bono practitioner will work. 4. Pro-bono practitioner’s appearance rights and experience type (i.e. district,

regional or high court).

POST CONDITION Matter allocated to Pro-bono practitioners.

USE CASE NAME UC 14: Pro-bono Closure

DESCRIPTION Finalisation of a case allocated to a Pro-bono practitioner.

ACTOR Admin Officer, Admin Manager

PRE-CONDITIONS Matter issued on a pro-bono basis has been attended.

BASIC FLOW 1. Pro-bono practitioner will send a report containing the outcome of the case, finalisation date and hours spent on the case.

2. The report is scanned and indexed by the Admin Officer. 3. Admin Officer captures the hours worked and marks the

case as finalised.

POST CONDITION The matter is successfully closed.


UC 15: Linking of co-accused

UC 16: Judicare Payment Verification

USE CASE NAME UC 15: Linking of co-accused

DESCRIPTION An activity whereby an accused can be grouped with the primary accused in the same matter for civil and criminal cases.

PRIMARY ACTORS Admin Officer

PRE-CONDITIONS The initial allocated matter reference is required.

BASIC FLOW 1. Admin Officer opens a new matter. 2. Admin Officer captures the details of the accused. 3. If the case number and the seat of court are similar to any

active matter, the system will highlight it as a co-accused and the admin officer will have to indicate it as such.

POST CONDITION All co-accused have been successfully linked.

USE CASE NAME UC 16: Judicare payment verification

DESCRIPTION A process where payment is verified

ACTOR Admin Officer, AM, JCE (JC)

PRE-CONDITION LA2 & Invoice submitted

BASIC FLOW

1. Verify payment history 2. JC indicated whether the payment is additional/interim , corrective payment or final

payment 3. Create purchase order

POST CONDITION Judicare invoice ready for payment


UC 17: Taxation

USE CASE NAME UC 17: Taxation

DESCRIPTION Process where Judicare is taxed

ACTOR PPU

PRE-CONDITION Judicare verification done by JC

BASIC FLOW

1. Verify payment history 2. Verify SARS tax affairs standing 3. Tax Account ”time, date & line item” 4. Post payment verification 5. Prove/Deny Payment 6. Pass the payments to Syspro

POST CONDITION Payment verified, taxed and passed to finance system (Syspro)


UC 18: Quality Self-Assessment

USE CASE NAME UC 18: Quality Self-Assessment

DESCRIPTION Internal self-assessment by the practitioners

ACTOR CA/PA/SPA

PRE-CONDITION Matter completed

BASIC WORK FLOW

1. Capture case reference number 2. Time spent on cases by internal practitioners 3. Quality check list completed

POST CONDITION 1. Assessment report is populated 2. Quality score captured


UC 19: Supervisor Rating

USE CASE NAME UC 19: Supervisor Rating

DESCRIPTION Rating score on a practitioner by a supervisor

ACTOR Supervisor/Internal Auditors

PRE-CONDITION Practitioners have adhered to the SOPs

BASIC FLOW

1. SPA check the following:

1.1. The unit standard document has been complied with. 1.2. Quality of details contained in Matter Activity Reports. 1.3. Ensures clients have given consent for legal assistance by signing the LA 1 form.

2. The score that the IA gives and rounded from JCE & ROE is emailed to the practitioner and supervisor

3. If the practitioner doesn’t question the score within 2 weeks. The score is kept in records

POST CONDITION Practitioner has performance rating score


UC 20: Allocate Matter – Internal (Proposed)

USE CASE NAME UC 20: Allocate Matter – Internal (Proposed)

DESCRIPTION Matter allocated to an internal practitioner

ACTOR SPA/Manager/Principal Attorney

PRE-CONDITION 1. Applicant is granted Legal Aid. 2. Court room information

BASIC FLOW

1. Decision to allocate matter internally is made. 2. The system automatically allocates matter to the relevant practitioner using the

court room information practitioner case load.

POST CONDITION The matter is allocated to an internal practitioner.


UC 21: Cancellation of legal aid

Use Case Name UC 21: Cancellation of legal aid

Description A process whereby request for legal aid application is cancelled and reallocated to another practitioner

Actors PA,SPA,HCUM,JCE

Preconditions One of the following reasons: 1. Conflict of interest 2. Change of Courtroom 3. Practitioner abandons practice 4. Practitioner struck from the role 5. Practitioner change firm 6. Practitioner not available

BASIC FLOW

1. Select the reason for cancellation from the dropdown list , if the selected reason is “Change Court room”,

2. Then select the correct court room number. 3. Then print the “cancellation letter”

OR

1. Select the reason for cancellation from the dropdown list , if the selected reason is not “Change Court room”,

2. Regroup the applicants 3. Print the “cancellation letter”

Post condition Matter cancelled and evaluated pending allocation.

UC 22: Maintenance of Judicare Practitioner – Vendor


UC 23: Maintenance of Judicare Practitioner – Decision Suspend

USE CASE NAME UC 22 : Maintenance of Judicare Practitioner – Vendor

DESCRIPTION Maintenance of information relating to our existing Judicare Practitioner as a vendor

ACTOR Admin Officer , JCE

PRE-CONDITION Receive a request to update information relating to a Judicare Practitioner.

BASIC FLOW

1. Scan and Index- the request. 2. Amend the Accreditation Application form 3. Update records on Syspro 4. Update BEE information 5. Refer decision to another JC ( if the request is to add a

district falling under another JC) 6. JCE approves or declines the request. 7. Print and send a ‘practitioner letter’ notifying the Judicare

Practitioner of the Acceptance/ Rejection of changes.

POST CONDITION Judicare practitioner information is updated on Accreditation list.


USE CASE NAME UC 23 : Maintenance of Judicare Practitioner – Suspend

DESCRIPTION The request to suspend /exclude the Judicare Practitioner from rendering his service from a particular District.

ACTOR JCE, ROE and NOE

PRE-CONDITION Receive a request to Suspend or Exclude a Judicare Practitioner.

BASIC FLOW

1. Scan and Index- the request. 2. Update the Accreditation information - by indicating

that the district to be suspended /excluded, the date from and the reason.

3. Refer to ROE/NOE for Investigation. 4. Judicare Practitioner will be suspended during the

investigation. 5. The ROE/NOE makes a decision to Approve/Reject

the request. 6. Suspend/Exclude the district if the request to

approved. 7. Remove suspension if request declined. 8. Print and send a ‘practitioner letter’ notifying the

relevant Judicare Practitioner of the decision.

POST CONDITION If approved, the Judicare practitioner will not be able to render his service in that district- the system will not rank him for work in that district.


UC 24: BAC Procurement

USE CASE NAME UC 24: BAC Procurement

DESCRIPTION Contracts that are approved via the BAC process are scanned, captured and maintained on the system

ACTOR Procurement Admin Officer/ Procurement Manager/ Finance officer (vendor creation) /Finance Manager

PRE-CONDITION A contract is approved by BAC.

BASIC FLOW

1. Scan and index the contract 2. Capture contact information and budgeted amount. 3. Create vendor for this contract on Syspro 4. Generate a GL code for this contract 5. Maintain all a payments on this contract, making sure that they are all within

budget and within the contract period.

POST CONDITION Comply with BAC approved contract budget and condition.


UC 25: Asset Procurement Module

USE CASE NAME UC 25: Asset Procurement Module

DESCRIPTION This module assists in tracking Assets as they are being acquired until they are captured on Syspro Asset Module.

ACTOR Admin Officer/ Finance officer (assets) /Finance Manager

PRE-CONDITION Create purchase requisition to buy an asset

BASIC FLOW

1. Purchase requisition for an asset is generated. 2. System auto-generate an asset number 3. Update the asset acquisition information on system after the asset has been

acquired. 4. Update the asset information on finance system (Syspro)

POST CONDITION Asset module on Syspro is up to date.


UC 26: Validate vendor (creditors) tax status

USE CASE NAME UC 26: Validate vendor (creditors) tax status

DESCRIPTION A facility to maintain and conduct a validity check of the vendor’s (creditors) Tax Clearance Certificate Status.

ACTOR Admin Officer / Finance officer

PRE-CONDITION Check vendor’s compliance to tax clearance certificate requirements every first day of the month.

BASIC FLOW

1. The system generates a report of all vendors that will have three months or

less for their Tax Clearance Certificate to expire every first working day of the

month.

2. Send email reminders to the vendors who’s Tax Clearance Certificate are

expiring.

3. If the vendor’ tax clearance certificate has expired the vendor must be

suspended.

POST CONDITION Vendors’ tax clearance certificates up to date.