.NET Solution Architectures: Gathering and Analyzing User Requirements
Date: Jul 4, 2003
Terms you'll need to understand:
Unified Modeling Language (UML)
Use cases
Usage scenarios
Globalization
Localization
Techniques you'll need to master
Creating use cases and use case diagrams
Developing usage scenarios
Gathering requirements needed to develop world-ready applications
The previous chapter covered methods for analyzing the current business state and identifying business requirements for the solution. There are many sources from which to collect information and ways to interpret this information. The next phase of the requirements process is to focus on gathering and analyzing users' specific requirements. In many ways, this phase can be one of the most challenging and frustrating aspects of developing a computer system (think of your "favorite" user). Because of time or resource constraints, you might need to start designing the system before you can adequately complete the requirements-gathering phase. You might encounter users who can't tell you what they want but still expect the perfect solution. The amount of information gathered during the requirements-gathering phase can, at times, be overwhelming or contradictory. To extend the lifespans of systems professionals and to address these issues, the development of systems applications evolved into the object-oriented approach.
Unified Modeling Language
To address the need for a commonly accepted method of object-oriented modeling, the Unified Modeling Language (UML) has been developed. The notations in UML are meant to be straightforward and consistent, and a minimal number of symbols are used. It was purposely designed to be readable on almost any medium, such as whiteboards, paper, or computer displays.
IN UML, nine types of diagrams are used to represent the various modeling viewpoints. Here, in alphabetical order, is a list of the various diagrams and a brief explanation of each:
Activity diagrams—These diagrams represent the behavior of an operation as a "set of actions" document. Activity diagrams document the logic of a single operation or method, a single use case, or the flow of logic for a business.
Class diagrams—These diagrams represent the static structure in terms of classes and relationships. The purpose of a class diagram is to depict classes within a model.
Collaboration diagrams—These diagrams are a spatial representation of objects, links, and interactions. They are useful for visualizing how several objects collaborate to complete a task.
Component diagrams—These diagrams describe software components and their relationships within the implementation environment.
Deployment diagrams—These diagrams represent the deployment of components on particular pieces of hardware. Deployment diagrams model the hardware used in implementing a system and the association between those hardware components.
Object diagrams—These diagrams represent objects and their relationships and correspond to simplified collaboration diagrams that do not represent message broadcasts.
Sequence diagrams—These diagrams are temporal representations of objects and their interactions. Sequence diagrams contain the same information as collaboration diagrams but emphasize the sequence of the messages instead of the relationships of the objects.
Statechart diagrams—These diagrams represent the behavior of a class in terms of states. Statechart diagrams emphasize the possible states of an object and the transitions between states.
Use case diagrams—These diagrams represent the functions of a system from the user's point of view.
Although all UML diagrams are important in some aspect of the development life cycle, use case diagrams, because they are considered such an integral part of gathering user requirements, are the only UML diagram explored in detail in this chapter.
Use cases use actions and reactions to describe the behavior of a system from a user's standpoint. They show the definition of the system's boundaries and the relationships between the system and the environment.
Even with these modern methods available, the most basic task of gathering requirements, talking to the users, is still the major source of gathering requirements. So to create use cases, you still need to sit down with expected users of the system and do a thorough analysis of the functions they need from the new system. Each use case corresponds to a specific kind of system use. A use case is an image of a system's functionality, which is triggered in response to the stimulation of an external actor.
An actor represents the role played by a person or thing that interacts with a system. Actors are represented in use case diagrams by little stick people who trigger the use cases. (Additional certification for drawing stick people might be available soon.)
The name of the actor describes the role the user plays. To determine who the actors are, observe the direct users of a system, those who are responsible for its use or its maintenance, and other systems that interact with the one you're gathering requirements for. The same person can play the roles of several actors.
CAUTION
The various concepts related to UML, data modeling, and actors as tools for gathering requirements have continued to gain momentum, so expect to see questions about these topics in the exam.
A good rule for determining what can be considered an actor is that they are usually the people and things outside a system, and they interact with the system by exchanging information. In this way, determining the actors also helps set the system's boundaries. There are four main categories of actors:
Principal actors—These are the people who use the main system functions.
Secondary actors—This category includes people who perform administration or maintenance tasks.
External hardware—These are the hardware devices, such as printers or scanning equipment, that are part of the environment in which the application will reside and must be used. These devices are most likely not the computers running the application.
Other systems—These are the other systems with which the system must interact.
In UML, a use case model is depicted in a diagram (see Figure 3.1). A use case diagram depicts the use cases and actors for a system. The use cases are represented as ellipses contained within the system. The two main pieces of information to determine when creating use cases are the actor's action and the expected result. (If there were any doubts, look at the diagram. I was serious about the stick people.)
Figure 3.1 A use case diagram.
Use cases are determined by observing and specifying, actor by actor, the interaction sequences (scenarios) from the user's standpoint. They are described in terms of the information exchanged and the way the system is used. A use case groups a family of usage scenarios according to a specific functional criterion. Use cases are abstractions of dialogue between the actors and the system: They describe potential interactions without going into the details of each scenario.
Use case diagrams represent use cases, actors, and relationships between use cases and actors. In UML, there are three types of links between actors and use cases:
-
The communicates or association relationship—The actor's participation is signaled by a solid line between the actor and the use case. This is the only relationship between actors and use cases. An action by the actor triggers the use case. Using the Billington Pharmaceuticals case study, an action by a customer, such as placing a phone call, triggers the pharmaceutical ordering process to begin (see Figure 3.2).
Figure 3.2 The communicates or association relationship.
-
The uses relationship—This type of relationship between use cases means that there is a shared activity between the connected use cases (see Figure 3.3). For example, using the Billington Pharmaceuticals case study, 75% of doctors have some type of online capability, but 25% have to use a telephone for ordering. Online processing and telephone ordering would have many similar behaviors, thus creating a uses relationship between the two use cases.
Figure 3.3 The uses relationship.
-
The extends relationship—This type of relationship between use cases means that the source use case extends the behavior of the target use case (see Figure 3.4). This relationship occurs when an extra step, dependent on a specific event occurring, might be needed to complete a process. For example, using the Billington case study again, one of the identified requirements is that the system must be able to generate e-mails for refill reminders and even contact physicians if the refill count reaches zero. This extra step of contacting the physician when the refill count is zero is an example of an extends relationship.
Figure 3.4 The extends relationship.
Usage Scenarios
Usage scenarios capture the system's requirements in the users' business context, using a narrative or story format. They also describe necessary tasks and serve to document the series of steps required to complete a business function. Usage scenarios and the use cases from which they are derived should describe an application's expected behavior in multiple business processes. Gathering this information requires sitting down with users and determining every possible scenario for a specific function. Documenting usage scenarios might seem tedious and not as much fun as drawing stick figures, but it is helpful in finding possible missing conditions.
The project team can use the usage scenarios to keep its focus on the real problem to be solved. Usage scenarios should also provide a conceptual description of what the application must do and provide the basis for the logical design of components in the application. Also, even if some previously undiscovered interaction is identified later, new use cases can be incorporated into the design.
To see how a usage scenario works, take the simple process of a customer logging on to the Billington Web site (see Figure 3.5) and walk through what a usage scenario might look like:
Figure 3.5 The logon function.
Finally, it is important to remember that the scope of use cases is not created while defining the system requirements and then forgotten. Use cases come into play throughout the development life cycle, from the requirements phase to system testing, through the analysis, design, implementation, and documentation stages. Besides, a good stick figure is a terrible thing to waste.
Developing World-Ready Applications
CAUTION
Being able to develop applications that can be easily distributed globally with little or no specialized development for each locale is a major selling point for adopting the .NET architecture, so expect exam questions involving globalization, localization, and Unicode.
The .NET Framework provides extensive support for developing world-ready applications. There are several advantages to designing and developing world-ready applications using .NET:
Worldwide revenue—The more cultures the application can support, the larger your user or customer base will be.
Support for new cultures can be added quickly—After completing the initial application, no additional development should be necessary to produce localized versions. Creating a localized version is the process of adapting an application to a particular culture/locale.
Resources will be used more efficiently—Making the goal of world-readiness a key business requirement from the beginning of the project lessens the number of development and testing resources. Retrofitting an application designed to support a single culture, such as U.S. English, so that it can support additional cultures is expensive.
The .NET Framework fully supports Unicode—Unicode is a character-encoding scheme that uses two bytes to represent every character, regardless of whether it's an ASCII character. This scheme is capable of encoding all known characters and is used as a worldwide character-encoding standard. The Unicode-related classes, such as Encoder and Decoder, that can convert between Unicode characters and other types of target character code pages reside in the System.Text namespace.
System.Globalization functionality—Another feature included in .NET is the System.Globalization namespace, which contains classes that define culture-related information, including language; country/region; calendars in use; format patterns for dates, currency, and numbers; and sort order for strings. Although the options available in the System.Globalization namespace are probably more relevant in the design and implementation phases, being aware that this feature is available is still important during requirements gathering.
Systems.Resources namespace—The classes needed to read and write compiled resources are located in the Systems.Resources namespace. These classes aid in creating world-ready applications. The ResourceManager provides access to culture-correct resources at runtime. The ResourceWriter writes resources to an output stream or file. The ResourceReader readsresource name-value pairs from resource files and streams. Finally, the ResourceSet stores all resources localized for a particular culture.
When determining the requirements for a world-ready application, you should divide the process into two areas, globalization and localization.
Globalization
Globalization is the process of designing and developing a software product that functions in multiple cultures and locales. A globalized application can correctly accept, process, and display a worldwide assortment of scripts, data formats, and languages. A truly global application is culture-neutral and language-neutral. The trick, then, in the requirements-gathering phase is to determine which requirements will work equally well for users from all cultures and regions that the application must support. The most efficient way to globalize these functions is to use the concept of cultures/locales. A culture/locale is a set of rules and a set of data that are specific to a given language and geographic area. This process involves two tasks:
Identifying the cultures/locales that must be supported
Designing features that support those cultures/locales
If your company already has an international market or plans on pursuing international customers, there are several important factors to consider when gathering your international requirements. The ultimate goal should be to develop one common application that offers customers a choice of languages and currencies. In the Billington Pharmaceuticals case study, there are more than 1,000 stores in the United States and Canada. Because Canada (usually considered a foreign country) has a different currency from the United States and, in some areas, its inhabitants speak a different language, the application developed for Billington Pharmaceuticals should follow the concept of globalization.
Although this requirement seems obvious, most companies choose to ignore this option or create several versions of their applications for different language sets. This is an excellent way of keeping their IT developers fully engaged, but it is not the most efficient use of resources. The goal should be to make it easy for customers to change language or currency without being directed to another application. The specific areas that the requirements-gathering phase should focus on include:
Character classification
Date and time formatting
Numeric and currency conventions
Sorting rules
Keyboard setup
The "Localization" section, later in this chapter, provides more detail about these areas.
Being sensitive to cultural and political issues is also especially important when designing world-ready applications. What is acceptable in one culture might be offensive to another; this fact should not be minimized. These are common items to avoid:
Slang expressions—Just as people in the United States get confused when people from the United Kingdom refer to an elevator as a "lift," terms such as "bottom-line" or calling someone a "turkey" can be confusing to people in other countries.
Colloquialisms—Avoid using phrases that are local to a single region or have different meanings in different areas. This is true even within the United States. For example, in certain parts of the United States, asking for a "pop" might get you a punch in the face; in other parts of the country, you might get a can of Coke.
Obscure phrasing—Be cautious of using sports terms, such as "homerun," that have other meanings well known in the United States, but mean nothing (or have an unintended meaning) in most other countries.
Bitmap images that could be considered offensive in some cultures—For example, an icon of an outstretched hand indicates "Stop!" in some countries, but is considered offensive in Greece.
Maps that might include controversial regional/national boundaries or flags—For example, showing a French flag to indicate that the application can switch to French might be considered offensive to people in Algeria, Belgium, and Canada.
Localization
The final step in building a world-ready application is localization, which is the process of customizing and adapting your application for a given culture/locale. Localization consists primarily of translating the user interface, using rules developed for specific cultures/locales. Most organizations make the mistake of attempting localization after the initial application is developed. This approach is expensive and causes inconsistencies among versions. It also usually requires international users to wait weeks or months to have a localized version available.
These are the major advantages of following the localization model:
The application will reach the market more rapidly.
Resources are used more efficiently.
The application is easier and less expensive to maintain.
The application will be more stable.
There are several specific areas in which requirements pertaining to localization need particular attention:
Character display—Some languages need more space to display text than English does. Consider this factor when gathering requirements, especially for messages, menus, dialog boxes, icons, and bitmaps. Remember, too, that not all languages are displayed left to right. Some languages, such as Hebrew and Arabic, are bidirectional, going right to left for text and left to right for numbers.
Currency and number formatting issues—The currency symbol can be a predefined symbol, such as the European euro (), or a combination of letters, such as DM for Germany's deutsche mark. The negative sign can be displayed in many different positions, depending on local requirements. Many countries use different combinations of decimal and thousands separators than we do in the United States. For example, in Germany the decimal separator is a comma and the thousands separator is a period. Most currencies use the same decimal and thousands separator as the numbers in the culture/locale. However, in some places in Switzerland, for example, the period is a decimal separator for Swiss francs (Sir. 127.54), but the comma is the decimal separator everywhere else (127,54).
Date and time formatting—Although all culture/locales display a date with the day, month, and year, their presentation order and separators vary greatly. In fact, there might be many differences between regions within the same country.
For displaying time, the biggest issue is whether a 12-hour or a 24-hour clock is used. Most European and Asian cultures/locales use the 24-hour clock instead of the 12-hour a.m./p.m. model used in the United States.
Sorting—Alphabetical order and conventions for sequencing items vary from culture to culture. For example, sort order can be case-sensitive or case-insensitive. It can be phonetically based or based on the appearance of the character. A world-ready application must be able to compare and sort data on a per-culture basis to support culture-specific and language-specific sorting conventions.
Keyboards—The layout of keyboards differs in some cultures. Some characters might not exist on some keyboards, which could be an important factor when assigning shortcut-key combinations. Some cultures, such as Eastern Europe and most Arabic-speaking countries, use more than one type of keyboard (although probably not at the same time).
Practice Questions
Question 1
Which of the following UML diagrams documents the logic of a single operation or method, a single use case, or the flow of logic of a business?
Class diagrams
Activity diagrams
Deployment diagrams
Statechart diagrams
Sequence diagrams
The correct answer is B. The purpose of an activity diagram is to document the behavior of an operation as a set of actions. The other diagrams represent other parts of the modeling process, so only answer B is correct. Use cases use actions and reactions to describe the behavior of a system from a user's standpoint. They show the definition of the system's boundaries and the relationships between the system and the environment. A use case is an image of a system's functionality, which is triggered in response to the stimulation of an external actor.
Question 2
Which of the following are benefits of use cases? (Choose three.)
Use cases use actions and reactions to describe the system's behavior from a user's standpoint.
Use cases show the definition of the system's boundaries and the relationships between the system and the environment.
Use cases show an image If a system's functionality when triggered by the actions of an external (user) actor.
Use cases show where automation will be required.
Use case diagrams show the sequence in which events in the system must occur.
The correct answers are A, B, and C. Use cases do not show a system at a technical level, so answer D is not correct. Use cases are not concerned with a sequence of events, but with the expected system response to specific triggers, so answer E is also not correct.
Question 3
Considering the use of actors in a use case diagram, which of the following statements is not true?
An actor represents the role played by a person or thing that interacts with a system.
Actors always represent people.
The name of the actor represents the role played by the user.
The same person can play the roles of several actors.
Determining the actors also sets the system's boundaries.
The correct answer is B. Actors can also represent external hardware and other systems.
Question 4
In the Billington Pharmaceuticals case study, which of the following situations would require creating a usage scenario?
The process to hire developers for the development project
Setting prices for the co-payment amounts
A Billington customer logging on to the Web site
Determining a new logo for the Web site
Implementing computer systems in participating doctors' offices
The correct answer is C. All the other responses are considered outside the scope of the project, so only answer C is correct.
Question 5
Which of the following statements about usage scenarios are true? (Choose three.)
Usage scenarios document the series of steps required to complete a business function.
Usage scenarios are depicted pictorially.
Usage scenarios capture requirements in the users' business context.
Usage scenarios are used only in the requirements-gathering phase.
Usage scenarios can be used to validate the design.
The correct answers are A, C, and E. Because usage scenarios are used to document a business function, capture requirements in the users' business context, and help validate the design, answers A, C and E are all correct. Because usage scenarios are depicted in a narrative format and are used in all phases, answers B and D are not correct.
Question 6
Which of the following is the type of use case that represents a relationship between an actor and a use case?
Uses relationship
Communicates relationship
Extends relationship
Functional relationship
Logical relationship
The correct answer is B. The communicates relationship is the only relationship that exists between actors and use cases.
Question 7
Which of the following is not a major advantage of using .NET to develop world-ready applications?
Support for new cultures can be added quickly.
The .NET Framework fully supports Unicode.
A feature of .NET is the System.Globalization namespace.
.NET enables you to create a different application for each country.
Resources are used more efficiently.
The correct answer is D. The main advantage of using .NET is that it enables you to have only one application that can easily function in multiple countries.
Question 8
Which of the following is the major goal of globalization?
Develop a unique application for each culture/locale.
Encourage the use of local colloquialisms.
Determine the language favored in each individual country.
Apply a currency exchange rate calculation to the application.
Create an application that is both culture-neutral and language-neutral.
The correct answer is E. By using many of the functionality options already available in the .NET Framework, specifically the System.Globalization namespace, creating a culture- and language-independent application is an achievable goal.
Question 9
Billington Pharmaceuticals will be developing an application distributed globally using the .NET architecture and specifically incorporating Unicode features of and classes available in the System.Globalization namespace. Assuming the infrastructure is implemented properly, which of the following common internationalization issues will be resolved by the available .NET architecture and require no additional development or research effort? (Choose two.)
Language displayed to the users
Allocation of adequate screen space to display all text regardless of language
Format patterns for dates, currency, and numbers
Preventing the display of offensive or misleading icons
Syntax checking to remove slang or obscure phrases
The correct answers are A and C. Based on the assigned locale, the correct language and format patterns will be chosen. Allocation of adequate screen space is a design or development issue, so answer B is not correct. Not allowing offensive icons and preventing slang and obscure phrases from being part of the application are research efforts, so answers D and E are also not correct.
Question 10
When developing localized versions of an application, which of the following statements are correct? (Choose two.)
The selected database management system has a major impact on developing localized versions.
Efforts to develop localized versions should begin only after the entire application has been developed and implemented.
To avoid having an application that won't work in some locales, knowing which keyboards can be used is important.
Applications that follow the localization model are easier and less expensive to maintain and are usually more stable.
One advantage of localization is that it converts all screen flow to be left-to-right and top-to-bottom.
The correct answers are C and D. The choice of a DBMS should be not be a localization issue, so answer A is not correct. Localization efforts should begin in the requirements-gathering phase and continue to be done in parallel with the system development phases, so answer B is not true. Localization must take into account that some locales do not follow left-to-right display rules, so answer E is not correct.
Need To Know More?
Microsoft Global Software Development Site (http://www.microsoft.com/globaldev/). Provides extensive reference material and a number of articles dealing with developing world-ready software.
ftp://ftp.microsoft.com/developr/msdn/newup/
glossary/.
Individual glossaries for all Microsoft localized products are available for
download.
MSDN Online Certified for Windows Program
(http://msdn.microsoft.com/library/en-us/vsent7/html/vxconDesigningAccessible
Applications.asp).
For more information on designing accessible applications.
http://msdn.microsoft.com/certification/
default.asp.
For more information on the Certified for Windows program.
For more information about usage scenarios, search online for "usage scenarios" in MSDN Library Visual Studio 6.0.
Valacich, Joseph S., Joey F. George II, and Jeffery A. Hoffer III. Essentials of Systems Analysis and Design. Upper Saddle River, NJ: Prentice Hall, 2000.
Cooper, Alan and Paul Saffo. The Inmates Are Running the Asylum. Indianapolis, IN: Sams, 1999.
Symmonds, Nick. Internationalization and Localization Using Microsoft .NET. Berkeley, CA: Apress, 2002.
Kaplan, Michael K. Internationalization with Visual Basic. Indianapolis, IN: Sams, 2000.