Html/Javascript widget

Monday, 21 November 2016

Functional and non-functional requirements

In Software engineering and systems engineering, a functional requirement is something the system is supposed to do, such as calculations, technical details, data manipulation and processing and other specific functionality that expected from a system. Functional requirements are supported by non-functional requirements (also known as quality requirements), which impose constraints on the design or implementation. Non-functional requirements are often used as benchmarks for rating system performance and trustability. The plan for implementing functional requirements is detailed in the system design, while non-functional requirements are found in the system architecture plan.

A functional requirement establishes what the system should do e.g.: display a bank balance.
A non-functional requirement handles features of the system that describe its behaviour. Non-functional requirements include:
Look and feel
performance and efficiency
Portability and interoperability

Class diagram

The UML class diagram (UML is a modelling language for designing applications) represents the static view of an application, being useful not only for visualising, describing and documenting different aspects of a system but for wiriting executable code of a planned software application. The class diagram presents the attirbutes and operations of a class for modelling object-oriented systems. Besides classes, class diagrams also depict interfaces, associations, collaborations and constraints. It is also known as a structural diagram. A class diagram can also describe the responsibilities of a system and serve as the basis for deployment and component diagrams. When drawing a class diagram, its name should be meaninhful to the system aspect it's describing, with each element and their relationship identified in advance.
Example of class diagram. retrieved from <>

EKD - enterprise knowledge development

EKD - enterprise knowledge development - is a recent modelling methodology for analysing, understanding and documenting the components of a an organisation. This methodology aims at narrowing ties between IT and business processes and creating a common knowledge repository, ultimately serving as a tool for effective knowledge management. Applying EKD enables a wider understanding of all the areas in a company, including the social, organisational, technical and economic aspects that come into play when establishing a plan for requirements engineering.

EKD seeks to address some issues such as:

- business plan strategies;
- analysis and definition of business rules;
- business process re-engineering;
- common understanding of how a business works to support problem solving;

EKD also uses sub-models to explore business components in depth so as to offer a breakdown of the company's current standing and how it can lead to meaningful changes that will create more value to the business:

1- objective Model: Describes what the company needs to attain and avoid. This models seeks to establish priorities and how the objectives relate to problems, threats and opportunities part of the company's reality.

2- business rule model: enacts business rules, which depends on what was established in the objectives model.

3- business process model: sets the organisational processes and the interactions involved among them.

4- concept model: defines the entities and they relate to the business flows.

5- actors and resources model: defines teh actors and resources in the business processes, depicting the relationships therein. They can be people, organisational units and functions.

6- requirements and technical component model: describes the information system to support the business activities.

Sunday, 20 November 2016

Other business process techniques.

Besides BPMN, there are other standard process modelling techniques. Many of them can also be used for software process modelling. Regardless of what is being modelled, the basic purpose remains the same: present a common representation of how information flows in a process to a wide range of stakeholders.

1 - Business Process Modeling Notation (BPMN)

BPMN is a graphical representation of a business process through standard objects. It works pretty well for presenting business process information to stakeholders with little technical knowledge about process modelling, but it can also be implemented to show a greater deal of details which would be helpful to design engineers.

BPMN usesf the following building blocks;

-Flow objects: events (circles), activities (rectangles with rounded corners), and gateways (diamonds);
-Connecting objects: arrows, these indicate sequence flow (filled arrows), message flow (dashed arrows), and associations
-Swim lanes: pools (graphic container) and lanes (sub-partition of the pool)
-Artifacts: data objects, groups, and annotations

2 - Flowchart - Few standard symbols makes it a suitable choice to a wide audience since it requires little knowledge or understanding of how modelling works. While it relies heavily on sequential flows of actions, it's not optimised to depict the breakdown of individual activities. Its symbols are very similar to those used in BPMN, execpt that it uses rectangles with rounded edges for the start/end events, rather than an empty circle, while a parallelogram stands for data input and output.

