Business Design

Visualising requirements fosters a common understanding of a project

Statements like “I understood that differently” or “That’s not what I meant” are familiar to anyone who works on software projects. After all, software is typically a complex and dynamic system where it’s difficult to envision all possible states, despite the collective imagination of all stakeholders.

Visualising requirements – known as business design – helps significantly reduce misunderstandings caused by unspoken expectations. This is of paramount importance since the cost of implementing changes to software increases significantly the later the need for these changes is identified. Moreover, such instances often result in project delays and hamper the timely completion of the software.

This does not align well with limited budgets and tight schedules, and is no longer sustainable for companies striving to thrive in fast-paced markets.

The pictures used in software development are models that provide a visual representation of requirements. The key is to present the subject matter in a simplified manner so that it can be understood quickly by your stakeholders while still encompassing all relevant aspects.

A wide variety of modeling languages and notations are available nowadays and serve as tools for visualising requirements. When it comes to selecting the best diagram types for your project, we don’t believe in being dogmatic or blindly following the latest trends. We will consider any type of diagram as long as the following question can be answered affirmatively:

Is it capable of describing the subject matter to the relevant stakeholders in a comprehensive yet easily understandable manner?

doubleSlash is your expert for professional business design

Various scenarios need to be modeled in a software project, and choosing the most accurate representation is crucial to ensure that all parties can understand the intended functionality of the software quickly and comprehensively.

• Business processes
  An IT system usually represents one section of a broader set of business processes. Our extensive experience has shown that Business Process Model and Notation (BPMN) is extremely well-suited to the graphical representation of business processes and it is a widely accepted model among our customers. In cases where only an initial, high-level depiction of business processes is required, simple block arrows can be used.

• Use Cases
  Use cases describe software functions from a user's point of view. They help to understand which specific functions the user expects from the software. We use standard UML graphical and tabular notation to describe use cases.

• Domain model
  Domain models, or domain-oriented data models, describe the business objects used within business processes and use cases. Traditionally, these domain models are represented using entity-relationship (ER) models. Our experience of using UML class diagrams for modeling business objects has always been very positive, since they offer considerably more syntactic flexibility.

• State model
  Depending on the business context, business objects can transition between different states. Let’s take requests, for example, which can be ‘submitted’, ‘accepted’, ‘rejected’ or ‘withdrawn’. State models (also known as state automata or state machines) help to clearly represent the states and possible state transitions.

• UX Design
  UX Design is because of paramount important since it serves as a direct window between the software and the end user. Our tried and tested approach to UX design involves two steps. In the first step, we create wireframes to give the customer a first basic impression of the user interface. Once the customer is happy with the wireframes, we proceed to the second step which involves developing the actual screen design.