Software Requirements Specification

version 1.0

Dated: 10th December, 2004

 

bWise - Enterprise Application Integration Framework

Anurodh Srivastava & Shalin Shekhar Mangar,
JSS Academy of Technical Education, Noida.
Group: RHS041528

 

Contents

Section	Title
1	Introduction
	1.1 Purpose
	1.2 Document Conventions
	1.3 Intended Audience and Reading Suggestions
	1.4 Scope of Development Project
	1.5 Definitions, Acronyms and Abbreviations
	1.6 References
	1.7 Overview
2	Overall Description
	2.1 Product Perspective
	2.2 Product Function
	2.3 User Classes and Characteristics
	2.4 Operating Environment
	2.5 Design and Implementation Constraints
	2.6 User Documentation
	2.7 Assumptions and Dependencies
	2.8 Overview of Data Requirements
	2.9 General Constraints, Assumptions, Dependencies, Guidelines
	2.10 User View of Product Use
3	External Interface Requirements
	3.1 User Interfaces
	3.2 Hardware Interfaces
	3.3 Software Interfaces
	3.4 Communications Interfaces
4	System Features
	4.1 System Feature 1
	4.1.1 Description and Priority
	4.1.2 Stimulus/Response Sequences
	4.1.3 Functional Requirements
	4.1.3.1 Purpose
	4.1.3.2 Inputs
	4.1.3.3 Outputs
	4.2 System Feature 2
	4.2.1 Description and Priority
	4.2.2 Stimulus/Response Sequences
	4.2.3 Functional Requirements
	4.2.3.1 Purpose
	4.2.3.2 Inputs
	4.2.3.3 Outputs
5	Other Nonfunctional Requirements
	5.1 Performance Requirements
	5.2 Safety Requirements
	5.3 Security Requirements
	5.4 Software Quality Attributes
	5.5 Business Rules
	5.6 Special User Requirements
	5.6.1 Backup and Recovery
	5.6.2 Data Migration
	5.6.3 Data Retention
	5.6.4 User Training
	5.6.5 Installation
6	Other Requirements
	6.1 Coding Standards
	6.2 Database Requirements
	6.3 Internationalization Requirements
	6.4 Legal Requirements
	6.5 Reuse Objectives

 

1. Introduction

1.1 Purpose

This Software Requirements Specification (SRS) specifies the requirements of bWise - Enterprise Application Integration (EAI) Framework, which will be used in corporate computer departments. This document will be used by the KReSIT software evaluation team to ensure that all specifications are correct and verified by the software engineer to design the system.

1.2 Document conventions

Main Section Title: Font: Times New Roman : Bold : Size : 18

Sub Section Title: Font: Times New Roman : Bold : Size : 14

Other Text: Font: Times New Roman : Size : 12

Underlined text is used to denote important side headings.

1.3 Intended audience and reading suggestions

Business Process Analysts - The Business Process Analysts will be using part of this software to design and develop the EAI roadmap of the concerned organization.

EAI Developers - The EAI Developers will use the various parts of the system APIs for customization of the default configuration.

System Administrators - The System Administrators will use part of the software for enforcing authentication and authorization.

1.4 Scope of the development project

The purpose of the bWise software is to automate and co-ordinate a business process involving more than one application, while automating the data transfer, transformation and processing in a secure manner. bWise will provide developer tools such as Business Process Designer, Document Designer and Document Transformation Designer, along with a Process Co-ordination Server (server component) and associated administration tools. The developer tools will be implemented as plug-ins for the Eclipse IDE providing a complete framework for EAI development. The Process Co-ordination Server will be a server component which will execute the EAI process created through the developer tools. The Administration tools include tools for configuration, management and viewing performance statistics of the Process Co-ordination Server.

1.5 Definitions, Acronyms, Abbreviations

1. Business Process

2. Document

3. EAI

4. IDE

5. Enterprise Single Sign-on

6. Correlation

1.6 References:

1. Business Process Execution Language for Web Services (BPEL4WS) specification

2. Workflow Design Patterns

3. Design Patterns

4. Eclipse Plug-in Developer's Guide

5. Thinking in Java

1.7 Overview of document

The first section of SRS gives a brief idea what bWise is and what is the need behind having it. Along with this background information it also provides the reference information for further study, design and implementation.

The second section throws light on overall description of application, functions, perspective, operating environment, design and implementation constraints, data inputs required.

The third section gives description of external interfaces such as user interface, hardware interface, communication interface and software interface.

The fourth section includes system features in detail. The subsections describe the features in much more detail.

The fifth section gives details of non-functional requirements such as security requirements, safety requirements etc.

 

2. Overall Description

2.1 Product perspective

