# Engineering requirements for new Project

The feature development process at ezyVet typically follows a structured approach that involves several stages, from ideation to launch. While the exact details of the process can vary depending on the product and team, the following are some of the key stages that should be involved:

## Ideation
The process starts with ideation, where product managers, product owners brainstorm ideas for new features or improvements to existing ones. This process can involve gathering feedback from users, analyzing data, and evaluating market trends.

### Stakeholders
Product Managers, Product Owners, Business Analyst, Domain Experts

### Artifacts
Scratch pads, draft documents, customer journeys identified, Ubiquitous language

## Conceptualization
Once an idea has been identified, the team will work on conceptualizing the feature, defining its scope, and evaluating its feasibility. This stage involves identifying the technical requirements, estimating the level of effort and resources needed, and identifying any potential risks or roadblocks.

### Stakeholders
Architects, The Engineering Team, Product Owners, UI/UX Designers

### Artifact
Optional - POC of potential solution
customer journeys finalised

## Requirement Specification
Once the conceptualization stage is complete, the team will move on to the design stage. This involves creating detailed design specifications, wireframes, and mockups of the user interface. The design process may involve multiple iterations based on feedback from stakeholders and users.

### Stakeholders
The Engineering Team, Product Owners

### Output Artifacts
Technical Design Documents <!-- TODO: produce template-->

## Planning
In this stage, the team will develop a detailed plan for implementing the feature. This can involve defining the feature's requirements, creating a roadmap, developing a project schedule, and identifying dependencies and potential bottlenecks.

### Stakeholders
Developers, Product Owners, QA

### Output Artifacts
Tickets

## Implementation
With the design finalized, the team will move on to implementing the feature. This typically involves writing code, testing, and iterating until the feature is stable and meets all requirements.

### Stakeholders
Developers, Product Owners, QA

### Output Artifacts
Working Code

## Launch
Finally, the feature will be launched to users, and the team will monitor its performance and gather feedback for future improvements.

### Stakeholders
Developers, Product Owners, Platform

### Output Artifacts
Working Code

## Glossary:

### Idea:
Idea is a mental representation of something, this is often perceived as a suggestion that comes to mind.

### Concept:
A concept on the other hand, is a more developed and refined mental representation. The concept is an abstract idea that reflects a systematic and structured understanding of a particular subject.

### Stakeholer
A stakeholder within the context of this document refers to the parties that will be actively working on the artifacts produced throughout a project stage.

### Artifact
Documents and other tangible media that get produced from a team working toward a solution.

## Notepad:
Idea -> Concept -> Requirements -> Implementation -> Deployed Artifacts

Parts:
**TODO**: Explain stakeholders and artifacts for each section.
**TODO**: Explain when a document like this is required
## TODO

Initiative -> SOMETHING HUGE -> Revamp our UI/UX so the app looks modern.

TODO: define a process for creating initiatives

## Issues
Here we will list some areas that causes friction in our current setup and what we are doing to mitage these friction points.

Friction:
* New features are being built without technical signoff. An engineer cannot provide technical signoff for a major feature. This needs signoff from the architecture team.
* Engineers are unknowingly making architectural decisions without architecture being involved.
* New features are started without any documentation.
* New features are being created using old systems rather than investing in newer systems that will improve performance overall. (need a good example)
* Features are shipped without any architectural review.
* Engineering architecture is not part of resourcing.
* Architectural decisions are not being respected.
* No clear process that handles with the overarching business related to taking a feature from idea to launch.

Examples:
* Global search was kicked off without key architecture members being present.
* Global search development was started without documentation being present.
* Contextual help guide system was started without key architecture members being present.
* Windcave release of remote signatures did not have any opportunity for architectural oversight.
* None of the architects are involved in ezyVet roadmap creation and what technology is required to sustain roadmap features.
* Global search team want to make changes to core authentication systems in ezyVet without involving architecture.
* Product type split feature had no support to get on the roadmap.
* PHP8 rollout had no support to get on the roadmap.
* V3 Go to market had no support to get on the roadmap.
* SSO project core mechanisms are being blocked from non architecture members of the team. This is disrupting this feature going ahead.
* No single feature was completed with the same process.

### Pouya
1. General: There is no process in place for major feature development. What is the current approach to major feature development? how do I learn as a engineer who has been on-boarded what to follow. Example: How did the contextual help process start? why the first proposal aimed at expanding a technical debt to a new areas of the software? are the managers are aware of the true cost of this technical debt ? given that we are currently at a very risky/dangerous place with tech debts, how do we make sure this is not introduced further to our systems ?
2. There is no ubiquitous language created for each domain and product. You would ask 10 person the same question, and end up getting 20 answers. If this company is going towards the approach of domain-driven design, how do we ensure consistent language in a product? how is this captured currently? what artefacts do we currently use to create and disseminate ubiquitous language. example: in the financial screen the code communicates the phrase of price adjustment rules, while other teams refer to it as discount, some just call it adjustment. Which is the right phrase ?
3. How do developers currently use architecture resources ? how do they know need to for example reach out for an architect ? example: for global search project, initially how developers decided which backend to use ?