Requirements Engineering

Requirements engineering (RE) refers to the process of formulating, documenting and maintaining software requirements and to the subfield of software engineering concerned with this process.

The first use of the term 'requirements engineering' was probably in 1979 in a TRW technical report but did not come into general use until the 1990s with the publication of an IEEE computer society tutorial and the establishment of a conference series on requirements engineering.

In the waterfall model, requirements engineering is presented as the first phase of the development process. Later software development methods, including the rational unified process, extreme programming and scrum assume that requirements engineering continues through the lifetime of a system. Alan m. Davis maintains an extensive bibliography of requirements engineering. Types of Requirements

Requirements are categorized in several ways. The following are common categorizations of requirements that relate to technical management: 1. Customer Requirements

Statements of fact and assumptions that define the expectations of the system in terms of mission objectives, environment, constraints, and measures of effectiveness and suitability (MOE/MOS). The customers are those that perform the eight primary functions of systems engineering, with special emphasis on the operator as the key customer. Operational requirements will define the basic need and, at a minimum, answer the questions posed in the following listing:

a. Operational distribution or deployment: where will the system be used? b. Mission profile or scenario: how will the system accomplish its mission objective? c. Performance and related parameters: what are the critical system parameters to accomplish the mission? d. Utilization environments: how are the various system components to be used? e. Effectiveness requirements: how effective or efficient must the system be in performing its mission? f. Operational life cycle: how long will the system be in use by the user? g. Environment: what environments will the system be expected to operate in an effective manner? 2. Architectural Requirements

Architectural requirements explain what has to be done by identifying the necessary system architecture of a system. 3. Structural Requirements Structural requirements explain what has to be done by identifying the necessary structure of a system. 4. Behavioral Requirements Behavioral requirements explain what has to be done by identifying the necessary behavior of a system. 5. Functional Requirements

Functional requirements explain what has to be done by identifying the necessary task, action or activity that must be accomplished. Functional requirements analysis will be used as the top level functions for functional analysis. 6. Non-Functional Requirements

Non-functional requirements are requirements that specify criteria that can be used to judge the operation of a system, rather than specific behaviors. 7. Performance Requirements

The extent to which a mission or function must be executed; generally measured in terms of quantity, quality, coverage, timeliness or readiness. During requirements analysis, performance (how well does it have to be done) requirements will be interactively developed across all identified functions based on system life cycle factors; and characterized in terms of the degree of certainty in their estimate, the degree of criticality to system success, and their relationship to other requirements. 8. Design Requirements

The “build to,” “code to,” and “buy to” requirements for products and “how to execute” requirements for processes expressed in technical data packages and technical manuals. 9. Derived Requirements

Requirements that are implied or transformed from higher-level requirement. For example, a requirement for long range or high speed may result in a design requirement for low weight. 10. Allocated Requirements

A requirement that is established by dividing or otherwise allocating a high-level requirement into multiple lower-level requirements. Example: a 100-pound item that consists of two subsystems might result in weight requirements of 70 pounds and 30 pounds for the two lower-level items. Well-known requirements categorization models include FURPS and FURPS+, developed at Hewlett-Packard. Requirements Engineering Activities (Requirements Engineering Process)

The activities involved in requirements engineering vary widely, depending on the type of system being developed and the specific practices of the organization(s) involved. These may include:

1. Requirements inception or requirements elicitation -

In requirements engineering, requirements elicitation is the practice of collecting the requirements of a system from users, customers and other stakeholders. The practice is also sometimes referred to as requirements gathering.

The term elicitation is used in books and research to raise the fact that good requirements cannot just be collected from the customer, as would be indicated by the name requirements gathering. Requirements elicitation is non-trivial because you can never be sure you get all requirements from the user and customer by just asking them what the system should do. Requirements elicitation practices include interviews, questionnaires, user observation, workshops, brainstorming, use cases, role playing and prototyping. Before requirements can be analyzed, modeled, or specified they must be gathered through an elicitation process. Requirements elicitation is a part of the requirements engineering process, usually followed by analysis and specification of the requirements.

Commonly used elicitation processes are the stakeholder meetings or interviews. For example, an important first meeting could be between software engineers and customers where they discuss their perspective of the requirements.

2. Requirements identification - identifying new requirements 3. Requirements analysis and negotiation - checking requirements and resolving stakeholder conflicts

