Yet Another Workflow Language - Prioritization Techniques and Organization of the Requirements - Case Study Example

YAWL Foundation

Yet Another Workflow Language (YAWL) is a workflow system that bases on workflow patterns with powerful and complex language for managing composite data transformations and full integration with organizational resources and external Web services. YAWL has a powerful process specification language for native data handling through XML, Schema, XPath and XQuery and allows for automated verification. YAWL Foundation also gives comprehensive support that captures resourcing requirements, and it evolves over time-to-time to satisfy the new and changing requirements. However, the YAWL tasks can allow mapping into human participants, Web Services, Java classes and external applications giving it robust flexibility support to Worklets approach. The primary significance of YAWL Foundation is that it allows for the redesigning of an already identified website thereby enhancing user experience and raise its market share.

Requirements Breaking

There are three primary levels of requirements in YAWL Foundation, which includes Business, Stakeholder and Functional requirements of which is at the same level with non-functional requirements. The business requirement is the first level of the YAWL Foundations, which contains its objectives and the goals while the second level is Stakeholder requirements comprising the texts, tables, models and the use cases. However, stakeholder also includes the issues, constraints and the risks in the workflow, which is related to the non-functional requirements. The last level of the requirements is the Functional requirements which contains the specifications of the requirements alongside the non-functional. In requirements analysis, there is also a development of the models of the current state of the organization which formalize the solution scope with stakeholders and establishing the current state’s improvements.

Logically, the breakdown of the requirements into three sections results into inputs, task and outputs sections with each section categorized further into smaller subdivisions. Inputs sub-section comprises the business case, business needs, organizational process assets, requirements plan management, solution scope, stakeholder lists, roles, responsibilities, and concerns. Input requirement involves the founder stakeholders who work with the developers enable the success of elicitation activities. Task section is where prioritization of requirements takes place followed by the organization, specification and defining the assumptions and constraints. However, the last stage in task requirements is the verification and the validation of the requirements. Ultimately, in output requirements contains the stakeholder communication requirements for the business analysis activities, the format, contents, and level of detail. Also, in output requirements, there is the need for collecting, distributing, accessing and updating information.

Output requirement involves the use of standard and templates that contain presentation formats and requirements documentation templates for the business analysis. The aim of output requirement is to identify new capabilities that can do business to meet its needs through cross-evaluation of the capability gaps. Stakeholders’ lists, roles, and responsibilities make it easy to recognize the speaker who will need the information concerning the business analysis process and how to use the information. Elicitation assists in extraction of specific project requirements from the stakeholders reflecting the actual business when redesigning a website. Moreover, elicitation also enhances the organization and scheduling of all the needed resources for conducting the elicitation processes. In some cases, conduction of interview in formal and informal setting helps in a provision of information from a group of people through asking questions and recording the responses. The technique is purposeful in that it elicit information concerning the overall goals and objectives and for the website redesign.