An Enterprise Application Integration (hereon referred to as EAI) framework is a platform-neutral e-commerce framework that enables integration across business applications, regardless of platform, operating system or underlying technology. It enables integration, management and automation of dynamic business processes by exchanging business documents and messages among applications, within or across organizational boundaries. bWise is an open-source EAI framework which performs all the above functions. This SRS describes the functional and performance specifications of a new EAI framework and its related components. Since the primary feature of the software would be to communicate with other applications, the applications will support many external interfaces including Web Services, Email, FTP, file system transfer facilities for exchanging documents with other applications.

The steps for performing integration using bWise are:

1. For a given scenario, the Business Process Analyst identifies and analyzes a business process.

2. The Analyst then proceeds to draw the logical structure of a business process in the Business Process Designer.

3. The EAI developer then, studies the process diagram, identifies the applications participating in the process, identifies the external interfaces to those applications including the communication methods (Email, FTP, Web Services etc.), the document (message) structure required by the application and document transformations (if required).

4. The EAI developer defines the document formats (using the bWise Document Designer) and the document transformations (using the bWise Document Transformations Designer) and these definitions are added to the process diagram.

5. The EAI developer defines the document transport (both input and output) mechanisms in the form of Message Transport Agents (MTA) and adds the MTA in their respective places in the process diagram.

6. The finished process diagram is then loaded into the bWise Process Co-ordination Server.

7. The System Administrator defines the configuration and authentication mechanisms required to execute the business process.

8. An instance of the Process Co-ordination Server is then executed for the given Process Diagram.

The steps outlined above are illustrated in the figure given below:

Figure 1: EAI through bWise

 

Figure 2: An Example Network Architecture for EAI

The context diagram in Figure 2 shows an example of how bWise Server may be used in a sample EAI scenario. This sample scenario is for a order processing system. Here the bWise server runs the Process Co-ordination Server and handles requests from the web server and the email server which provide initial input to the order processing business process. The order is coordinated using applications like Spare Parts application, MARC, Sales System, I2 (Business Intelligence & Data Mining) application and Finance application.

 

2.2 Product functions

The following is the list of primary functions provided by bWise:

1. Development of business process for automation

2. Administration and configuration

3. Execution of business process

 

2.3 User classes and characteristics

The various use classes that are anticipated for this product are:

Process Analysts - Use the Business Process Designer to diagram the process and its related data flows.

EAI Developers - Identify and specify the messages needed to be passed, their schemas, transfer methods etc.

Administrators - Setup, manage and monitor the bWise process execution server.

2.4 Operating environment

The software, being developed in Java, will be executed in a Virtual Machine specific to each operating system. Hence the software will run on Linux, Solaris and Windows environment.
The minimum hardware requirements of the software will be specific to the operating system used but a general configuration is specified:

Pentium-II class CPU 300 MHz and above

128 MB RAM

100 MB Hard disk space

The software requirements consist of only the Java Virtual Machine: J2RE v1.5.0.

2.5 Design and implementation constraints

The software will use Java and hence will be dependent on the presence of a Java Virtual Machine.

2.6 User documentation

The software will be delivered with an electronic user manual, Software Design Specification (SDS), UML diagrams and Javadocs.

2.7 Assumptions and dependencies

The software uses the following third-party components:

Eclipse IDE - for implementing process designer and other components for developers as plugins.

Apache Axis - as a Web Services hosting server.

Apache log4j - as a logging toolkit

Quartz - Job Scheduler

Apache Jakarta Commons - Miscellaneous functionalities.

Apache Xindice - native XML database

Apache Derby - as an embeddable database engine

JOSSO – Java Open Single Sign On solution

Piccolo – Java2D graphics drawing toolkit

Apache Batik – toolkit for SVG rendering and manipulation

Apache Avalon – a framework for server applications

Trove4j – A library of high performance collection utilities

J.A.D.E. – Java addition to default environment (miscellaneous utilities)

Apache Xerces

2.8 Overview of data requirements

The data needed to be input to the system is the business process diagrams, details of message receive and transfer mechanisms, document schemas and transforms.
The output would be performance statistics and run-time logs including success and failure notifications.

2.9 General constraints, assumptions, dependencies, guidelines

The software would work only with Java Virtual machines supporting Java 1.5

The software adopts and implements the Business Process Execution Language for Web Services (BPEL4WS) specification for defining and describing business processes.

2.10 User view of product use

The process analyst will first create the business process diagram. The EAI developers will then analyze and specify the applications participating in the process, their associated message transfer methods, message document schemas and transformations. The administrators will then create user accounts and load the designed process for execution in the process execution server.

3. External Interface Requirements

3.1 User Interfaces

