Notes on "The Law of Construction"---Chapter 10 Typical Users and Scenarios

Notes on the Law of Construction

Chapter II Personal Technology and Process
Chapter Four Cooperation
Chapter 6 Agile Process
Chapter 10 Typical Users and Scenarios

---

---

Foreword

Persona and Scenario, Functional Spec and Design Doc, FDD, Use Case

---

I. Typical Users (Persona) and Scenarios (Scenario)

A typical user often describes the typical skills, abilities, needs, ideas, work habits, and work environment of a group of users.
Determine for each typical user his goals (what he wants to achieve with the system).For each goal, list the process that must be experienced to achieve the goal, that is, the scene, which can also be called a story.
From scene to mission.

Second, use cases

Commonly used requirements analysis tools.Basic elements:

• Title: Describe the goal to be achieved by the use case
• Actor: A role that interacts with a software system, such as a user, other entities, or even time (describe some time-related scenarios)
• Main Success Scenario: A series of steps describing how the character interacts with the system to achieve the goal.
  • Steps: describe the interaction of each step
• Extended scenarios: describe some extended interactions, such as some unexpected situations

Third, Specifications

Software Function Spec

is mainly used to describe the external functions of the software and user interaction (think of the software as a black box).
Describes the functions, input, output, interface, function boundary issues, function efficiency (for users), internationalization, localization, abnormal situations, etc. of software products from the user's point of view, not involvingSoftware internal implementation details.

Template:

1. What does the goal include and what does not include (specify some assumptions);
2. Users and typical scenarios (mainstream users);
3. Terms and definitions (define some concepts);
4. How users use software functions (software interaction steps);
5. Various boundary conditions;
6. What are the side effects of the function and any explicit or implicit dependencies on other functions;
7. What is "good" and what is "this function has been tested and can be delivered";
8. What kind of project-related data can be collected after the software is released, and how to prepare for the data collection in the implementation stage;

Software Technical Spec

Also known as Design Doc, it is mainly used to describe the design specifications inside the software (think of the software as a transparent box is used to describe how developers implement a certain function, orA set of interrelated functions.
Note: Design documents should describe how the design embodies some design principles.

Fourth, Feature Driven Design

How to turn user requirements into development work that can be directly manipulated by team members, FDD is one of many methodologies for this problem.

Construction steps:

1. Develop an Overall Model
2. Build a Feature List
3. Plan by Feature
   Considerations (dependencies between entities and features; complexity; appropriate advance of high-risk and difficult features; …)
4. Design by Feature
   Analyze a set of related entities and their functions, and show how entities and functions are dynamically combined through Sequence Diagram and other toolsup to implement a function.
5. Build by Feature
   Specific team members implement classes/functions, perform relevant unit tests, and integrate the code into the product build after code review

Note: FDD does not speak enough about testing other than unit testing (integration testing, stress testing, testing of user interface and user experience).

---

Summary