From Customer Challenges to a Product: A Guide for Process-Driven Requirements Engineering for Beginners
Today, building large-scale inter-organizational software systems comes with challenges. Solution architects have to create the right solutions for existing problems in a way that the user of the system gains utility. This article introduces the FASD approach. FASD is process-driven and can be used by technical and non-technical solutions architects. FASD was created based on academic and industry experiences within our JadenX client projects. It supports its users in process and software design as well as with management challenges like project scoping.
From Complex Problems to Easy Solutions: Requirements Engineering
Building large-scale enterprise systems today is challenging. The systems we engage with today span across different companies involve different systems and many interactions between them. For solution architect the overall challenge is to create the right solutions for existing problems in a way the the user of the system gains utility. Requirements Engineering focuses on eliciting requirements from the system’s possible users. These gathered requirements can be used as the input for many different software system design tasks.
This article introduces FASD (Fast Guide to Process-driven Solution Design), our process-driven approach to fast requirements engineering. FASD is a combination of existing approaches that target technical and non-technical requirements engineers, focusing on eliciting requirements quickly, structuring them, and deriving system design decisions from them. FASD is based on experience that we had while dealing with complex software systems. The approach can be used for status quo assessment, interaction design, and the precise scoping of large projects. Thus, FASD aims to provide insights for technical tasks (software design, interface design) and non-technical tasks (process design, project management).
FASD’s Ingredients
The users of the FASD approach need to have a basic understand of the concepts of design thinking and business process modeling. The following sections give a short overview on the two concepts.
Design Thinking and User Personas
Design thinking is a practical and creative problem-solving approach. Initially, design thinking evolved from a combination of different fields, including architecture, engineering, and business. Conceptually, it is based heavily on the methods and processes that designers use. Design thinking is domain-independent and can be applied to any application area. The design thinking paradigm is highly user-centric. The approach seeks to understand people’s needs and come up with effective solutions to meet those needs.
In general, the design thinking methodology has many different activities and tools. They all focus on getting a better understanding of customers or users. One major activity that FASD uses is the creation of personas. A persona is a fictional character that represents a type of customer or user of a service or product. The creation of a persona is based on insights that we learn about real customers and users. They are an abstraction of the “typical user’’ and include the characteristics that many users share in common. The creation of user personas is highly research-based. It is focused on understanding the customers’ and user’s needs, behaviors, experiences, and goals. In FASD, we will use the creation of user personas as one of the key initial steps.
Business Process Modelling
The second ingredient of the FASD method are business process models. FASD is inherently process-centric. A business process is a set of activities executed jointly to achieve a specific business goal. Process models are an abstraction of a business process that can be illustrated visually.
Conceptionally, a business process model consists of nodes and edges. Nodes represent models for activities, events, and gateways in a process. Edges express sequence or message flows. Activities represent units of work in a process. These units of work may be tasks executed by automated systems, manual tasks, or whole subprocesses. Events illustrate the reaching of a specific point of interest. Examples of that are start, end, or failure events. Gateway elements such as splits or joins express decision points or parallel workflows. Edges are the connection between different nodes. They can represent sequence flows (within one organization) or message flows (across different organizations).
Many business process modeling languages enable the user to illustrate different organizations or organizational units using lanes or pools. Processes with different organizations collaborating in a joint workflow are called collaborative business processes.
The Business Process Modeling Notation (BPMN) is a standardized modeling language. The FASD method advices using BPMN, even though it is generally possible to use other process modeling languages. This article is not a BPMN tutorial. If you want to get into BPMN, we recommend this book.
The FASD Method
This section introduces the general FASD method as illustrated in the figure below.
FASD aims to bridge technical and non-technical roles in both situations to get a full end-to-end solution. FASD consists of three main phases.
Phase 1 aims to establish the As-Is situation and defines the goals. Therefore, the FASD method models personas, identies roles, and models the initial process. With that basis, mission statements and high-level focus points are set. After a general overview of the As-Is situation has been established, non-functional constraints are identified. These non-functional constraints serve as the fundamental requirements for the To-Be process design, performance, and costs.
In general, phase 2 is carried out by non-technical solution architects. These non-technical solution architects elicit the requirements of the new system users and their organization in interview-style engagements.
Phase 2 is concerned with designing the solution. Therefore, first, the To-Be process and the system functions therein are modeled. This modeling requires a feedback loop between the technical- and non-technical solution architects, users, and their organizations. Designing the solution is inherently iterative.
After the process design, system interactions and interfaces are designed. For the system interactions, engagement between solution architects and users is required. Technical solution architects create the drafts for the technical interfaces to define how the organization’s current systems are integrating with the new solution. At the end of phase 2, an effort estimation for the different system parts is conducted.
Phase 3 aims to finalize the initial scope of the implementation phase. This phase includes the prioritization of features and planning of resources and time.
In general, FASD can be applied to any project management paradigm. In a waterfall model, solution architects would go over the model once. In an agile approach, FASD can be used iteratively to design solutions for problems.
Where to go from here
This article introduced you on a high level how to FASD apporach works. If you want to know more, get deeper, or do some training, get in contact with us. Let’s talk and we can see how we can help you.