The developer components like the process designer, document schema designer will be implemented as Eclipse IDE plugins and hence will follow the UI standards of the Eclipse IDE.
The administrative module will be implemented in Eclipse SWT toolkit.

3.2 Hardware Interfaces

Not Applicable

3.3 Software Interfaces

The data messages coming in and going out of the system will be dependent on the business process being coordinated and is a dynamic functionality determined at run-time. Hence the messages cannot be specified exactly beforehand.

3.4 Communications Interfaces

The software requires communication interfaces such as email, HTTP, FTP and LDAP.
The software uses digital signatures and certificates for authentication and authorization of messages.

4.   System features

As the bWise software contains multiple components, the system features are organized by user classes viz. Process Analysts, EAI Developers and System Administrators.

4.1 Document Designer

4.1.1 Description and priority

The Document Designer is a tool which is used to create document specifications i.e. document format definitions against which a document instance is validated.

4.1.2 Response/Stimulus sequences

The response/stimulus for the different classes of users are:

1. Business Process Analysts: None

2. EAI Developers: Create, edit, modify and save document specifications.

3. System Administrators: None

4.1.3 Functional Requirement

The features required in the Document Designer are:

1. Provide a way to load a positional or delimited document and create its generic specification against which other instances of the document can be validated.

2. Load an already created document specification and modify it to suit other document specifications.

4.2 Document Transformation Designer

4.2.1 Description and priority

The Document Transformation Designer is a tool which is used to define the transformations between two message specifications i.e. it is used to define one-to-one correspondence between to message specifications.

4.2.2 Response/Stimulus sequences

The response/stimulus for the different classes of users are:

1. Business Process Analysts: None

2. EAI Developers: Create, edit, modify and save document transformations.

3. System Administrators: None

4.2.3 Functional Requirement

The features required in the Document Transformation Designer are:

1. Load two document specifications and provide a way to map the data elements in the two specifications.

2. These transformations must be made persistable on disk for future modification.

4.3 Business Process Designer

4.3.1 Description and priority

The Business Process Designer enables the process analyst to graphically specify the data flows associated with a business process and its associated applications. This is a High priority component.

4.3.2 Response/Stimulus sequences

The response/stimulus for the different classes of users are:

1. Business Process Analysts: Create, edit, modify, save business process diagrams.

2. EAI Developers: Add document specifications, document transformations, communication interfaces into the diagram.

3. System Administrators: None

4.3.3 Functional Requirement

The features required in the Business Process Designer are:

1. Provides a 2D drawing canvas for drawing process diagrams

2. Provides a library of pre built shapes denoting special entities like start, stop, branch, condition, document transformation, MTA, notification, application and custom entity.

3. Dragging, adding, deleting, resizing, editing properties of entities to the canvas must be allowed.

4. Creation, saving, loading, editing and modification of diagram must be supported.

5. If an entity (such as a transformation) is required which has not been created, the tool must provide an interface (such as a button) to start the appropriate builder tool (transformation designer in this sample case) to define the entity.

6. Wherever possible, the 2D figure representing the entity should provide a list of available choices for that particular class of entities.

A sample business process diagram created by a proprietory tool is shown below:

Figure 3: A sample Business Process Diagram

 

4.4 Messaging Manager

4.4.1 Description and priority

The Messaging Manager is the tool which enables the EAI Developer to specify the various applications involved in the process, their external communication interfaces and message transfer methods. The application profiles defined by this tool are then specified into the Business Process Diagram.

4.4.2 Response/Stimulus sequences

The response/stimulus for the different classes of users are:

1. Business Process Analysts: None

2. EAI Developers: Create new application profiles which specify communication interfaces of the application and Message Transport Agents (MTA).

3. System Administrators: None

4.4.3 Functional Requirement

The features required in the Messaging Manager are:

1. Create message pipelines which involve document transformations in between input and output interfaces specified by Message Transport Agents.

2. Create, edit, modify and save Message Transport Agents (MTA).

3. Specify the encryption to be used, if any, for the document being transmitted.

4. Specify the decryption method to be used, if any, for the document being recieved.

4.5 Process Coordination Server

4.5.1 Description and priority

The Process Coordination Server is used to execute the business process defined in the process diagram developed by the Process Analyst and the EAI Developer. Its responsibilities include: process workflow execution as defined in the diagram, reliable message transport, process status notification (success/failure/suspended/timed-out or custom notification), secure transport, routing and correlation of messages.

This component is a stand alone system and hence has no user interactions directly.

4.5.2 Response/Stimulus sequences

The response/stimulus for the different classes of users are:

1. Business Process Analysts: None

2. EAI Developers: None

3. System Administrators: None