Requirements analysis in systems engineering and software engineering, 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, analyzing, documenting, validating and managing software or system requirements.

Requirements analysis is critical to the success of a systems or software project. the requirements should be documented, actionable, measurable, testable, traceable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.

4. Requirements specification (software requirements specification)- documenting the requirements in a requirements document

A software requirements specification (SRS), a requirements specification for a software system, is a complete description of the behavior of a system to be developed and may include a set of use cases that describe interactions the users will have with the software. In addition it also contains non-functional requirements. Non-functional requirements impose constraints on the design or implementation (such as performance engineering requirements, quality standards, or design constraints).

The software requirements specification document enlists all necessary requirements that are required for the project development. To derive the requirements we need to have clear and thorough understanding of the products to be developed. This is prepared after detailed communications with the project team and customer.

The SRS may be one of a contract deliverable data item descriptions or have other form of organizationally-mandated content.

5. System modeling - deriving models of the system, often using a notation such as the unified modeling language

Unified modeling language (UML) is a standardized (ISO/IEC 19501:2005), general-purpose modeling language in the field of software engineering. The unified modeling language includes a set of graphic notation techniques to create visual models of object-oriented software-intensive systems.

The unified modeling language was developed by Grady Booch, Ivar Jacobson and James Rumbaugh at rational software in the 1990s. It was adopted by the object management group (omg) in 1997, and has been managed by this organization ever since. In 2000 the unified modeling language was accepted by the international organization for standardization (ISO) as industry standard for modeling software-intensive systems. The current version of the UML is 2.4.1 published by the omg in august 2011. 6. Requirements validation - checking that the documented requirements and models are consistent and meet stakeholder needs 7. Requirements management - managing changes to the requirements as the system is developed and put into use

Requirements management is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. A requirement is a capability to which a project outcome (product or service) should conform.

These are sometimes presented as chronological stages although, in practice, there is considerable interleaving of these activities. Verification and Validation (Validating Requirements)

In software project management, software testing, and software engineering, verification and validation (V&V) is the process of checking that a software system meets specifications and that it fulfills its intended purpose. It may also be referred to as software quality control. It is normally the responsibility of software testers as part of the software development lifecycle.

Validation checks that the product design satisfies or fits the intended use (high-level checking), i.e., the software meets the user requirements. This is done through dynamic testing and other forms of review.

Verification and validation are not the same thing, although they are often confused. Boehm succinctly expressed the difference between them:

 Validation: are we building the right product?  Verification: are we building the product right? According to the capability maturity model (CMMI-SW v1.1),

 Validation: the process of evaluating software during or at the end of the development process to determine whether it satisfies specified requirements. [IEEE-STD-610]  Verification: the process of evaluating software to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. [IEEE-STD-610]

In other words, validation ensures that the product actually meets the user's needs, and that the specifications were correct in the first place, while verification is ensuring that the product has been built according to the requirements and design specifications. Validation ensures that "you built the right thing". Verification ensures that "you built it right". Validation confirms that the product, as provided, will fulfill its intended use. From testing perspective:

 Fault – wrong or missing function in the code.  Failure – the manifestation of a fault during execution.  Malfunction – according to its specification the system does not meet its specified functionality.

Within the modeling and simulation community, the definitions of validation, verification and accreditation are similar:  Validation is the process of determining the degree to which a model, simulation, or federation of models and simulations, and their associated data are accurate representations of the real world from the perspective of the intended use(s).  Accreditation is the formal certification that a model or simulation is acceptable to be used for a specific purpose.  Verification is the process of determining that a computer model, simulation, or federation of models and simulations implementations and their associated data accurately represent the developer's conceptual description and specifications. Software Design (Requirements and Design)

Software design is the process by which an agent creates a specification of a software artifact, intended to accomplish goals, using a set of primitive components and subject to constraints. Software design may refer to either "all the activities involved in conceptualizing, framing, implementing, commissioning, and ultimately modifying complex systems" or "the activity following requirements specification and before programming, as ... [in] a stylized software engineering process."

Software design usually involves problem solving and planning a software solution. This includes both low- level component and algorithm design and high-level, architecture design. Design Concepts

The design concepts provide the software designer with a foundation from which more sophisticated methods can be applied. A set of fundamental design concepts has evolved. They are:

1. Abstraction - abstraction is the process or result of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose. 2. Refinement - it is the process of elaboration. A hierarchy is developed by decomposing a macroscopic statement of function in a step-wise fashion until programming language statements are reached. In each step, one or several instructions of a given program are decomposed into more detailed instructions. Abstraction and refinement are complementary concepts. 3. Modularity - software architecture is divided into components called modules. 4. Software architecture - it refers to the overall structure of the software and the ways in which that structure provides conceptual integrity for a system. A good software architecture will yield a good return on investment with respect to the desired outcome of the project, e.g. in terms of performance, quality, schedule and cost. 5. Control hierarchy - a program structure that represents the organization of a program component and implies a hierarchy of control. 6. Structural partitioning - the program structure can be divided both horizontally and vertically. Horizontal partitions define separate branches of modular hierarchy for each major program function. Vertical partitioning suggests that control and work should be distributed top down in the program structure. 7. Data structure - it is a representation of the logical relationship among individual elements of data. 8. Software procedure - it focuses on the processing of each modules individually 9. Information hiding - modules should be specified and designed so that information contained within a module is inaccessible to other modules that have no need for such information Test Case (Requirements and Test Cases)

A test case, in software engineering, is a set of conditions or variables under which a tester will determine whether an application, software system or one of its features is working as it was originally established for it to do. The mechanism for determining whether a software program or system has passed or failed such a test is known as a test oracle. In some settings, an oracle could be a requirement or use case, while in others it could be a heuristic. It may take many test cases to determine that a software program or system is considered sufficiently scrutinized to be released. Test cases are often referred to as test scripts, particularly when written - when they are usually collected into test suites. Formal Test Cases

In order to fully test that all the requirements of an application are met, there must be at least two test cases for each requirement: one positive test and one negative test. If a requirement has sub-requirements, each sub-requirement must have at least two test cases. Keeping track of the link between the requirement and the test is frequently done using a traceability matrix. Written test cases should include a description of the functionality to be tested, and the preparation required to ensure that the test can be conducted.

A formal written test-case is characterized by a known input and by an expected output, which is worked out before the test is executed. The known input should test a precondition and the expected output should test a post condition. Informal Test Cases

For applications or systems without formal requirements, test cases can be written based on the accepted normal operation of programs of a similar class. In some schools of testing, test cases are not written at all but the activities and results are reported after the tests have been run.

In scenario testing, hypothetical stories are used to help the tester think through a complex problem or system. These scenarios are usually not written down in any detail. They can be as simple as a diagram for a testing environment or they could be a description written in prose. The ideal scenario test is a story that is motivating, credible, complex, and easy to evaluate. They are usually different from test cases in that test cases are single steps while scenarios cover a number of steps of the key. Requirements Analysis Issues (Problem Analysis) Stakeholder Issues

Steve McConnell, in his book rapid development, details a number of ways users can inhibit requirements gathering:

1. Users do not understand what they want or users don't have a clear idea of their requirements 2. Users will not commit to a set of written requirements 3. Users insist on new requirements after the cost and schedule have been fixed 4. Communication with users is slow 5. Users often do not participate in reviews or are incapable of doing so 6. Users are technically unsophisticated 7. Users do not understand the development process 8. Users do not know about present technology This may lead to the situation where user requirements keep changing even when system or product development has been started. Engineer/Developer Issues Possible problems caused by engineers and developers during requirements analysis are:

1. Engineer/developer starts coding/implementation immediately before they really understand the whole requirement from analyst, which usually causes lots of defect fixing or reworking in test/verification phase. 2. Technical personnel and end-users may have different vocabularies. Consequently, they may wrongly believe they are in perfect agreement until the finished product is supplied. 3. Engineers and developers may try to make the requirements fit an existing system or model, rather than develop a system specific to the needs of the client. 4. Analysis may often be carried out by engineers or programmers, rather than personnel with the domain knowledge to understand a client's needs properly. Attempted Solutions

One attempted solution to communications problems has been to employ specialists in business or system analysis.

Techniques introduced in the 1990s like prototyping, unified modeling language (UML), use cases, and agile software development are also intended as solutions to problems encountered with previous methods.

Also, a new class of application simulation or application definition tools have entered the market. These tools are designed to bridge the communication gap between business users and the IT organization — and also to allow applications to be 'test marketed' before any code is produced. The best of these tools offer:

1. Electronic whiteboards to sketch application flows and test alternatives 2. Ability to capture business logic and data needs 3. Ability to generate high fidelity prototypes that closely imitate the final application 4. Interactivity 5. Capability to add contextual requirements and other comments 6. Ability for remote and distributed users to run and interact with the simulation Ishikawa Diagram (Fish Bone Diagram)

Ishikawa diagrams (also called fishbone diagrams, herringbone diagrams, cause-and-effect diagrams, or FISHIKAWA) are causal diagrams created by Kaoru Ishikawa (1968) that show the causes of a specific event. Common uses of the Ishikawa diagram are product design and quality defect prevention, to identify potential factors causing an overall effect. Each cause or reason for imperfection is a source of variation. Causes are usually grouped into major categories to identify these sources of variation. The categories typically include:

1. People: anyone involved with the process 2. Methods: how the process is performed and the specific requirements for doing it, such as policies, procedures, rules, regulations and laws 3. Machines: any equipment, computers, tools, etc. Required to accomplish the job 4. Materials: raw materials, parts, pens, paper, etc. Used to produce the final product 5. Measurements: data generated from the process that are used to evaluate its quality 6. Environment: the conditions, such as location, time, temperature, and culture in which the process operates

Business Requirements

Business requirements are what must be delivered to provide value. Products, systems, software, and processes are the ways how to deliver, satisfy, or meet the business requirements what’s. Consequently, the topic of business requirements often arises in the context of developing or procuring software or other system; but business requirements exist much more broadly. That is, 'business' can be at work or personal, for profit or non-profit.

Confusion arises for three main reasons. (1) A common practice is to refer to objectives, or expected benefits, as 'business requirements.' (2) People commonly use the term 'requirements' to pertain to the features of the product, system, software expected to be created. (3) A widely-held model says these two types of requirements differ only in level of detail or abstraction—wherein 'business requirements' are high-level and vague and decompose into product, system, or software requirements that are detailed.

Such confusion can be avoided by recognizing that business requirements are not objectives but rather meet objectives (i.e., provide value) when satisfied. Business requirements whats do not decompose into product/system/software requirements hows. Rather, products and their requirements represent a response to business requirements—a way how presumably to satisfy the whats. Business requirements exist within the business environment and must be discovered, whereas product requirements are human-defined (specified). Business requirements are not just high-level but need to be driven down to detail. No matter how far down in detail they are driven, business requirements are always business deliverable whats that provide value when satisfied; driving them down to detail never turns business requirements into product requirements.

In system or software development projects, business requirements typically lead to the creation or updating of a product, system, or piece of software. The product/system/software requirements usually consist of both functional requirements and non-functional requirements. Although typically defined in conjunction with the product/system/software functionality (features and usage), non-functional requirements often actually reflect a form of business requirements which sometimes are considered constraints, such as necessary performance, security, or safety that apply at the business level.

Business requirements are often listed in a business requirements document or BRD. The emphasis in a BRD is on what is required, rather than on how to achieve it, which is usually delegated to a systems requirements specification or document (SRS or SRD) or other variation such as a functional specification document. While supposedly describing the product, system, or software from an external perspective, such documents often define the product/system/software requirements in the context of a chosen technology (a solution approach or architecture). Further confusion often arises when people writing BRDS do not understand the distinctions; and consequently many BRDS actually describe requirements of a product, system, or software. Business Process Modeling

Business process modeling (BPM) in systems engineering is the activity of representing processes of an enterprise, so that the current process may be analyzed and improved. Bpm is typically performed by business analysts and managers who are seeking to improve process efficiency and quality. The process improvements identified by bpm may or may not require information technology involvement, although that is a common driver for the need to model a business process, by creating a process master. Business process modeling results in the improvement of the way tasks performed by the business. They can pick up errors or cons about the way processes are currently being performed and model an improved way of carrying out these processes. Business Model

A business model is a framework for creating economic, social, and/or other forms of value. The term 'business model' is thus used for a broad range of informal and formal descriptions to represent core aspects of a business, including purpose, offerings, strategies, infrastructure, organizational structures, trading practices, and operational processes and policies.

In the most basic sense, a business model is the method of doing business by which a company can sustain itself. That is, generate revenue. The business model spells-out how a company makes money by specifying where it is positioned in the value chain. Business Process

A business process is a collection of related, structured activities or tasks that produce a specific service or product (serve a particular goal) for a particular customer or customers. There are three main types of business processes:

1. Management processes that govern the operation of a system. Typical management processes include corporate governance and strategic management. 2. Operational processes that constitute the core business and create the primary value stream. Typical operational processes are purchasing, manufacturing, marketing, and sales. 3. Supporting processes, that support the core processes. Examples include accounting, recruitment, and technical support.

A business process can be decomposed into several sub-processes, which have their own attributes, but also contribute to achieving the goal of the super-process. The analysis of business processes typically includes the mapping of processes and sub-processes down to activity level. A business process model is a model of one or more business processes, and defines the ways in which operations are carried out to accomplish the intended objectives of an organization. Such a model remains an abstraction and depends on the intended use of the model. It can describe the workflow or the integration between business processes. It can be constructed in multiple levels.

A workflow is a depiction of a sequence of operations, declared as work of a person, of a simple or complex mechanism, of a group of persons, of an organization of staff, or of machines. Workflow may be seen as any abstraction of real work, segregated into work share, work split or other types of ordering. For control purposes, workflow may be a view of real work under a chosen aspect. Artifact-Centric Business Process

The artifact-centric business process model has emerged as a new approach for modeling business processes, as it provides a highly flexible solution to capture operational specifications of business processes. It particularly focuses on describing the data of business processes, known as “artifacts”, by characterizing business-relevant data objects, their lifecycles, and related services. The artifact-centric process modelling approach fosters the automation of the business operations and supports the flexibility of the workflow enactment and evolution. Business Use Case Model (Business Use Cases)

A primary purpose of the model of business use cases and actors is to describe how the business is used by its customers and partners. Activities that directly concern the customer, or partner, as well as supporting or managerial tasks that indirectly concern the external party can be presented.

The model describes the business in terms of business use cases, which correspond to what are generally called "processes".

Actors and use cases at the check-in counter. Different Categories of Business Use Cases

When looking at the activities in a business you will be able to identify at least three categories of work corresponding to three categories of business use cases:

1. First, there are the commercially important activities, often called business processes. 2. Second, there are a lot of activities that are not that commercially important, but have to be performed anyhow to make the business work. Systems administration, cleaning and security are typical examples. The business use cases are of a supporting character. 3. Third, there is management work. Business use cases of management character shows the type of work that affects how the other business use cases are managed and the business’ relationships to its owners.

Typically, a management type of business use case describes in general the relationships between the ceo, and people who work in the business use cases. It also describes how business use cases are developed and "started" (instantiated). Note that what you regard as a core business use case can sometimes be a supporting business use case in another business. For example, software development is a core business use case in a software development company, while it would be classified as a supporting business use case in a bank or an insurance company.

At a restaurant, the core business use cases are marketing and serving dinner, and the supporting business use case is purchasing supplies. Business Process Model and Notation

Business process model and notation (BPMN) is a graphical representation for specifying business processes in a business process model. It was previously known as business process modeling notation. Elements

BPMN models consist of simple diagrams constructed from a limited set of graphical elements. For both business users and developers, they simplify understanding business activities' flow and process. BPMN's four basic element categories are: 1. Flow objects: Events, activities, gateways 2. Connecting objects: Sequence flow, message flow, association

3. Swim lanes: Pool, lane

4. Artifacts: Data object, group, annotation

These four categories enable creation of simple business process diagrams (BPDS). BPDS also permit making new types of flow object or artifact, to make the diagram more understandable. Flow Objects

Flow objects are the main describing elements within BPMN, and consist of three core elements: events, activities, and gateways. Event

An event is represented with a circle and denotes something that happens (compared with an activity, which is something that is done). Icons within the circle denote the type of event (e.g., an envelope representing a message, or a clock representing time). Events are also classified as catching (for example, if catching an incoming message starts a process) or throwing (such as throwing a completion message when a process ends).

1. Start event

Acts as a process trigger; indicated by a single narrow border, and can only be catch, so is shown with an open (outline) icon. 2. Intermediate event

Represents something that happens between the start and end events; is indicated by a double border, and can throw or catch (using solid or open icons as appropriate). For example, a task could flow to an event that throws a message across to another pool, where a subsequent event waits to catch the response before continuing. 3. End event

Represents the result of a process; indicated by a single thick or bold border, and can only throw, so is shown with a solid icon. Activity

An activity is represented with a rounded-corner rectangle and describes the kind of work which must be done.

1. Task

