Requirements analysis, product design to deployment and delivery phases illustrated
Below is a diagram that represents the product design to deployment delivery phase:
All parts of the R&D process:
- demand analysis
- product design
- UI design
- Development and Testing
- Deployment delivery
Team Division
Teams by function
- Product Team
- Backend Development Team
- UI Design Team
- Front-end development team
- Operations and Testing Team
- Mobile Development Team
Teams are organized by function and each team has a team leader, such as a team leader.
The organizational structure is shown below:
Cross-functional teams
Cross-functional teams are generally organized based on a product, project, or functional feature. Within this team, requirements, development, and deliverables can be completed, and then the next product feature can be developed.
Such a team consists of product, UI, back-end development, O&M testing, delivery, etc. to form a cross-functional full-featured development team.
Architect Team
In slightly larger companies, there may also be some public technical teams, such as the architect team, which is basically responsible for the design of the technical architecture of the company's projects, attacking technical problems, and may also be responsible for the company's technical infrastructure.
Companies with fewer developers may not have a team of architects, so what happens? The technical manager is usually the one who doubles up as the architect.
Interdepartmental teams
Some companies may form committees according to functional responsibilities to address various technical, communication, and coordination issues encountered within the company.
For example, the Technology Committee, the company's highest technical decision-making organization, which consists of CTOs, technical team leaders, architects, who communicate, discuss and solve various technical problems encountered in the company.
The Product and Design Committee, consisting of CTO, product managers, designers, architects, business people, etc., reviews product projects, various requirements, etc., and solves the company's product-related problems.
demand analysis
What's the demand?
What is Demand? In economicsdemand (economics)is the quantity of a good that a consumer is willing and able to purchase at different prices in a given time period.
What are the requirements in the product?
Understood from a problem perspective, the user is trying to solve a problem in a certain scenario.
Understood from a heart perspective, in a certain scenario, in order to fulfill a certain desire within the user.
Requirements = User + Scenario + Problem
How to get user requirements
First you need to gain insights into user requirements, collect the insights and then analyze them - Requirements Analysis. Analyze the true requirements and pseudo requirements and then form a requirements document.
- Insight into the user's needs, imagine yourself as a user, and enter the user's scene. This is what Ma Huateng said about entering the user state in 5 seconds.
- The second can be field trips and user interviews to understand user needs.
- Thirdly you can use questionnaires for requirements gathering.
- The fourth can leverage third-party data or analyze its own product data to capture demand.
- Fifthly you can do a competitive analysis to get the requirements.
And so on for some demand insights.
（Step-by-step diagram (requirements gathering and analysis)
user analysis
For example, the user's age, education, interests and hobbies are analyzed to determine which users are the target users, and then demand analysis can be performed.
Requirements Analysis Steps
Requirements Analysis Steps:
Requirements Filtering -> Requirements Auditing (reviewing requirements for authenticity) -> Requirements Categorization -> Requirements Sorting (prioritization)
This is followed by requirements realization, requirements delivery and validation.
- Requirements Filtering: Some low-level requirements are removed, some requirements are incomplete and incorrectly formatted, and these need to be communicated and refined by the production manager to continue to improve this requirement.
- Requirements Review: Evaluate whether the requirements are real, whether the requirements are valuable to the product and business, and whether there are no words that need to be removed or re-collected from the requirements.
- Classification of Requirements: Categorize formal requirements and subsequently treat different requirements differently. A product may have many different product groups and which product group takes on this requirement.
- Requirements prioritization: Prioritize requirements, with high priority requirements done first because development resources are limited.
A Requirements Analysis Model, Introduction to the KANO Model:
The KANO model is a model of user satisfaction with product features established by Noriaki Kano, a professor at Tokyo Institute of Technology, and his colleague Fumio Takahashi. It is a tool generally used in requirements analysis for categorizing and prioritizing requirements.
KANO models can be used to qualitatively analyze user acceptance of new features.
The model's core concept:
User satisfaction with a product or service does not simply increase proportionally with the increase in functionality, but shows a more complex non-linear relationship.
KANO model plot:
KANO model demand categorization:
-
Required Requirements (Attributes)(Must have): Some are also translated as basic-type requirements (attributes). Needs that users take for granted and must have, and these needs must be met. When these needs are not met, that is, when they are not provided, user satisfaction decreases dramatically; when these needs are met, user satisfaction does not improve. For example, cell phones make phone calls and send text messages.
-
Desired demand (attributes): User satisfaction increases when this need is met, and decreases when it is not.
-
Charismatic needs (attributes): Users don't have much expectation for this kind of demand, and product managers need to have deep insight into users to dig into this hidden demand, which belongs to the demand of surprise to users. If you don't meet this demand, user satisfaction will not decrease; if you meet this demand, user satisfaction will increase dramatically. Sometimes it is a reflection of the product's competitiveness.
-
Undifferentiated demand (attributes): Whether or not this requirement is met has no impact on user satisfaction.
-
Reverse type demand (attribute): The presence or absence of such a need is of no concern to the user. If this need is satisfied, user satisfaction will decrease instead.
They are prioritized in order:
Essential Needs > Desired Needs > Charismatic Needs > Undifferentiated Needs
The analysis steps of KANO model include: questionnaire collection → data cleaning → attribute attribution analysis → Better-Worse coefficient calculation.
user analysis
For example, the user's age, education, interests and hobbies, etc. to analyze, figure out the user profile, to determine which users are target users, and then further user needs analysis.
Business Analytics
Some concepts in business analysis:
Business objectives, business process analysis, what are the key business processes, what are the business scenarios, what are the business objects, what are the relationships between business objects? What are the business activities, what are the business rules, what are the relevant roles? Abstract the business model.
Diagramming the business, e.g., using UML mapping to draw the steps of the business, use case diagrams, business process diagrams, etc.
product design
Product Programming
User and Business Requirements -> Product Definition -> Product Solution -> Detailed Design
After analyzing the user requirements and business requirements above, it is time to define the product .
- Product Definition: Converts user and business requirements into a description of product realization, forming product requirements.
- Product Solution: Once the product definition is complete, there can be multiple solutions to realize the product, and it is possible to further come to a discussion about which solution is more appropriate.
Overall solution, product architecture design, subsystem design, business module design and so on.
- Detailed design: list of functions of each module, detailed description of various functions, relationship between modules, interface details, etc.
Product PRD
The product manager can output a product PRD document, which is a document for back-end development, front-end development, interaction design, QA testing.
The PRD document consists of:
- Background description of needs
- Product Flowchart
- Function List
- Function Details
- Iteration Roadmap
- Product Prototyping
The product prototype diagram, which is important here, draws the interface, features, operations, rules, etc. of the product.
Product prototyping tools are Axure, Blue Lake, Figma and other tools and software.
Finally, the PRD document review process.
UI design
Design the product UI and interaction design according to the prototype drawn by the product manager.
Development and Testing
At this point, it's a true realization of the product.
architectural design
Architecture design, in general, can be categorized into: business architecture, product architecture, application architecture, data architecture, and technology architecture.
-
The business architecture can be the business systems that the business can be composed of once the overall analysis of the business is complete.
-
Product architecture corresponds to business architecture, and a product implementation is an implementation of the business, so often there are many similarities between business architecture and product architecture diagrams.
-
The application architecture corresponds to the product architecture, what are the components of the developed application.
-
Data architecture is about data design, data management, data analysis, etc.
-
The technology shelf involves specific technology system architectures, application technology architectures, and so on.
Application Architecture, Data Architecture, and Technical Architecture These 3 architectures are relatively technical in nature.
technological infrastructure
- System Architecture:
Design the application based on the product architecture document, PRD document above.
System Design:
- Do I need to design into multiple applications? According to the 4 cycles of the product lifecycle, in the first cycle, a product developed from 0 does not need to be divided into multiple applications. A single application is sufficient.
- Subsystems and modules: If the application system is not complex, there is no need to divide the subsystems. It is straightforward to divide the single application system into modules.
Architecture selection: monolithic architecture is sufficient.
Finally, you can draw a diagram of the application system architecture.
- Application Technology Architecture: Technology selection and overall technology architecture design, produce a design diagram. For example, using SpringBoot, MySQL, Kafka for architecture and development.
- Module and class design: Division of modules, class design in modules. Various relationships of classes, interfaces.
- Database design: database field design.
- API interface design: API interface design for interaction with the front-end and other interface design, such as third-party interfaces.
All of the above designs can produce corresponding technical documentation.
Data architecture: data management, data analysis
development capability
An agile development approach can be taken with an iterative approach to product feature development. One product goal is achieved per development cycle.
Scrum Agile development methodology:
- The Product Owner is responsible for the Product Backlog and prioritizes it.
- The Agile Lead is responsible for Sprint Planning. Each iteration cycle (typically 1-4 weeks), sprint tasks are selected from the iteration plan for development, and then incremental iterations are delivered.
- Development team members conduct brief daily stand-up meetings to share progress, plans, and problems encountered.
- Upon completion of each iteration cycle, a review meeting is conducted to present the deliverables and gather relevant feedback.
- At the completion of each iteration cycle, a retrospective meeting is conducted to review what went well and what didn't go so well, and to develop improvements.
Continuous Integration and Testing
After completing the sprint, the source code is submitted to the Gitlab code repository, and then the build is triggered. After completing the code coverage, unit tests, and other successes, the build is completed, and the results of the build can be stored in the artifactory and deployed to the test environment.
The QA testing team performs QA testing, performance testing, and regression testing, and if the QA team passes the tests, it is deployed to the UAT (User Acceptance Test) environment. If the UAT test passes, it becomes a candidate for deployment to the production environment.
Deployment delivery
If all of the above tests pass and the testing department agrees to go live, the appropriate tag version is created and ready to go live.
The Ops team establishes the timing of the go-live, the version number of the go-live, and assesses the scope of the impact of the go-live.