4.5.3 Functional Requirement

The features required in the Process Coordination Server are:

1. It must be able to discover new business processes loaded into the server by the administration tools.

2. It must be able to execute a business process without any user intervention, once the process is loaded.

3. It must maintain a transaction and activity log specifying the messages, recieved, sent and process activity status records.

4. It must support asynchronous communication between applications involved in a process.

5. It must be able to maintain a process state for the time-out period specified without losing any data for a process suspended or waiting for a request or response by a participating application.

6. If the server is shut down for some reason then all running processes should be suspended and their state should be persisted on disk and on regaining execution the server must restore the processes in the same state as before.

7. The server must provide for reliable and secure message transport by utilizing cryptographic services.

8. The server must provide a mechanism for disseminating alert notifications to subscribing applications, in the event of a process suspension or abnormal termination.

9. The server must provide support for correct routing of message as defined in the process diagram's data flow.

10. The server must provide for correlation of messages i.e. the messages recieved into the system must be sent to the correct process instance and correct application instance so that multiple instances of the same process can run in parallel.

4.6 Administration Tools

4.6.1 Description and priority

The Administration Tools are used by the System Administrators to load and unload Business Processes, configure server properties, configure and manage Message Transport Agents (MTA) installed on the system, view and manage the transaction logs, manage the server database, backup and restore data, monitor alert notifications and view performance statistics.

4.6.2 Response/Stimulus sequences

The response/stimulus for the different classes of users are:

1. Business Process Analysts: None

2. EAI Developers: None

3. System Administrators: all above specified actions.

4.6.3 Functional Requirement

The features required in the Administration tools are:

1. Configure server execution properties such as log file size and other parameters.

2. Configure and manage Message Transport Agents (MTA) including installation and uninstallation of MTAs into the system.

3. View and manage the server database.

4. View and manage the transaction and activity logs.

5. Backup and restore data including scheduling automatic backups.

6. Monitor alert notifications.

7. Provide a Publish-Subscribe model for alert notifications.

8. View performance statistics such as process instances executing per minute, workload division among installed business processes.

5.   Other nonfunctional requirements

5.1 Performance requirements

The software must be able to handle peak loads of upto a thousand business process executions per day. Moreover the software may need to execute many different processes in parallel. The software must hence be highly efficient so that it scales upto the load specified.

To support business processes that involve long running transactions involving periods ranging from days to months, the communication infrastructure must be aysnchronous in nature.

The Business Process Designer must support a highly responsive user interface for drawing process diagrams.

5.2 Safety requirements

The software must provide facilties to make a through system backup and recovery, comprising complete transaction log backup and persistence of running business processes.

5.3 Security requirements

The software must provide facilities to use digital signatures and certificates, encryption of documents passing between applications participating in a business process.

5.4 Software quality attributes

The source code of the product is going to be open as this is going to be open source software. It will be free for further modifications and improvements.

The software must provide an application programming interface to facilitate further enhancement and tweaking of the default configuration.

The software must be reliable i.e. for each execution of a business process, the end result (success/failure) must be communicated without fail. The software must detect and inform the administrator about malformed messages recieved and about failure of communication to a specific interface, so that the failure can be identified and corrected quickly. The software, once correctly and fully configured, must be able to run without user intervention i.e. the errors and exceptions should not result in the termination of the software.

5.5 Business rules

Not Applicable

5.6 Special user requirements:

5.6.1 Backup and Recovery:

The software must provide facilties to make a through system backup and recovery, comprising complete transaction log backup and persistence of running business processes.

5.6.2 Data Migration:

Not Applicable

5.6.3 Data retention:

The software must maintain a log of all business processes both under execution and previously executed.

5.6.4 User Training:

The user training will be solely through the electronic user manual provided.

5.6.5 Installation:

The software must provide different distributions for:

1. Client side (developer tools) installation

2. Administrative tools installation

3. Business process execution server installation

4. Complete installation (including all above with documentation and source+binary)

6. Other requirements

6.1 Coding standards

The software must follow the coding standards outlined in the Java Coding Standards outlined by Sun Microsystems.

6.2 Database requirements

The software must use a database for effective querying of XML messages. For this purpose a native XML database is recommended.

6.3 Internationalization requirements

The software must support the unicode text encoding so that the software can be used to handle messages composed of international languages (particulary asian languages which have extended character sets).

6.4 Legal requirements

The software must be open source and hence must be released under the GNU General Public Licence.

6.5 Reuse objectives

The software must be made as modular as possible so that the individual components can be reused in multiple scenarios. Also, the business process designer component must be able to support many kinds of business processes.

Any open source software component used after modification must be made public so that the contributions can be shared in the open source community.