|
|
| Successful Case
|
| Continental Automotive Electronics |
| Bosch Automotive Electronics |
| Schaeffler electric drive |
| Joyson Automotive Electronics |
| Huawei Technical Center |
| BMW Automotive Research and Development Center |
| Geely Auto Research Institute |
| Byd Automotive Research Institute |
| |
|
|
|
|
|
|
| Courses > Modeling |
|
 |
|
Transition from Requirements to Design |
Views 
|
|
|
| Time Location: Beijing, Shenzhen and Shenzhen open classes Based on registration |
| Course Cost：701 $/Person |
|
|
|
| Internal Training: You can customize internal training according to the needs of the enterprise. |
|
 |
Authentication Method:
Understand the competency model before training.
Ability evaluation after training:
Online Examination
Ability Analysis, give learning suggestions
The qualified person shall be issued a certificate as proof of vocational skill qualification
|
 |
|
|
|
This course is based on the "iPerson Competency Model: Requirements Analyst". After the training, the evaluation test will be conducted, and the qualified person will be awarded the "Competency Certification: Requirements Analyst" certificate
Students can obtain the ToolBox:： 《Requirements analysis work Guide》《Requirement Document Template》《Demand Tool Solution》 |
 |
 |
| learning Advice |
 |
| |
It is recommended to first understand the requirement capability reference framework:
Work maps, capability models, artifacts, tools;
In addition to this course, there are options for follow-up services:
courses, consulting, competency assessment, tool services. |
|
| This course solves the problem that developers do not have adequate requirements analysis and thus cannot effectively design. The specific problems are as follows:
They do not read requirements documents, resulting in omission of requirements information and inadequate requirements reading
There is no demand quality index, unconditional acceptance of demand, can not determine whether the demand meets the development needs
How do I find omissions in the alternative event flow description of use cases in the requirements document
Developers lack experience, and the requirements are not described, missing a lot of details, how to avoid
Unable to identify valid design constraints from requirements
The requirements cannot be effectively quantified to determine the metrics of the design
In the case of outsourced development, many requirements that are not described in the requirements document cannot be known due to communication limitations
|
|
| From a developer's perspective:
Reviewing the process from requirements to design
Explains how to receive, read and confirm requirements.
In combination with the package development style, it explains how to avoid the requirement omission of the implicit rule style
And then learn how to analyze requirements, how to transition from analysis to design
At the same time, clarify which are existing modules and which are new modules to be developed |
| Training Target: Requirements Analysts, Software Developers, Software Designers, Architecture Designers |
| Student Basis:Experience in demand, programming, analysis and design. |
| Teaching method: customized course + case explanation + group discussion, 60% case explanation, 40% practice exercise |
| Training Content: 2 days
|
| A developer's analysis of common problems with requirements analysis |
Overview of the roadmap from requirements to design
Define the boundaries of requirements and design2
Common questions developers ask about requirements analysis
Can not read the requirement document, resulting in the omission of the requirement information, the requirement reading is not in place
There is no demand quality index, unconditional acceptance of demand, can not determine whether the demand meets the development needs
How do I find omissions in the alternative event flow description of use cases in the requirements document
Developers lack experience, and the requirements are not described, missing a lot of details, how to avoid
Unable to identify valid design constraints from requirements
The requirements cannot be effectively quantified to determine the metrics of the design
In the case of outsourced development, many requirements that are not described in the requirements document cannot be known due to communication limitations
Problem cause analysis
Discussion on how to solve the problem |
|
What are the requirements and what are the criteria for description
Functional requirements:
Use case model, use case description, and quality criteria
How do I read the function description in the requirements document
How to confirm functional requirements with requirements personnel
Non-functional requirements (performance, reliability, availability, maintainability)
What are the quality standards
How do I read the non-functional description in the requirements document
How do I identify non-functional requirements with requirements personnel
How to identify hidden rules in requirements
Case: Combined with actual project cases
|
| Analyze the requirements and establish the design foundation |
Deterministic analysis mechanism
Architecture analysis
Processing analysis
Data analysis
Existing assets analysis
Use case analysis
Class analysisbr> Analyze non-functional requirements
property
reliability
availability
expandability
Case: Combined with actual project cases |
How to transition from analysis to design
|
Software level cases: combined with actual project cases,
From analyzing use cases to designing use cases
From analysis class to design class
From architecture analysis to architecture design
From processing analysis to processing action design
Case: Combined with actual project cases |
| Document Association |
How to review requirements document quality
The association between the requirements document and the outline design document
Association between requirements documents and detailed design documents
Case: Combined with actual project cases/li> |
|
| |
|
|
|
|
|
| Consulting Objective
|
Help build model-driven analysis, design, development, testing |
| Scope Consultation |
Requirements Modeling, Architecture Modeling, Database Modeling, Code Modeling, Test Modeling.
|
| Consultation Method |
Model-driven development process training, modeling and management tool environment construction, combined with actual customer case demonstration, team practice guidance, model evaluation standards formulation, specification formulation |
| Successful Case |
Huawei Research and Development Center, Space Center of Chinese Academy of Sciences, Nanjing 14 Institute, China Mobile Research Institute and so on. |
| For more information:010-62670969， umlooo@hotmail.com
|
|
|
|
|