(Retrieved from, http://iiba.ru/wp-content/uploads/2015/07/7_Requirements_Analysis_and_Design_Definition_Input_Output_Diagram.png.)

Prioritization Techniques

Prioritization of the requirement determines the relative importance of requirements based on the qualification of the value, risk, and the implementation difficulties. It also decides which requirement to be first implemented and which one is a target for further analysis. Prioritization helps in decision making regarding products planning for a single or multiple releases and in complex decision problems. However, prioritization is done by the business value which is common when enhancing the existing solutions and the about the organization. It is also done by technical risks, implementation difficulty, a likelihood of success, urgency, regulation compliance and finally on the relationships with other requirements. The methods for prioritization depends on the overall objectives and constraints. Various techniques can be used to prioritize requirements which include MoSCoW Analysis, general techniques, Timeboxing/ Budgeting and Voting.

The general technique involves the decision analysis for high-value requirement identification. It’s also involved in risk analysis where the requirement that is seen as a risk may need to be implemented first. The general technique is important in that the risk may fail the project if it has invested to some extent. The MoSCoW analysis divides the requirements into four categories which are Must, Should, Could and Won’t (Hailes&Newton, 2014). For instance, Must describes the requirement that must be satisfied in the final solution for the solution to be regarded as the success. Should category represent the high-priority item that should be included in the solution if it is possible. However, could category describe the requirement that is considered desirable but not necessary, so that it can be included only if the resources and time permit. The won't finally represent the requirement that stakeholders have agreed will not be implemented in due time but may be considered for the future.

The third technique for prioritization is Timeboxing or budgeting technique. The method prioritizes requirements for implementation depending on the allocation of a fixed resource and on the quantity of work that the project team can deliver in a set period. It’s mostly used when a fixed deadline must be met or for the solution that is enhanced on a frequent and regular basis. In budgeting technique, it’s subdivided into (all in), which is important to start with assigned duration or cost followed by the removal of the requirements to meet the budget date limit. The careful budgeting requires the identification of high priority requirements added to the calendar or budget to meet the calendar dates or the budget limit.

The fourth method of prioritization is the voting where there is the allocation of a fixed quantity of resources such as votes, play money and other tokens to each participant for them to distribute among proposed features or requirements. The requirement to receive the most resources are the ones that will be investigated or implemented first. Besides the four prioritization techniques, there are other methods of analysis such as the Decision analysis which is based on the knowledge of the values, goals, objectives, uncertainty and the consequences of each action. Risk analysis method depends on the tolerance, assessment probability, and impact and also the response.

The checklist of the prioritization involves making the prioritization the common practice, involvement or relevant stakeholders, applying quantification formula and document approach as the requirements management plan outlines. In prioritization, the stakeholders include the project manager, the sponsor, the implementation subject matter experts and the domain subject matter experts. The prioritized requirement will be assigned an attribute that describes its relative importance to the stakeholders and the organization.

Organization of the Requirements

The main aim of organizing the requirements is to develop a set of views of the requirements that are complete, consistent, and comprehensive and understood by all stakeholders’ perspectives. However, the main objectives of organizing the requirements include giving a knowledge of which models are suitable for the solution scope and the business domain. Secondly, the organization of requirements helps to identify the interrelationships between the models and their dependencies. For that reason, the related requirements must also clearly depict the inherent relationships between the requirements. Moreover, the solution scope of the inputs must be sufficient to describe the solution scope fully from all needed perspectives.

There are many elements of requirements organization which include following the organization’s standards or choosing appropriate standard. Other elements of the organization requirement include the use of natural language and terminology common to the organization and also the document dependencies and interrelationships between the requirements are important in business analysis. The production of a consistent set of models and templates to the document the requirement is also another element of an organization of requirements. Finally, the use of consistent definitions for each type of requirement is also important(Hailes & Newton, 2014).

(Retrieved from, http://image.slidesharecdn.com/babokv2requirementsanalysisknowledgea)

Abstraction Levels

There are various levels of abstraction that can be used to articulate requirements, which shows how much the details are expressed which vary when describing the requirements. Although there can be difficulties when deciding on the level of abstraction which depends on the number of requirements and their complexity. The levels of abstraction depend on the audience and the enterprise architecture standards or methodologies which informally designate a set of requirements as high or low level depending on the level of the detail included. Different stakeholders determine the different perspectives of defining business requirements.

Models of Selection

The business analysts must identify which types of the models will be needed to draw the solution scope and fit the informational needs of stakeholders, which may vary over time. Models abstract and simplify the reality in their specific ways because they may need multiple models to represent a situation or a solution. Each model corresponds to the different view of the reality of the business domain. However, there is a necessity of developing multiple models using different modeling techniques to analyze completely and document requirements. Several modeling concepts are present that are relevant to the business analysis. These modeling concepts include the user classes, profiles or roles which describe the people who directly interact with the solution. For instance, each role groups together people with similar needs, expectations, and goals, where each role corresponds to stakeholders hence should be implemented as a source of requirement.

BA models work in different ways in that BPM captures the process then identifies roles, events and use the cases identity goals to capture the processes and the stakeholders. Concepts and relationships which correspond to places, people, things or entities related to the business domain and what the relationships they have with other concepts. Events are also model selection techniques which are a request to business systems to do things such as a customer placing order or a manager seeking a report. In most cases the organizations react to the events in preplanned ways which trigger or affect the business.

Processes are the process of repeatable activities carried out within an organization which ranges from simple to complex. The method describes who and what has to be involved in adequately responding to an event and how people in the enterprise collaborate to achieve a goal. Rules is another modeling element that is used by organizations to enforce goals and make decisions that determine operations and priorities. The rules also identify when the information associated with an entity may change, evaluating the values of information which are valid and how to make decisions in the process. It's advisable to choose a set of modeling methods that meet the informational needs of the stakeholders and allow description of all the above elements of model selection to cover the business domains fully.

Techniques for Model Selection

The techniques for model selection include business rules analysis which may be separated from other requirements for implementation and management of the business rules engine. Data flow diagram is another technique which shows how information flows through the system while data modeling reports the concepts and relationships relevant to the business domain(Hailes & Newton, 2014). Thirdly, functional decomposition breaks down an organizational unit and product scope into its parts, where each part has its sets of requirements. There is also process modeling as a technique for model selection. In this case, the requirements may be organized around relevant processes. On the other hand, scope modeling is where the requirements may be organized based on the solution components with their relationship. Scenarios and User cases as well describe the requirement that supports the individual goals of each actor or the response triggering event. Organization modeling describes the various organizational unit, stakeholders, and their relationships. Consequently, user stories and state diagrams are also used to describe the stakeholder objectives that the solution will support.

Specification and Model Requirements

The main purpose of the specification is to analyses the expressed stakeholder desires and the current state of the organization using a combination of textual statements, diagrams, formal models, and matrices. Specification models are critical in studying the organization’s function and giving insights into improvements opportunities. Moreover, they were helping to develop and implementations of solutions, facilitation of communication among stakeholders and enhancing compliance with the contracts and regulations. Specification of models also supports training activities, and knowledge the management and the specifics of this business analysis is highly dependent on the methods used for specifying and modeling requirements

Elements of Specifying and Model Requirements

Among the elements include the textual requirement that must describe the capabilities of the solution and any conditions that must exist to operate the requirement. Guidelines for writing textual requirement include the use of consistent terminology, which is familiar to the stakeholders. Also, avoiding complicated conditional clauses but expressing the requirement as a verb or a verb phrase. It’s also important to show one requirement at a time and writing who is responsible for fulfilling the requirement(Hailes & Newton, 2014).

The second element of a model requirement is matrix documentation, which provides a uniform structure in a form of a table showing attributes that apply to each and every entry. Matrices are always used for traceability and prioritization of requirement to each other from test cases by mapping to goals and objectives, grouping requirement and gap analysis.

(Retrieved from, https://encrypted-tbn3.gstatic.com/images?)

Another element is modeling formats which are a simplified representation of a complex reality that is useful for understanding the reality and making decisions regarding it. Such models can use graphs or texts or both, where graphical models are known to be diagrams. The models, however, can be formal or informal by following rules and semantics which are meaningful to the audiences. The models can be used to describe business processes, thoughts and action flow, business rules and logics, components and relationships and finally categories and hierarchies.

Assumptions and Constraints

The main purpose of identifying assumptions and constraints is to determine the other factors apart from the requirements that may change viable solutions. Assumptions are considered to be true but have not been confirmed and change all aspects of the project hence risky if not proven right. Perhaps the business analysts determine the assumptions and document them by trying to confirm the accuracy of the assumptions. They also manage the risks related to the ability of a solution to meet they business need. The assumptions also provide knowledge on how desired outcomes are likely to be achieved. On the other hand, constraints are the restrictions or limitations on possible solutions. The business analysts are responsible for documenting any restriction or limitation to a solution design, construction, testing, validation, and deployment. Moreover, they provide an aspect to the current state or planned future state that may be constant. So the constraints are rendered to the project team to enlighten them on which options they would always be permitted to consider are not available. Constraints, therefore, need to be carefully examined to ensure that they are accurate and justified.

Verifying Requirement

Verification of requirement aims at ensuring that the requirement and the models meet the necessary standard of quality to allow them to be efficiently used to guide further work. The features of a requirement quality include cohesiveness, where the requirements sources relate to only one thing and completeness of the requirement ensures that there is no contradiction but having the same level of details. Also, a justified requirement should be consistent, correct, modifiable and feasible too. So it is important to check for completeness within each requirements model and compare each prepared requirements against all other requirements models(Hailes & Newton, 2014). Also, verify that the terminologies used in expressing the requirements model are understandable to the stakeholder and consistent with the use of those terms within the organization. Hence, if the requirement cannot be verified, it cannot also be successfully be implemented so it cannot meet the business need.

Validation Evidence

Validation is important in that it ensure that all requirements support the delivery of value to the business by fulfilling its goals and objectives and therefore must meet the stakeholder need. The process of validation of a requirement starts by the identifications of assumptions, defining the level of measurable evaluation criteria, determining business value and finally determining dependencies of benefits realization. Ultimately, the acceptance criteria are the quality metrics that must be met to achieve acceptance and validation of a requirement by the stakeholder.

Reference

Hailes, J., & Newton, S. (2014). Business Analysis Based on BABOK® Guide Version 2: A pocket guide. Zaltbommel: Van Haren Publishing. Print.