Use Cases to capture business requirements (seven practical principles of business requirements)

Blueski recommendations []
Source: Rational edge
Author: Thomas behrens
 

 

Seven principles that lead to the difference

Thomas behrens, chief technology officer, alpheus Solutions
Source:
Http://www-128.ibm.com/developerworks/cn/rational/rationaledge/content/feb05/behrens/

From rational edge: This article, based on the experience of the business demand engineering project of a payment system operated by mobile phone, roughly depicts seven practical principles for capturing business requirements.

Suppose you already have some experience in requirement engineering specifications, and you suddenly face a major business demand solution that involves multiple companies and spans different business areas. At first, a problem occurs in your mind: will the use case be used in this project? How should I determine the correct level of case granularity? How should I build a case model? Do I have to crop standard IBM Rational Unified Process or RUP to meet delivery standards? This article provides alpheus, an international IT consultant, on how to address these issues in project 1 of the demand project on simpay (a hand-held telephone payment system that can be operated together. It draws from what we learned in the project and becomes the seven practical principles. It will illustrate how you succeed in your own business demand plan.

This discussion assumes that the reader has a good understanding of the demand project, use cases, and the Basic Agreement of the RUP.

 

Simpay is the First Step 2 on developing a new architecture that can work together with the current segment of the handheld phone payment market. Figure 1 shows the overview of the business context. Simpay occupies the central location of this context and uses open interfaces to integrate handheld phone commercial requirements (representing multiple retailers and [or] content providers) and handheld phone operators (representing and authenticating end customers) to become online financial transactions. Simpay provides services for payment authentication, settlement and settlement of funds between handheld phone operators and handheld phone business requirements. 3

Figure 1: Overview of simpay Business Context

The business demand process is embedded in a large process of transforming the payment solution (such as the simpay product) into the market. The product presents a new business built from scratch using manual or automatic processes. Because the budget must be properly controlled, it is decided to extend the implementation of the exact automation process until the business has been modeled.

The overall project and business features can be summarized:

• Multiple companies (orange, Telef a m es, T-Mobile and Vodafone)
• Focusing on Scale (supporting about 0.2 billion million customers)
• Multinational companies with virtual teams
• Potential reputational impact
• Covering multiple expert fields (for example, wireless communication and Financial Services)
• Rule extender with various legal constraints

These features express the importance and visibility of establishing a set of stakeholder, common, and consistent business needs for all enterprises.

We will introduce a process of combining with RUP that spans the project life cycle from the commercial idea of simpay to the product deployment. We map activities and delivery products to four stages (initial, refined, built, and productized) of RUP and their respective milestones. The RUP activities and delivery products were originally tailored to the software development process, but the project already has a very broad scope (for example, a delivery product is created by a new company, such as simpay Ltd .). However, activities and deliverables sometimes deviate significantly from the RUP. Furthermore, this process, contrary to the best practices of the RUP, is not repetitive. However, many individual deliverables are generated on the basis of repeated/incremental, provide early reviews, verification and quality assurance, and occasionally rely on early activities to start.

When we want to capture requirements at the business level without specifying that a specific delivery product is manual or automatic, we use the RUP business modeling specification as our reference specification, and use some elements of the requirement project for enhancement. For the customized delivery product structure, see the supplementary content of the article.

Practice Principles
Next, we will discuss the practical principles summarized by our experience. They will help you:

• Find the correct boundary for your business needs (Principle 1: Get the correct scope)
• Properly structured your use case model (Principle 2: challenges your Use Case goals and principles; Principle 3: Use Demand attributes to determine the best use case model)
• Further detail your business needs (Principle 4:Divide and conquer: Decomposition by business participants)
• Describe your business use case appropriately (Principle 5: use case description: Clarify"What is", Not"How to do")
• Connect your business use cases to avoid redundancy and confirm your needs (Principle 6: propose a domain model and Principle 7: Use the lifecycle of an object)

Principle 1: determine the correct scope
The purpose of requirement management is to determine the correct scope. Where is the boundary? Who is inside and who is outside? This is a high-level abstraction and more important. A small change in scope may have a major impact on the enterprise owner, the work to be carried out, and the project operation deadline.

Let's review Figure 1. This time we regard it as a market view. 6. This view shows the interaction between purchase (shopping interaction) and payment. It also shows simpay as the payment intermediary. Now, compare figure 1 and figure 2. In addition to using different marks (UML), figure 2 shows two different contexts. The above is the context of a merchant with a sales function, which shows in the case of purchasing a product. The following is the payment function of simpay, which is presented in the request payment case. 7

If you look at it carefully, you will see that this feature divides the simpay from the market view into two parts: the simpay product and the simpay company. This difference is necessary when we find that the simpay product is not only required by simpay Ltd. (that is, the central entity), but also required by mobile operators and mobile merchants. At the same time, these entities recognize the features of the product; therefore, all three parties are within the scope of the project.

Is this an overhead? No! It helps us clearly establish project boundaries. This means that we can avoid unnecessary discussions from the beginning. After the event, these differences can be seen clearly. In addition to new business activities, the boundary is determined for those involved in the demand activities. However, it is worth studying.

Figure 2: commercial and simpay contexts

Principle 2: Challenge Your Use Case goals
Once you have determined your scope, you can start to determine the use case and participants. A common problem is the explosive growth of the use case model, especially when you are working at the abstract layer of business requirements. Soon, you will find that you need to express a lot of content. Literally, stay at the top of your case model to avoid "700 case complications ". If your use case model is exploding, you should challenge your Use Case granularity. For simpay, at the highest abstraction layer, we end with about 20 main use cases. Remember, a Use Case transmits values to the participants; it achieves a goal for the participants. Make sure that all use case objectives are at the same level, and for business modeling, all goals are at the abstract layer.

There is a specific example from the simpay context. Payment can be implemented immediately -- payment authorization 8 occurs at the same time as payment capture 9, or deferred implementation -- authorization occurs before the capture. Figure 3 shows a possible use case diagram. However, note that the purpose of the use case is not at the same level. The merchant's goal is to accept the payment. He must obey the management rules and separate the payment transactions into the captured independent authorization, which may not be his pleasure. At the same time, you are forced to express some relationships between the request for payment authorization and the request for payment capture. A simple solution is to combine the two use cases into a use case called request deferred payment. 10. You can use fewer use cases and create case models that are easy to understand.

What is a long gap between authorization and capture? You don't need to worry about this! The time gap is not an indicator for separating use cases. In particular, Business Use Cases can run for a long time. The essential criterion for determining whether to separate use cases is whether their goals are different.

Another danger that causes the use case to expand is that I call it "Lily's concurrent symptoms ". When you find a change for a use case, it starts; In the simpay example, it may be the channel for payment (for example, SMS, WAP ). You may immediately be tempted by the multi-purpose use cases in our example (requires immediate payment using WAP, SMS, and other methods ). There may also be more dimensions. Soon, you will be able to cover your use case map like a lily covering the pond. On the contrary, it challenges the target. If you do some analysis, you will find that the target is the same for all these use cases. Focus on the actual use cases, and you will know a better way to present these changes later (for example, in the special requirements section of the use case description)

At the same time, when you determine the support goals, such as maintaining important business entities, exclude them, so that they are independent and use their own graph support case packages.

Figure 3: different target Layers

Principle 3: Use Demand attributes to determine the best use case model
Requirement attributes include requirement information. Priority: display a requirementForHow important business users are. Iteration: indicates the iteration to which the requirement is allocated. Stability: identify which requirements may be changed. There are more attributes, but let's focus on the above three attributes. Make sure that you are persistently capturing these attributes for your use case. Why? Because they can make your process easier. In particular, you will often have multiple choices about how to build the case model 11. When you do this, use the above attributes to locate your case model. This will produce the least refactoring effort and focus on your work.

In fact, consider the following guidelines to decide your choice:

1. If any of these guidelines violates principle 2 and lead to more use cases, do not apply the guidelines!
2. If two use cases have different priorities, avoid merging them.
3. If two use cases are allocated to different iterations, avoid merging them.
4. If the two use cases have different stability levels, avoid merging them.
5. Do not spend too much time on models that obtain unstable use cases; this feature may not need to be changed at all. Now, focus on the stable use case to get the correct model.

Remember: How you reconstruct the use case model will affect other work. Business users will have to find a method suitable for the new model, and tracking of different deliverable variables will also need to be updated. Building Models correctly from the very beginning will save other people's time.

In the above example, we firmly oppose merging the extension and pay-as-you-go functions into a single use case (for example, requesting to pay) because "Initial simpay development, yes, and there will also be delayed or direct payment "which may soon be generated; no matter which payment mechanism is selected, the other will be in the range of future versions. This type of case changes repeatedly, resulting in splitting into pay-as-you-go requests and delayed payment requests.

Principle 4: Decomposition and rules-decomposition by business participants
Now you have a well-structured and understandable business case model. Where are you going next? One important thing is thatNoBreak down functions into your use case model; that is, do not break your use case into a small part. This part will become isolated, one of the most important advantages of violating the use case steps: to present requirements in the target context of the participants. On the contrary, the answer is to apply it again recursively in the current context based on the Use Case steps.

Let's look back at figure 3. The simpay product context at the bottom shows the simpay product implemented by simpay Ltd., mobile operator and mobile business requestor. The terminology of the rational version of these entities isBusiness participants. These business participants work together to complete the functions of the simpay product. One, two, or all business participants participate in each simpay product use case. With this information, you can set the context for each business participant (by the simpay product ContextAllocateTo generate a context. Each context is established by the following two: (1) Dividing use cases by business participants, and (2) deriving new participants from existing business participants. This process is illustrated in figure 4, which shows an instance result for the mobile operator. A new mobile operator context with two use cases and a new participant (simpay Ltd.) has been derived from a higher abstraction layer. Now you can separate control (Mutual call) New context. 12

Is this different from functional breakdown? Yes! In the simpay product context (not inspired by the participant's goal), you have created a smaller domain with the precise goal presented by the new participant. Let's look at the results of the mobile operator context. Obviously, simpay has done these things on behalf of the mobile business demand side (representing traders in turn. However, the field of mobile operator is self-contained; it does not need to understand what the participants of simpay Ltd are doing. On the contrary, the Function Decomposition Method splits the use cases into many parts: obtaining commercial details, conducting foreign exchange transactions, authorizing payments, and capturing payments. Which method is more suitable for managing the scope of the solution?

Figure 4: Division of business participants.

Principle 5: use case description: State "what", rather than "how to do"
Fortunately, we have business representatives who are interested. They quickly adapted to the use case method and a competent technical team. Their goal is to automatically translate requirements into technical specifications. However, as it is generated, business representatives are motivated as much as possible by the status, and the tech team is uneasy about unnecessary restrictions imposed on them. Use Cases are used to describe what the product does to show the needs and achieve the goal of the participants. "What to doAndHow to do"Product activities between people, especially global distributed teams, are not clear. Misunderstanding is normal. There are four types of guidelines to help us avoid these errors:

1. Specific natural language expressions have technical connotations. (Loop, for example ). If you use these expressions, make sure they are not misunderstood as technical design recommendations.
2. Business Use Cases describe business flows; they determine who is the source of information and who is the target. They do not imply the technical implementation of the stream. There is no clear definition of whether information is to be pushed or pulled. Information exchange is batch or online and whether cache is used. Such technical decisions are mainly related to non-functional requirements. Determine that people understand the words in business use cases, such as contacts and requests. do not imply technical constraints for basic technical communication infrastructure.
3. Strive for a simple communication mode between participants and products. Try to follow the synchronous request/response 13 communication model. This implies that the response of a request is either received or not received when the case description is sustained (for example, timeout ). When the use case has moved forward in its description, it cannot accept the response. The request is fully expressed, and it simplifies the description. It should be emphasized that it does not imply the technical implementation of the same model.
4. When you number the use case step, people usually think that you are ordering how to complete the function. 14 however, the sequence of Use Case steps is generally only related to the next interaction of participants. When such a group of steps are hosted in a specific order, you are used to following the clear state.

It is important to exchange these guidelines. For simpay, we capture them in the Product overview document (see the sidebar. The Use Case model and guidelines document are the best suited for doing this in RUP. More importantly, if you are working on a custom process, you should have an experiment. Select a use case and try to align with the entire team so that everyone will be satisfied with how you will generate transactions and management expectations.

Principle 6: propose a domain model
In RUP, a domain model (see figure 5) is defined as capturing the most important type of objects in the domain context. The domain model is a subset of the business analysis model. The business analysis model contains the business case implementation that describes the business participants (see Principle 4) and how the business entity obtains the use case function. The domain model is useful even if you do not propose business use cases. It connects your use cases by providing general terms with precise meanings for your use case description. The domain model ensures that the same term points to the same business entity. The following types of requirements are also captured:

• The relationship between business entities and their diversity (for example, a mobile user uses one or more mobile phones)
• Restrictions (for example, a payment cannot exceed a specific value) and deduction rules (for example, interest calculation), especially when these are not just related to a use case

Structure your domain model document and add placeholders for this information (see figure 5. In my experience, business users are quite satisfied with the forms of these minor improvements, and it improves stability and completeness for you:

• Have all business entities and their attributes been defined?
• Have you captured all contacts?
• Are all involved business entities in at least one use case?
• Are all involved business entities included in the use case of the domain model?

When creating a domain model, you can use the following guidelines in addition to common sense and your reader preferences:

1. Use graphs to help describe, especially to show the relationships between business entities.
2. We would rather generalize redundancy. Otherwise, you can request it from your business users.
3. Use attributes for simple link types; otherwise, you will confuse your graph.
4. Ignore attributes when they are of a type that significantly avoids confusion.
5. If the identifiers (such as user IDs) are not commercial, ignore them.
6. They are used only when participant names help clarify the context. Otherwise, it means to name the business entity as a participant to avoid messing up your graph.
7. Simple navigation skills for related items. Domain models are often used to find information. For simpay, we use IBM Rational Rose to capture information for the domain model and IBM Rational soda to generate simple navigation documents.

How can a domain model be associated with a glossary? A glossary defines important terms used in a project. Based on this definition, a domain model is a subset of terms in the glossary. But avoid redundancy: Define an entry in the glossary or domain model, but not both. Generally, when you know more about your business domain, the term is transferred from the glossary to the domain model. However, your glossary is still a useful delivery product for terms that do not exist in the business entity.

Figure 5: domain model diagram and related text.

Principle 7: Use object Lifecycle
The entity lifecycle is not fully utilized in business specifications, but a good solution is available: UML state diagram. Why are you using these and how they are associated with use cases? A business entity (for example, a mobile user) usually has a life cycle across use cases. A case transition between States (usually different, the state chart gives a unified view about where your important business entities are and how they are manipulated. Figure 6 shows an example of a mobile user business entity. Transformation represents maintaining the mobile user's case 15 and converting it between different States.

As an analyst, you can also use a status chart to maintain the consistency and integrity of your demand set. How do my business entities become physical objects? Have I missed an important status? Have I described all the statuses of all transformations supported in my use case? Have I missed out on the special conditions that influence the transformation?

Define the lifecycle of the most important business object and describe all States in your document. Your use case will describe these States in terms of the correctly defined domain model, and remove ambiguity from your specification while maintaining readability. A use case description (involving the instances shown in Figure 6) is shown as follows:

4. The mobile operator confirms that the mobile user is not forbidden.

ThisProhibited statusIt specifies the status of a mobile user and shows a very precise definition of the status. Select dependency parameters. You can use the format to emphasize the status in the text.

It is best to place the lifecycle in the domain model as an appendix for coupling defined by the business entity (as shown in Figure 5. You can use IBM Rational Rose to maintain the state chart and document the state, and you can also use IBM Rational soda to generate documents that are easy to manipulate.

In this way, when you place the real life cycle before the business users, you can balance the benefits of using them, just like technician 16, without making demands.

A future survey: With model-driven architecture, 17 you will be independent of a specific platform, benefiting from pre-specified accuracy states. In addition, the runable UML will allow you to confirm your previous model before you begin to segment your needs at any cost.

Figure 6: status chart: mobile phone user-Lifecycle

Summary
Use Cases are an excellent way to capture business needs. As long as you define an appropriate abstraction layer to support all the details that are understandable and traceable, they can be well scaled through large projects. Adding only the number of use cases does not work. Business users who confirm your needs will be very comfortable with the case-based method. With regard to this method, elaborate on your automated business use cases to make it easier for technical teams to accept technical requirements.

Therefore, do not despair if you are assigned a complex business requirement project. By applying case methods to demand projects, a reliable development process and the principles presented in this article, and refining the supported methods, you can overcome many challenges and make the solution successful. As I have done, you may even have discovered that it is a satisfactory practice.

Thanks
I am very grateful to the people in simpay for their work in the methods described in this article. In particular, Tim Jones, Simon Richard, Martin rugfelt, and Jim Wadsworth. I am particularly grateful to my colleague Martin elliffe for providing helpful explanations and suggestions.

 

Footer
1. In this article, I use the demand project as a short name for the business demand project.

2. The example used in this article comes from the broad simpay context. Some have been simplified and used only to demonstrate the confidentiality of points and requirements. Therefore, please do not consider these examples as a real simpay activity.

3. For more information about the simpay business model, see www.simpay.com.

4. For more details about the RUP, see 《The Rational Unified Process., Addison-Wesley, 2000 and http://www-306.ibm.com/software/awdtools/rup/index.html.

5 The main obstacle to non-iterative delivery is the fact that it solutions and its operator are transferred from a third party and integrated into the entire process through a set of legal contracts. An iteration process adds significant complexity to these legal contracts.

6 Although it is not part of the standard 4 + 1 view associated with RUP, this view is basic. At the end, you have to sell your product.

7 There is a clear relationship between the two contexts. As part of purchasing product use cases in the commercial context, the commercial trigger payment request uses the example in the simpay context.

8. The Merchant determines that the mobile phone user can pay and reserve the currency for him.

9 The Merchant's request shall be paid to him.

10 In fact, you can even consider it further and have an independent payment request case: We did decide against it. The reason is range management, but continue to look down.

11 I am not here to discuss expansion and include contacts. In my experience, it is best to avoid these connections in your business case model.

12 《The object advantage(Addison-Wesley, pp. 1995, 173rd), e.a. jacbsen introduces an algorithm used to map a business case model to a system case model. A similar algorithm is used to map a business case model to another business case model in different contexts.

13 in a definite environment, you may have a request that does not respond. If the response has no business meaning, this is exactly the same as the proposed and used model.

14 on the contrary, I strongly recommend that you use a serial number style with a fine-grained texture as a case description. It allows you to improve consistency, integrity check, and reference.

15. If a use case is converted to a business entity in multiple States. You can switch to an alternative stream or a set of steps (for example, using a tag or a digital mark described in your use case ).

16. Let me emphasize that they may look like technicians, but they are not technicians because they only write business decision-making documents.

17 For more information about the mode-Driven Architecture, see http://www.omg.org/mda and behrens 《Statelator in Advanced Information Systems Engineering"Springer, 2000.

References

• For more information, see the original article on the developerworks global site.