Discoveryphase

Discovery phase is divided into stages (artifacts), at each of which the right questions are asked, solutions are proposed and the right implementation, taking into account all the nuances, is determined specifically for this project. After each stage, a separate artifact with fixed requirements is provided. Depending on the characteristics of the project, some of the optional artifacts can be skipped.

As a result of the Discovery phase the amount of work, technology stack, methodology of the project, the team needed, the methods and timing of its implementation become clear.

In order to successfully complete the Discovery Phase, the following specialists are needed:
1. Stakeholder (from the customer side)
2. Analyst
3. UI / UX Designer
4. Manager
5. Senior developer

All of them are on our staff.

In contrast to the usual discovery phase, ours can include up to 12 phases, which allows you to more thoroughly identify functional requirements, business processes and eliminate errors during project implementation.

Learn more about the artifacts of the Discovery Phase at our company:
1. Mind Map: Visualizing requirements in a relationship diagram helps you understand the scope of the project, the number of roles and modules, and determine the boundaries of the future project. It makes it easier to see immediately unseen tasks, build relationships, track inconsistencies and duplicate requirements.
2. BPMN diagram: Formalizing requirements in this form helps us clearly understand the interaction between users and each other and see possible white spots that in other artifacts we simply could not notice. At this stage it is explicitly stated exactly how the system works: where the data appears in it, the starting points for actions and processes, how exactly the user arrives to the goal and whether the path is not too long.
3. User Story/Functional Requirements: A brief description of a function or functionality from the end user's perspective, detailing what needs to be implemented on the project.
4. Non-Functional Requirements: Defines the quality attributes that a software system must have, such as performance, security, scalability, and usability.
5. Request-Response Model: Client-server communication model, a document specifying the requirements to integration with third-party systems and services: what exactly the system under development should request from the service (what fields) and what we will get from it in response.
6. Bottleneck analysis: Detecting bottlenecks and possible solutions. Bottlenecks can be considered from purely business-oriented to purely technical. In special cases, a symbiosis of both. For example, payment systems.
7. Wireframes: A low-fidelity representation of the layout, design and functionality of a user interface used to understand how the entire project will be navigated.
8. Design Concept: The design and rendering of several key design elements that reflect the project's underlying idea, key design components, and subsequent inheritable styling.
9. Clickable Prototype: Interactive, high-fidelity simulations of the final product used to test and validate the user experience.
10. Presentation: A visual representation of project goals, progress and results used to communicate the project to stakeholders. We can include a pool of work to help the customer present the idea to stakeholders.
11. Project Plan: A plan that describes the project goals, objectives, resources and timelines, used to manage and track progress. It is created to give an understanding of the required development resources and to translate deadlines for accomplishing tasks to the customer.
12. Rough estimate for development: A preliminary estimate of the time and cost required to develop a software system, used to plan and allocate resources.

Each of the artifacts is detailed to the extent necessary to accomplish the Discovery Phase tasks. For example, the User Story/Functional Requirements may write a detailed TOR, while the Design Concept may do the entire design.