Here at TML we’re big fans of UML. We’ve been using the language since version 1.1 and have implemented UML standards in retail, banking, travel and ecommerce spaces.

UML is a standardized visual specification language for object modeling. UML is a general-purpose modeling language that includes a graphical notation used to create an abstract model of a system, referred to as a UML model.

At TML we understand the importance of goal-orientated technical documents. We find use cases fit perfectly with our ethos of producing specifications which realise business requirements. The trick is (as with all forms of system/business analysis) is to find the right level of detail for multiple stakeholders and audiences; use cases enable us to do that.

A use case is a description of a system’s behaviour as it responds to a request that originates from outside of that system.

Use cases describe the interaction between a primary actor—the initiator of the interaction—and the system itself, represented as a sequence of simple steps. Actors are something or someone which exist outside the system under study, and that take part in a sequence of activities in a dialogue with the system, to achieve some goal: they may be end users, other systems, or hardware devices. Each use case is a complete series of events, described from the point of view of the actor.

Reengineering is the radical redesign of an organization’s processes, especially its business processes. Rather than organizing a firm into functional specialties (like production, accounting, marketing, etc.) and looking at the tasks that each function performs, we should, according to the reengineering theory, be looking at complete processes from materials acquisition, to production, to marketing and distribution. The firm should be re-engineered into a series of processes.

TML have a long history of helping businesses with their reengineering programmes in a number of diverse spaces: travel, retail, manufacturing.

The term process model is used in different contexts. For example, in Business process modeling the enterprise process model is often referred to as the business process model. Process models are core concepts in the discipline of Process Engineering.

Process models are processes of the same nature that are classified together into a model. Thus, a process model is a description of a process at the type level. Since the process model is at the type level, a process is an instantiation of it. The same process model is used repeatedly for the development of many applications and thus, has many instantiations. One possible use of a process model is to prescribe how things must/should/could be done in contrast to the process itself which is really what happens. A process model is roughly an anticipation of what the process will look like. What the process shall be will be determined during actual system development.

Stakeholder analysis is analysis that aims to identify the stakeholders that are affected by the results of a project simultaneously with the result’s success depending on the cooperation between the stakeholder and the project. It is important to identify all stakeholders for the purpose of identifying their success criteria and turning these into quality goals.

A stakeholder analysis is performed when there is a need to clarify the consequences of envisaged changes, or at the start of new projects and in connection with organizational changes generally.

The stakeholder is any person or Organization who can be positively or negatively impacted by, or cause an impact on the success of the project.

In software engineering, requirements analysis encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users. Systematic requirements analysis is also known as requirements engineering. It is sometimes referred to loosely by names such as requirements gathering, requirements capture, or requirements specification. The term requirements analysis can also be applied specifically to the analysis proper (as opposed to elicitation or documentation of the requirements, for instance).

Requirements analysis is critical to the success of a development project.

Requirements must be actionable, measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.

Business analysis helps an organization to improve how it conducts its functions and activities in order to reduce overall costs, provide more efficient use of resources, and better support customers. It introduces the notion of process orientation, of concentrating on and rethinking end-to-end activities that create value for customers, while removing unnecessary, non-value added work. The person who carries out this task is called a business analyst or BA.

Those BAs who work solely on developing software systems may be called IT Business Analysts or Technical Business Analysts.