A task represents a single unit of work that is not or cannot be broken down to a further level of business process detail without diagramming the steps in a procedure (which is not the purpose of bpmn) 2. Sub-process

Used to hide or reveal additional levels of business process detail. When collapsed, a sub-process is indicated by a plus sign against the bottom line of the rectangle; when expanded, the rounded rectangle expands to show all flow objects, connecting objects, and artifacts.

Has its own self-contained start and end events; sequence flows from the parent process must not cross the boundary. 3. Transaction

A form of sub-process in which all contained activities must be treated as a whole; i.e., they must all be completed to meet an objective, and if any one of them fails, they must all be compensated (undone). Transactions are differentiated from expanded sub-processes by being surrounded by a double border. 4. Call activity

A point in the process where a global process or a global task is reused. A call activity is differentiated from other activity types by a bolded border around the activity area. Gateway

A gateway is represented with a diamond shape and determines forking and merging of paths, depending on the conditions expressed.

1. Exclusive Used to create alternative flows in a process because only one of the paths can be taken, it is called exclusive 2. Event based The condition determining the path of a process is based on an evaluated event. 3. Parallel Used to create parallel paths without evaluating any conditions. 4. Inclusive Used to create alternative flows where all paths are evaluated. 5. Exclusive event based An event is being evaluated to determine which of mutually exclusive paths will be taken 6. Complex Used to model complex synchronization behavior 7. Parallel event based Two parallel process are started based on an event but there is no evaluation of the event Connecting Objects

Flow objects are connected to each other using connecting objects, which are of three types: sequences, messages, and associations.

1. Sequence flow

A sequence flow is represented with a solid line and arrowhead, and shows in which order the activities are performed. The sequence flow may also have a symbol at its start, a small diamond indicates one of a number of conditional flows from an activity, while a diagonal slash indicates the default flow from a decision or activity with conditional flows. 2. Message flow

A message flow is represented with a dashed line, an open circle at the start, and an open arrowhead at the end. It tells us what messages flow across organizational boundaries (i.e., between pools). A message flow can never be used to connect activities or events within the same pool. 3. Association

An association is represented with a dotted line. It is used to associate an artifact or text to a flow object, and can indicate some directionality using an open arrowhead (toward the artifact to represent a result, from the artifact to represent an input, and both to indicate it is read and updated). No directionality is used when the artifact or text is associated with a sequence or message flow (as that flow already shows the direction).

Swim Lanes

Swim lanes are a visual mechanism of organizing and categorizing activities, based on cross functional flowcharting, and in BPMN consist of two types:

1. Pool

Represents major participants in a process, typically separating different organisations. A pool contains one or more lanes (like a real swimming pool). A pool can be open (i.e., showing internal detail) when it is depicted as a large rectangle showing one or more lanes, or collapsed (i.e., hiding internal detail) when it is depicted as an empty rectangle stretching the width or height of the diagram. 2. Lane

Used to organize and categories activities within a pool according to function or role, and depicted as a rectangle stretching the width or height of the pool. A lane contains the flow objects, connecting objects and artifacts. Artifacts

Artifacts allow developers to bring some more information into the model/diagram. In this way the model/diagram becomes more readable. There are three pre-defined artifacts and they are: 1. Data objects: data objects show the reader which data is required or produced in an activity.

2. Group: a group is represented with a rounded-corner rectangle and dashed lines. The group is used to group different activities but does not affect the flow in the diagram.

3. Annotation: an annotation is used to give the reader of the model/diagram an understandable impression.

Activity Diagram (UML Activity Diagrams)

Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration and concurrency. In the unified modeling language, activity diagrams are intended to model both computational and organizational processes (i.e. Workflows). Activity diagrams show the overall flow of control.

Activity diagrams are constructed from a limited number of shapes, connected with arrows. The most important shape types:

1. Rounded rectangles represent actions; 2. Diamonds represent decisions; 3. Bars represent the start (split) or end (join) of concurrent activities; 4. A black circle represents the start (initial state) of the workflow; 5. An encircled black circle represents the end (final state). Arrows run from the start towards the end and represent the order in which activities happen.

Hence they can be regarded as a form of flowchart. Typical flowchart techniques lack constructs for expressing concurrency. However, the join and split symbols in activity diagrams only resolve this for simple cases; the meaning of the model is not clear when they are arbitrarily combined with decisions or loops.