3- Integrated Definition for Function Modeling  (IDEF) - IDEF is a family of methods that supports a paradigm capable of addressing the modelling needs of an enterprise and its business areas (IDEF, 2003). The IDEF family comprises different applications. For business process modelling, the most useful versions are IDEF0 and IDEF3. IDEF 0 is structured analysis and design technique a method for modelling actions, activities and decisions for organisations and systems. Effective IDEF0 models help to organise the analysis of a system and to promote good communication between the analyst and the customer. IDEF0 is useful in establishing the scope of an analysis, especially for a functional analysis. It's common to refer to IDEF0 as the box and arrow diagram, in which the box shows the function and the arrows going in and out of it indicate how operations are performed and controlled.  Activities can be described by their inputs, outputs, controls and mechanisms (ICOMs).

4- IDEF3 or Integrated DEFinition for Process Description Capture Method is a business process modelling technique, which comprises of a scenario-driven process flow description to learn how a specific system works. in other words, if you intend on finding out how the particulars of a certain system, you will do well to use IDEF3. IDEF3 enables capturing teh relationships between the actions of a given scenario and object state transition to capture the description of all possible states and conditions. The main purpose of IDEF3 is for a domain expert to express knowledge about how a system or process works.
As it may already be noticeable by now, description is a big part of IDEF3, being a keyword in this process modelling technique and having a specific meaning records of empirical observation (based on experience or common observations). Unlike description, a model is a proposed entity or state of affaris, supposed to represent objects and relations from a real-world system.
There are two IDEF3 description modes, process flow (captures knowledge of "how things work" in an organisation) and object state transition network (summarises the allowable transitions of an object throughout a particular process.).

5 - ARIS The ARIS toolset is a software tool for the depiction, upkeep and optimisation of business processes based on the ARIS framework. The ARIS toolset is split into 4 categories: control, data, organisational and functional.

6 -organogram- is a diagram that shows the structure of an organisation and the relationships of its parts and positions/jobs. As a diagram and process modelling technique, it's most efficient to depict hierarchy of organisational units. It can also be used to demonstrate the relationship of a department to another. Keywords frequently reserved for this modelling lanaguge include: organisational units, lines (to show hierachical structure), role, internal/external person and group.

7 - EPC - Event-driven process chain- An 'Event-driven process chain' (EPC) is a modeling language for describing business processes and workflows. EPCs can be used for setting up an enterprise resource planning (ERP) implementation, and for business process improvement.

Event - Events are passive elements in event-driven process chains, describing how a function or a process works or which state they result in. In the EPC graph an event is represented as hexagon. In general, an EPC diagram must start with an event and end with an event.

Function - Functions are active elements in an EPC, representing tasks or activities within the company. Functions describe transformations from an initial state to a resulting state. In the event-driven process chain graph a function is represented as rounded rectangle.

Process owner - Process owner is responsible for a function and is usually part of an organisation unit.Represented as a square with a vertical line.

Organisation unit - Organization units determine which organisational unit is responsible for a specific function. Examples are "sales department", "procurement department", etc. It is represented as an ellipse with a vertical line.

8 - FAD (funciotnal allocation diagram) - the Functional Allocation Diagram (FAD) is used to depict the Enterprise Business Services and operations for a particular integration. The average FAD should depict how input turns into output, the execution and the reousrces to make this happen.

BPMN - a brief description

Business Process Model and Notation (BPMN) is a graphical language for representing business processes in a business process model by OMG (object management group). BPMN proposes symbols and conventions that enable the user to model business processes and workflows and document information about current or proposed businesses.

Business Process Model and Notation (BPMN) is a standard for business process modelling that provides a graphical notation for specifying business processes in a Business Process Diagram (BPD), based on common flowcharting technique similar in other diagram languages. Using BPMN allows both technical and business users to simultaneously understand a graphical representation of the business processes in standardised form and find areas in the business model that could use improvement or remodelling. BPMN helps bridge the common communication gap between business process design and implementation.

Types of BPMN sub-model:

Business process modeling is used to communicate a wide variety of information to a wide variety of audiences. There are three basic types of sub-models within an end-to-end BPMN model:

Private (internal) business processes
Private business processes are internal to a specific organisation, generally called workflow. The Sequence Flow of the Process is constrained to a single Pool without crossing its boundaries. Only Message Flows can trespass the Pool boundary to show the interactions with other private business processes.

Abstract (public) processes
This represents the interactions between a private business process and another process or participant. Only those activities that communicate outside the private business process are included in the abstract process. Private activities are not shown in the publc process.

Collaboration (global) processes
the interactions now take place between two or more business entities. These interactions are defined as a sequence of activities that represent the message exchange patterns between the entities involved.

As a universal notation for process modelling, BPMN uses common elements to represent the interactions and information flows in its graphical representations. They are split into 5 categories:

Flow objects: Events, activities, gateways

Data Objects: data input, data output, singular and collective representation of data, data storage and message

Connecting objects:  Sequence flow, message flow, association
Swim lanes: Pool, lane
Artifacts: group, annotation (some authors include data objects within this category).

Connection Objects in BPMN
Types of Gateway, a category of flow objects

Thursday, 3 November 2016

Business Process Modelling and introduction to BPMN

Process modelling can be understood as a set of business activities depicted by graphical conventions for showing the end-to-end chain of events for primary, support and management processes. A perspective from a processual point of view lets all stakeholders understand all components of the business process, as well as the parts that need to communicate with other areas of the organisation. BY modelling a process we can represent how business works in a thorough and accurate manner. The process can be modelled according to the level of details adquate for the intended stakeholder. A nontechnical staekholder will require a simpler representation of the business processes, while a higher level of details is necessary for a technical stakeholder, whose role in the company usually demands a more comprehensive reading of the process diagram.

The main use of process modelling is to identify all the business areas involved in an activity, in addition to visualising the steps needed to successfully accomplish said activity in a most efficient way. Therefore, it can be inferred from process modelling that it helps understand the structure and dynamics at play of every organisational area and spot current problems and potential workarounds besides assuring that engineers and users have a common understanding of the organisation's inner workings.

A process model may comprise one of more diagrams, with each diagram containing its distinct set of objects and information about their behaviour and interaction with otehr objects. Modellilng a process usually involves illustrations using  icons and their relationships with other icons and entities. These icons and the symbols used for signalling their behaviour aren't created at random; but, rather, they are usually adapted from a standardised notation. Among the many advantages of using a standard for process modelling we can cite the use of a convention for universal understanding of the process components, consistency in use and meaning of the model and the possibility for portability of the business process diagram between different tools. It's important to notice that the standards for process modelling aren't applicable in different areas, there being specific modelling languages for established areas. Some of the languages include BPMN (business process model and notation), flowcharts, UML (unified modelling language), ARIS, IDEF (integrated definition language) etc.

BPMN (business process model and notation).

The primary goal of BPMN is to provide a notation easy to be understood by all stakeholders, including business users, developers and personel who will overlook and manage the processes. This standard looks to bridge the business process analysis and the process implementation. Thus it can be said that the main objective of BPMN is to propose a simplified means of communicating information among all involved in a business process. It bears mentioning that there are three basic types of modelling in a BPMN framework:

private/internal processes - also known as workflow or BPM processes. Modelling within a private view means that all information flow will be contained within a single lane.

public/ abstract - a visual representation of a private business process and another process or participant (remember that in BPMN a participant is also a pool). A public process differs from its private counterpart in that it throws into the mix external communication and control flow mechanisms to other participants. Other processes don't show here. Its main concern is to show to the external world the messages exchanged with another process or entity.

collaboration/global- full display of all teh possible interactions between two or more entities. The whole string of activities can be viewed here, including the messages exchanged back and forth among the participants. This model can hold one or more processes. In a collaboration process model, each participant is identified by a pool (as in a swiming pool) and the information flow can't cross over to the neighbouring swimlane. The communication between different pools is accomplished by messages carried over by association lines.