In this article, I will write several short articles carefully in my learning and practice, and strive to repeat them. This article does not explain how to find out use case, how to describe use case, etc., because there is a lot of information. I just wrote some of my own experiences and questions that I was or were confused about. Therefore, this article will not specifically describe some common terms, such as use case, RUP, and MSF.
I wrote a short article because I like to read it. For more information, see "Let them be shorter-call on everyone to make our internet texts more readable ".
Requirement= Use Case model?None.
Not all types of projects are suitable for useUse CaseTo describe the requirements.Use Case, ThenUse CaseAnd cannot describe all of the requirements,Use CaseOnly functional requirements can be described.
Use CaseDescribes the interaction between the executor and the system.Define and describe a coherent functional unit of a system or subsystem. SoUse CaseWhat you are good at is describing the interaction process between executors and the system in a specific scenario, thus defining the system functions. So the most common one is to describeMISSoftware requirements of a project.
In general,Use CaseWhich requirements are not suitable for description? Technology,AlgorithmRelated, such as data mining, such as servicesProgram; User Experience needs; Technical Transformation and upgrade needs; and so on.
Therefore, you should have a little thought before the new project starts,Use Case ModelingIs it the best way to capture requirements.
In additionUse CaseWhat else? For those who do the requirement analysis, never forget that the requirement is not onlyUse Case.Use CaseIt only describes the functional requirements of the system. For a complete set of requirements, see requirement model.
Digress,Use CaseWhat can I do besides describing software requirements?
Use CaseIt is a good form of describing the interaction between "user" and "system. When we expand the extensions of "user" and "system", we find thatUse CaseYou can do many things. For example, I once found that companies useUse CaseTo describe the company's internal business processes. For example, if a department is treated as a "system", the person who produces "business relationship" with the Department is the executor of the use case.