User Requirement Modeling

Microsoft Visual Studio ultimate helps you understand, discuss, and communicate your needs by drawing relationships between your activities and the role of your system in helping you achieve your goals. A requirement model is a set of such relationships. Each of these relationships focuses on different aspects of user requirements.  The requirement model has the following functions:  Differentiate the external behaviors of the system from its internal design.  Compared with natural language usage, there is less ambiguity in describing user and stakeholder needs.  Define a consistent Glossary that can be used by users, developers, and testers.  Reduce gaps and inconsistencies in demand.  Reduce the workload required to respond to demand changes.  The sequence in which each function is planned to be developed.  Use the model as the basis for system testing and establish a clear relationship between testing and requirements. When the requirement changes, this relationship helps you update the test accurately. This ensures that the system meets new requirements.  If you use the demand model to focus on discussions with users or their representatives and re-view the demand model at the beginning of each iteration, the use of the Demand Model will be the greatest benefit. You do not need to complete the requirement model in detail before writing the code. Even a very simple part-of-work application usually forms the most motivating basis for discussion with users. A model is an effective way to summarize the results of these discussions. For more information, see using models during development.   DescriptionIn all these topics, "system" indicates the system or application to be developed. It can be a large collection of many software and hardware components, a single application, or software components in a larger system. In each case, the demand model describes the behaviors that can be seen outside the system through the user interface or API.     You can create different views for a regular task. Each view provides specific types of information. When creating these views, it is best to switch between views frequently. You can start from any view during creation.  Relationship Diagram or document Content described in the requirement model Section   Use case diagram Who uses the system and what operations it performs. Describes how the system is used.   Concept chart A glossary that describes the type of the requirement. You can see the type on the system interface. Define the term used to describe the requirement   Activity diagram Workflow and information between activities executed by users and systems or their components. Displays workflows between users and Systems   Sequence Diagram The sequence of user interaction with the system or its components. The alternative view of the activity diagram. Display interaction between users and Systems   Additional documents or work items Performance, security, availability, and reliability conditions. Describe Service Quality Requirements   Additional documents or work items Constraints and rules not specific to specific use cases Show business rules     Note that most graph types can be used for other purposes. For an overview of graph types, see develop a software design model. For basic information on drawing a relational diagram, see How to: edit a UML model and a relational diagram.  Describes how the system is used to create a use case diagram to describe who will use the system and what the system will achieve. Use Cases indicate the target of the System user and the steps to achieve the target.  For example, the online meal sales system must allow customers to order food from the menu, and must allow restaurants that supply food and beverage to update the menu. You can summarize all of this in the use case diagram:      It also shows how a use case is composed of multiple smaller cases. For example, ordering a meal is a part of a purchase, and the purchase also includes payment and delivery:        It also shows which use cases are included in the scope of the system being developed. For example, the system in the illustration is not involved in the "food delivery" Use Case. This helps you set the development context. (In the use case diagram, the subsystem container can be used to represent the system or its components .)  It also helps your team discuss what will be included in subsequent versions. For example, you can discuss whether to schedule "Pay meals" between restaurants and customers in the initial version of the system rather than the entire system ". In this case, you can move the "meal payment" of the initial version to the exterior of the "Eat now" system rectangle.  The use case diagram only provides a summary of the use case. To provide more detailed instructions, you can link the use cases on the graph to a separate document or to other relational graphs. To learn how to perform this operation, see How to: link a use case to a document and a diagram.  Use Case Diagrams can help the team:  Focus on the operations that users need to perform on the system, rather than focusing on the implementation details.  Discuss the scope of the system or the specific version of the system.  The following topics provide more information:  To learn more Please read   More details about how to create a use case UML use case diagram: Principles   Elements in the use case diagram UML use case diagram: Reference   How to Develop code through Use Cases Establish Software System Architecture Model     Define the terms used to describe the requirements you can use UML class diagrams to help develop consistent business concept terms for the following purposes:  Users discuss the business that the system will act on.  Describes user requirements, such as use cases, business rules, and user scenarios.  Types of information exchanged in system APIs or through user interfaces.  Describes the system or acceptance test.  When used for this purpose, the content of a UML class diagram is called a "concept class diagram ". (Also known as "Domain Model" or "Analytical Model ".)  In the concept class diagram, you only need to show the classes required to describe the requirements, without displaying any details of the system's internal design. This diagram does not show any details about the system's internal design. Generally, you do not need to display operations or interfaces related to the concept class.  For example, you can create the following concepts for the "Eat now" system:      The concept chart provides the terms you use throughout the demand model. For example, in the detailed description of the "order" Use Case, you may write:  The customer selects a "menu" from which the "order" can be constructed, and then selects "menu item" from "menu" to create "ORDER item" in "order ".  Note that the usage of terms in the description is the name of the class in the model. The relationship graph clearly shows the relationships between these classes. For example, it clearly shows that each order is associated with only one menu.  Errors in user requirements are generally caused by incorrect understanding of the specific meaning of words. For example, most restaurants have a common understanding of the terms "menu" and "order", but the difference between order items and menu items is not clear. It is important to disclose these differences when discussing requirements with business stakeholders. A class chart is a very useful tool that helps you clarify terms and their relationships.  A conceptual model can constitute a basic term that describes the business logic of the system. However, classes in software are generally much more complex than conceptual models because the implementation must consider performance, distribution, flexibility, and other factors. A system usually has multiple implementations of a conceptual class.  For example, you can use XML, SQL, HTML, and C # To represent orders in different parts of the system and interfaces between parts. The association between orders and menus can be expressed in different ways, such as references in C # code, links in databases, and cross-referenced IDs in XML. Despite these changes, the conceptual model provides important information in each component of the software. The class diagram in the example shows that in each implementation, each order has only one menu associated with it.  To help the team:  Define and standardize the basic terms used when discussing user requirements.  Clarify the relationship between these terms.  The following topics provide more information:  To learn more Please read   For more information about the search requirement class UML class diagram: Principles   Elements in a conceptual chart UML class diagram: Reference   How to Develop code Through Concepts Establish Software System Architecture Model     Display business rules are not associated with specific use cases, should be observed throughout the system.  Many business rules are constraints on the relationship between conceptual classes. These "static business rules" can be compiled as comments associated with the classes on the conceptual charts ". For example:        The "dynamic business rules" constraint specifies the sequence of events allowed. For example, a sequence chart or activity chart shows that you must log on to your system to perform other operations.  However, many dynamic rules can be replaced with static rules to specify them more efficiently and broadly. For example, you can add the Boolean feature "logged on" to the class in the conceptual class model. Add "logged on" as the post condition for the login case and the preconditions for most other use cases. This method avoids defining all possible combinations of event sequences. This method is more flexible when you need to add a new use case to the model.  Note that the selection here is about how you define the requirements, and it is irrelevant to how you implement the requirements through program code.  The following topics provide more information:  To learn more Please read   More details about searching and recording static business rules UML class diagram: Principles   Elements in a conceptual chart UML class diagram: Reference   How to Develop code that complies with business rules Establish Software System Architecture Model     Descriptions of service quality requirements there are multiple types of service quality requirements. These categories include:  Performance  Security  Availability  Reliability  Stability  You can include some requirements when describing specific use cases. Other requirements are not specific to use cases and can be written in separate documents more effectively. If possible, it is very useful to follow the terms defined in the requirement model. In the following example, note that the main words used in the requirement are the titles of participants, use cases, and classes in the illustration above.  If a restaurant deletes a menu item when ordering a meal, any order item that references this menu item will be displayed in red.  The following topics provide more information:  To learn more Please read   More detailed information on recording service quality requirements Guidelines for Defining Quality of Service Requirements    Attach other documents to Use Cases How to: link use cases to documents and relationships   How to Develop code that complies with Service Quality Requirements Establish Software System Architecture Model     Shows workflows between users and systems. You can use activity diagrams to display workflows between different use cases. It is usually useful to create a requirement model by drawing an activity diagram (displaying the main tasks performed by the user inside and outside the system.  For example:      You can draw use case and activity diagrams to display different views of the same information. The Use Case chart is more effective for operations that are displayed in a large activity with a smaller nest, but not a workflow. For example:        Note that you can also use activity diagrams to describe the algorithms in the software. However, if you use these diagrams for business processes, you should focus on operations that are visible outside the system.  The following topics provide more information:  To learn more Please read   More information about how to define business workflows UML activity diagram: Principles   Elements in the activity diagram UML activity diagram: Reference   How to Develop code through activity diagram Establish Software System Architecture Model     Display interaction between users and SystemsYou can use a sequence diagram to display messages exchanged between the system and external participants or between various components of the system. The sequence diagram provides a step view in the use case, which can clearly display the interaction sequence. Sequence diagrams are particularly useful when there are multiple interactive parties in the use case and the system has APIs.  For example:      One advantage of a sequence diagram is that you can easily see the messages that pass into the system you constructed. To design a system, you can replace a single system lifeline with the independent lifeline of each system component, and then display the lifeline to respond to the interaction of each incoming message.  The following topics provide more information:  To learn more Please read   More information about how to define interactions UML sequence diagram: Principles   Elements in a sequence diagram UML sequence diagram: Reference   How to Develop code through sequence diagram Establish Software System Architecture Model     Using a model to reduce inconsistencies to create a model usually significantly reduces the inconsistencies and ambiguity of user demand. Different stakeholders generally have different understandings of the business scope of the system work. Therefore, your primary task is to eliminate these differences between customers.  You will find that when you create a model, there will naturally be many problems related to the business field. By raising these questions to the user, the change requirements will be reduced in the subsequent phases of the project. The following are some specific questions. You can first ask yourself. If you are not sure about the answer, you can ask the business stakeholders:  For each class in the demand model, ask "which use case to create such an instance ?" For example, for the online ordering service, you may ask, "which use case is used to create an instance of the" restaurant menu "class ?" This will lead to discussions about how a new restaurant registers with the service and provides menus. You can ask similar questions about which use case to create or change features and associations.  For each use case in the requirement model, use the words provided by the class diagram to describe the results or post-conditions of each use case. It is usually useful to draw a sketch of a class instance before and after a case match. For example, if the condition after the use case indicates that "the menu item has been added to the customer's order", a sketch of the order and menu item type instance will be drawn. Display the effect of the use case (such as a new link or object) in different colors or in a new drawing ). This usually leads to discussions about which information is necessary in the model. Although demand classes are not directly related to implementations, they describe the information that the system will need to store and transmit.  Query the characteristics and associated constraints, especially those involving multiple features or associated constraints.  Inquire about valid and invalid use case sequences, and draw a sequence diagram or activity diagram to demonstrate these use case sequences.  By checking the relationship between views provided by different relationship graphs, you can quickly understand the main concepts used by users and help them understand what they need from the system. You can also better understand the most uncertain requirements of stakeholders. You can plan to develop these features in at least simplified form at an early stage of the project to allow users to experience these features.