Peculiarities Of Functional Requirements Of Automated Enterprise Resource Management System

Participants of requirements generation

Any ERP-system is applied. Therefore, all ERP-system requirements should be developed by specialists who will interact during the design, testing and operation of the system. The full list of these specialists was suggested by Wieggers and Beatty (2014) who divided them into three categories:

• Specialists working outside an organization, which designs ERP-systems, but using information generated within the system (purchasers, purchasing specialists, subject experts, consultants, etc.).

• Designing organizations (design managers, marketing departments, IT-designers, training managers, etc.).

• Project teams (project managers, business analysts, designers, business decision designers, quality control analysts, process analysts, etc.).

Involvement of all these participants depends on:

• the scale of projects (project functions);

• internal features of automation objects (manufacturing and management technologies applied);

• relations between automation objects and connected systems and organizations;

• features of project management processes;

• a professional level of an ERP-system designing team.

Requirements generation issues

Formulation of functional requirements is carried out at the earliest stage of the ERP-system creation. Therefore, this process is one of the main ones. From the quality of its implementation depends the entire subsequent process of design and development (Baronov, Kalyanov, Popov, & Titovsky, 2006).

Sometimes the requirements are presented in a generalized form and an additional procedure for their detailing is required for implementation in the form of a program. In addition, functional requirements are not separately identified and are considered together with technological requirements (for example, storage of information) (Usov, 2007).

Some authors consider not specific requirements, but characteristics of requirements for various business configurations (simple configuration, mechanical bureaucracy, professional bureaucracy, adochocracy). For each configuration, the requirements groups are taken into account: where will be applied, operational activities, personnel, functionality, system architecture. At the same time, functionality is formulated only in general terms, which can not be implemented algorithmically in the original form and require very detailed additional consideration (Astapchuk & Tereshchenko, 2015).

Often the requirements for ERP-systems are considered only as technological requirements (for example, modular design, reliability, security and others). However, such requirements are common to any system that will be implemented as an application program. Functional requirements are described as the names of the modules included in the ERP system, that is, in general terms. Such a description does not reflect the algorithmic nature of the solution (Oleinik, 2012).

Analysis of only a few approaches allows us to draw the following conclusions:

• There are no uniform standards for the formulation of functional requirements.

• Information on requirements is of an advisory nature.

• The stylistics of the formulation of requirements presents them only in a general way.

• All the options considered require further elaboration.

• None of the approaches makes it possible to present the requirements as a task for programming

The generation of automated system requirements is a challenge of ERP-system designing and development which consists of the following problems:

• For a number of reasons, ERP-system users cannot provide exhaustive information upon request.

• As far as each party involved includes specific professional specifications, some requirements can be contradictory.

• It is difficult to determine requirements detail levels which can increase their amount, make it difficult to unify the requirements and impossible to manage them correctly.

• Insufficient involvement of users.

• Not all potential users are surveyed when designing requirements. Therefore, their requirements will not be implemented.

• There are redundant requirements which can be neglected since they do not improve decisions but need time and financial resources (Wieggers & Beatty, 2014).

Another problem is the lack of a single structural form, into which primary requirements can be recorded. Therefore, there are different options for describing them, for example, a text or a graphic model (Gusyatnikov & Bezrukov, 2010).

Choosing task names when generating requirements

It is useful to choose correct names of tasks which have to be implemented when designing a new system or modernizing an existing one. Task names have to include management functions which predetermine management functions implementation algorithms under the automated data processing, i.e. they simplify decision algorithm programming (Gutgarts, 2015).

Technical, technological, information and software functions of modern information technologies are diverse. They can implement any incredible functional requirements of potential users. However, it is necessary to identify these requirements and cast them into the correct form in order to simplify a formalization process. It is an obligatory programming condition. The requirements which cannot be described using logical dependences and formal presentations (unable to be algorithmized) cannot be implemented.

Future ERP-system users have to know which functions the system implements. However, at the designing stage, manufacturers cannot explain and formalize their wishes and IT-specialists cannot understand manufacturers since they use different terms.

To understand requirements of future ERP-system users, IT specialists have to go into details of manufacturing and/or management processes. Otherwise, they cannot carry out pre-project analysis. This process is often iterative. When IT specialists and manufacturers reach understanding, the ERP-system designing and development process starts.

The issues of relations between future users and IT specialists have existed since the beginning of development of applied automated systems for manufacturing companies. In 1973, the Information Bulletin of London University Computer Center published a comical picture of these relations (Pavlovskaya, 2004).

The issue of misunderstanding between parties involved is still crucial. Therefore, if required functions are not implemented, the project is useless (Gutgarts, 2008).

Functional requirements generation methods

• Coburn suggested an approach based on the following concepts:

  • Actors: somebody or something that is behaving.

  • Participants: somebody or something interested in the system behavior.

  • Key actors: participants who can initiate relations with the system for achieving specific purposes.

  • Use cases: behavioral scenarios.

  • Scope: a system designed.

  • Initial conditions and guarantees: what should be true before and after the use case implementation.

  • Main scenarios: standard solutions (main calculation processes) excluding errors.

Extension use cases (possible branches of the main calculation process) occurring under certain conditions violating standard use cases (non-standard processing procedures have to be applied) (Kobern, 2002).

Dealing with software requirements, D. Leffingwell and D. Widrig use the following concepts:

• Requirement is a function of a system.

• Requirements management involves recording, analysis and implementation of variable system requirements.

• Tasks of clients which have to be described using their terminology. It helps understand the needs of users and implement them in the system.

• Functions are requirements implemented in the system. When a set of functions negotiated with future users are identified, requirements are specified.

• Precedents are use cases for obtaining data processing results upon the user request (Leffingwell & Widrig, 2002).

The key feature of these approaches is the lack of a unified presentation structure and bulky description.

The first requirements generation level

Tasks names are presented through main management functions. Let us analyze examples of each management function.

Recording means that recorded information reflects performance of transactions. The task involves data basing from primary media (documents, oral messages, devices, etc.).

Planning (calculation, prediction) involves calculation procedures. The task is performed using information in the data base. Information which is not stored in the data base can be used for solving certain tasks.

Control involves calculation of deviations of planned data from factual (recorded) ones. The results can be kept or not kept in the data base depending on their further application.

Analysis involves selection of information from the data base and delivery reports to a specialist for recording, planning and control.

Control involves editing of planned information.

Thus, the use of functions as task names simplifies development of algorithms for automated decisions.

The second requirements generation level

Part 1: General characteristics of the task

1.1. Name (when using a management function) and assignment (for which objects it is designed).

1.2. Conditions and restrictions (if the use of a mathematical model is suggested); possible optimality criteria (for optimal planning tasks); alternate solutions (logical branches of the algorithm); restrictions on the search space.

1.3. Chronological features.

1.4. Relations with other tasks (through input and output data).

1.5. Restrictions imposed by related tasks.

1.6. Source data collection management (data sources and acquisition methods).

1.7. Chronological restrictions on solution results.

1.8. Specific features (if there are any).

Part 2: Data support.

2.1. Description of input information (a presentation form, semantic characteristics of indices and other features).

2.4. Reference data.

2.5. Output (resultant or analytical) information (a presentation form, semantic characteristics of indices and other features). The list and structure of controlled output information. The availability and assignment of the query system. Purposes of information (solution results) utilization.

Part 3: Mathematical support (task solution algorithm describing a standard solution path and all possible non-standard situations occurring when solving the task.

Part 4: Description of a test case. Identification of the quality and amount of source data which will be used for testing the task solution correctness.

Depending on the task, some parts can be omitted or expanded (specified).