Document directory
- Requirement acquisition task
- Work with TOGAF to prepare for requirement acquisition
- Requirement acquisition technology
InEnterprise Architecture: Use TOGAF for product developmentI introduced how to use TOGAF for product development. I put value-driven on the first page because the most difficult part of product development is not technology, but whether the product itself provides value to users. So how does the product value come from? How can we ensure that our value proposition is correct? Value points may be well-known, obtained through self-analysis, or the assumptions we make in advance. However, no matter what method is used to derive value points, it must be determined by the user. Since the user serves as the referee, early user participation is one of the important strategies for general product development, and demand acquisition is one of the important technologies.
A while ago, the project team conducted a large-scale in-depth interview, which is part of the demand acquisition stage. This article describes the main tasks of the demand acquisition process and how to combine TOGAF to do this, it is also a summary of the work :)
Requirement acquisition task
- 1. Prepare
- Objective: To ensure that all resources (persons, materials, equipment, etc.) required for the demand acquisition activity have been organized and arranged
- Description: business analysis requires detailed requirement acquisition activities and schedules.
- Input:
- Project Scope
- Requirement acquisition technology
- Stakeholder list: stakeholder roles and responsibilities
- Defined business problems/opportunities
- Business Case
- Key Points
- Specify a specific scope for the selected Retrieval Technology and collect any materials that may be obtained
- Arrange all resources, including people, facilities, and equipment
- Suitable candidates for notification
- Stakeholder
- Project Manager
- Business Analyst
- Technical representative
- Output
- Allocated resources
- Supported Materials
- Unified standards: for example, a unified survey list and survey records
- 2. Implementation
- Objective: To obtain information related to stakeholder needs
- Description: direct communication, self-analysis, or distribution survey.
- Input:
- Allocated resources
- Unified standards
- Supported Materials
- Defined business problems/opportunities
- Business Case
- Requirement Management Plan
- Key Points
Tracking demand: when obtaining the demand, it is important to prevent the spread of the demand. The business goals help us determine whether this requirement is included in the project scope.
Capture requirement attributes: When obtaining a requirement, record the requirement attributes, such as the source, value, and priority of the requirement.
Terminology: Business terminology is the core asset for acquiring technologies for all needs. The term will contain the main domain terms in the business definition
Measurement: Track the time that participants actually spend on requirement acquisition to provide guidance for future plans. For example, you can know which customers cannot provide value for acquisition and when it is most convenient for customers.
Event-based acquisition technology relies heavily on the expertise of the stakeholders, as well as their willingness to participate and the ability of organizations to reach an agreement. In the process of obtaining, it is important to listen to the customer, and then it is necessary to sort out and summarize all the opinions of the stakeholders.
- Stakeholder
- Participants
- Business Analyst
- Project Manager
- Technical representative
- Output
- Obtain activity results
- Assumptions, constraints, risks, and problems
- Various technical documents (such as interview records, seminar conclusions, and questionnaire feedback)
- 3. standardized requirements
- Objective: To analyze information provided by stakeholders
- Input: requirement activity result
- Key points: refer to the specific retrieval technology described later
- Stakeholder: Business Analyst
- Output: standardized requirements
- 4. verification requirements
- Purpose: To verify that the regulatory requirements meet the needs of the stakeholders and make them understand
- Description: This task is generally used in interview and observation techniques.
- Input: Required
- Key points: refer to the specific retrieval technology described later
- Stakeholder:
- Business Analyst
- Interviewee
- Observed
- Output: required specifications after verification
Work with TOGAF to prepare for requirement acquisition
To better illustrate how to combineTOGAFI will take my recent practical work as a case to share with you a case of preparation.
- Project Introduction
- Our current product is in the business research phase, focusing on business research.
- The business architect has analyzed this business for A long time and also proposed multiple possible project A/B. in Project B, it can be subdivided into two projects: B1 and B2, current product positioning and management software (letters are used to represent the project name)
- Just a few months ago, according to TOGAF's product architecture, we were prepared to conduct a large-scale in-depth user interview before the next work arrangement. We planned to interview 25 customers and 100 online surveys.
- Preparations
Interviews can be conducted in various stages of the product, but the purposes of different stages should be different. We all know that tests are required after development, and tests are also required after the product architecture is completed. Therefore, this user interview is an activity that allows users to help us test the architecture.
- Input
- Project Scope: determine the main considerations B1
- Demand acquisition technology: Mainly interview, supplemented by network research
- Stakeholder list:
1. Interview technology: the user is positioned at the top of the enterprise. Through the user list collected by the senior management meetings and branches, the enterprise qualification, user roles and responsibilities are confirmed, and qualified callers are called one by one.
2. Questionnaire Survey Technology: User positioning at the operation layer
- Defined business problems/opportunities:TOGAFArchitecture context stage
- Business Case: The business product process can be explained through a prototype
- Output
- Structured interview: the value of the Management and Operation layers is different, so we need to design them separately. This in-depth interview Is mainly conducted by senior executives. Therefore, the interviews are mainly targeted at As-Is, To-Be, and value points (the main content of TOGAF) compliance and the customer's urgency to the software are listed in four interview questions. The network questionnaire is mainly designed for specific business application problems at the operation layer. In the early stage of product development, it is best to first develop the common value points of the Management and Operation layers. At least some value points must be included first; otherwise, product promotion is not convenient.
- Ready prototype products
- Interviewed person with an appointment
- Arrangement of internal interviewers
- Areas to be improved
- The requirement personnel in the group did not communicate in time after investigation. It is best to discuss the interview situation on a daily basis.
- Improve the interview technology, learn to listen, grasp the key points, be good at guiding, and confirm
- Validation path and method for business processes and value points
Requirement acquisition technology
The above describes the steps for obtaining requests. These steps are applicable to all requests for obtaining technologies. In the future, I will continue to introduce the specific requirement acquisition technology. Here, I will briefly discuss the requirements for obtaining technologies.
- Event-based
- Brainstorm
- Focus Group
- Interview
- Observation
- Prototype
- Seminars
- Execution-based
- Document Analysis
- Interface identification
- Reverse Engineering
- Distribution
Manage Software pre-sales consulting and Enterprise Architecture
Recommended: online e-books you may need
You are welcome to reprint it. Please note: Reprinted fromZhou jingen [http://zhoujg.cnblogs.com/]
