85 lines
5.9 KiB
Markdown
85 lines
5.9 KiB
Markdown
# A Guideline for Discovery Phase
|
||
|
||
When you start working on a service in the discovery phase, you can easily get lost if the service has many features. However, the discovery phase is an important and sensitive phase of the development process. Skipping this phase can lead to incomplete services in addition to new bugs and unreported features during the development phase. However, not doing the requirement gathering and documentation in the right ways would lead to the same consequences. You need to take your time researching all the requirements, and do not leave any questions unanswered.
|
||
|
||
So, how to collect the requirements in the right way? How to cover every corner of the service? Sometimes you need to dig deeper into the services and ask questions that the client can not remember for the time being.
|
||
|
||
## How long does the discovery phase take?
|
||
|
||
It usually takes 2 to 8 weeks, but it can take more than that, depending on the project. However, in the discovery phase you should take your time with researching the service. Because, it is crucial to understand the service very well, and collect the right requirements.
|
||
|
||
## Where to start your research?
|
||
|
||
Follow these steps throughout your research. While going through the steps, do not assume any detail of the service and skip steps.
|
||
|
||
### 1\. Find the problem
|
||
|
||
At the very beginning of the research, you must know what is the problem with the current service, then ask for details of the service. Knowing what the problem is will help in understanding the situations your client is going through, and it will lead to a better solution.
|
||
|
||
### 2\. Define the objectives of this service
|
||
|
||
Now that you know what is the problem of the current service or the client is going through, you have to define what are the objectives for this project. The objectives later can be used as a metric for how far you have come to solve the problem in the discovery phase. Later on in the development can also be used to see if the service is achieving its purpose.
|
||
|
||
### 3\. Find the stakeholders
|
||
|
||
Find out who all the users of this service are? What are their roles? And What is their responsibilities? Finding all the stakeholders is important, but finding the right ones will lead you to a better understanding of the service. Who are the right stakeholders? Users who are heavily involved in the service, the ones that use the service almost all the time and know exactly how it works. These stakeholders need to be interviewed in detail, because they have faced every disadvantage and advantage point of the service.
|
||
|
||
#### Key points
|
||
|
||
- Who uses this service?
|
||
|
||
- Find the right stakeholders (The one who uses the service the most)
|
||
|
||
- What is their role in the service?
|
||
|
||
- What is their responsibility?
|
||
|
||
- Build a [mind map](documentationGuideline.md#mind-mapping-guideline) representing all the stakeholders
|
||
|
||
### 4\. Research the service
|
||
|
||
After finding all the stakeholders, you need to go through the service with them, and ask questions on any actions you don't understand. Especially researching the right stakeholders, you need to take your time with them, and ask detailed questions. It is important to take those requirements from the stakeholders and turn them into user stories, because they are fresh in your mind, you know why these requirements are needed, and how important they are. Use the template for user story in the [documentation guideline](documentationGuideline.md). After you write all the user stories, build a flowchart representing the workflow of the current service, and try to re-engineer the workflow until you come up with a workflow that meets the objective of this service. When you find a solution for the current service workflow, design a new flowchart according to the [documentation guideline](documentationGuideline.md) for the newly proposed workflow. While re-engineering the current workflow, you have to take the KRG rules and regulations into consideration that will be mentioned in the next step.
|
||
|
||
#### Key points
|
||
|
||
- How does the old service work?
|
||
|
||
- How do they want the new service to be?
|
||
|
||
- What are the tasks of the users in the current service?
|
||
|
||
- What will be the tasks of the users in the proposed service?
|
||
|
||
- What is the purpose of each task?
|
||
|
||
- Turn the requirements into [user stories](documentationGuideline.md#user-stories-guideline)
|
||
|
||
- Build a [flowchart](documentationGuideline.md#flowchart-diagram-guideline) for the workflow of the current and proposed service
|
||
|
||
### 5\. Find the KRG rules and regulations related to this service
|
||
|
||
It is important to understand the legislation for building this service, so that you understand why this service exists, and why it is important to be digitized.
|
||
|
||
#### Key points
|
||
|
||
- What are the KRG rules and regulations related to this service?
|
||
|
||
- Which of these rules will be removed or amended when changing to the proposed service?
|
||
|
||
- Will there be any new KRG rules and regulations added to the proposed service?
|
||
|
||
- How do the rules and regulations affect the proposed service?
|
||
|
||
- Why do these rules and regulations exist?
|
||
|
||
### 6\. Share the document with the clients
|
||
|
||
After you have done your research and documented all the requirements, share all the documentations with them. It is important that you go through the documentation again with the clients, to make sure that you have everything documented and all of them are correct.
|
||
|
||
#### Key Points
|
||
|
||
- Go through the flowchart with the stakeholders
|
||
|
||
- Do not make any assumptions in the requirements, make sure the requirements are correct
|
||
|
||
Now that you have been through all the steps, you are ready to prepare the final document using this [template](https://docs.google.com/document/d/1FZqdr-2xK0YuyiWsdvuDQHNCscFL4xJHDe9ueMUP_Us/edit) with the help of the [documentation guideline](documentationGuideline.md). It is mandatory for you to use the template for documentation and follow the guideline for ease of understanding the service by the development team. |