Date: February 19, 2004
Analyzing Requirements and Defining Microsoft.NET Solution Architectures, Part III...
Gathering and analysing requirements (user).
Date: February 19, 2004
The aim of this series of articles is to provide an overview of issues surrounding the architecture of .NET Solutions. In doing so we are loosely following Microsoft’s recommended approach and, in particular, looking at the requirements of the related Microsoft certification exam (70-300), which itself is one of the requirements for the MCSD .NET qualification. The main reference for this series of articles is the Que publication: 'Exam Cram2 .NET Solution Architectures'.
We've looked at the following thus far:
Article I: phase 1 of the process, the Envisioning Phase.
Article II: started on phase 2 (gathering and analysing requirements) focussing on business requirements.
In this third article we turn our attention to the differing view of requirements provided by focussing on the user's perspective and introduce the notation that is UML (Unified Modelling Language). We're also going to take a quick look at the issues surrounding globalisation and localisation of your application.
Whereas the last topic focused on business requirements this section focuses on the user more explicitly. This can be thought of as a more detailed specific view of the requirements already captured. It can be difficult dealing with users; for example often they will be unable or unwilling to tell you what they want but still expect you to deliver a perfect system. Frequently you will find one user of your system desires a set of attributes at odds with the last individual you interviewed. However, users are key during each phase of the project lifecycle and should be involved as much as possible. Saying this, it is also important to balance specific user requirements against the overall business goals of the project.
UML provides a standard for object-oriented modelling as well as a proven tool for analysis and design of software systems, having become something of an industry standard over the last decade or so. Here I'll present a brief overview of UML. Look out for future articles on DotNetJohn for a more detailed look at UML. Please let me know if this would interest you via chris.sully@cymru-web.net.
The notations in UML are meant to be straightforward and consistent with a minimal number of symbols being used. Nine type of diagrams are used to represent the various modelling viewpoints which collectively allow a complete representation of the system:
activity diagrams: represent a single operation as a set of actions. They document the logic of a single operation or method, a single use case, or the flow of logic for a business.
use case diagrams: represent the functions of the system from a user’s point of view.
class diagrams: represent the structure of the model in terms of classes and relationships.
collaboration diagrams: spatial representations of objects, links and interactions useful of visualising how several objects collaborate to complete a task
sequence diagrams: temporal representations of objects and their interactions, containing the same information as collaboration diagrams but emphasizing the sequence of messages rather than the relationships between objects.
object diagrams: represent objects and their relationships and correspond to simplified collaboration diagrams that do not represent message broadcasts
statechart diagrams: represent the behaviour of a class in terms of states, emphasizing the possible states of an object and the transitions between states.
component diagrams: describe software components and their relationship within the implementation environment
deployment diagrams: represent the deployment of components on particular hardware, modelling the hardware used in implementing a system and the association between the hardware components.
UML is pervasive across the majority of a project lifecycle. As we're currently focussing on analysis activities you will recognise that several of the above diagrams are not applicable. Key when it comes to user requirements are use case diagrams, though others amongst the above, e.g. collaboration diagrams, are also useful providing additional information that feeds back into the use cases. However, we shall focus on providing an overview of use cases and the related usage scenarios for the purposes of this article.
Use cases are exactly that – cases of system usage, describing the behaviour of a system from the users perspective via their actions and reactions. To create use cases you need to sit down with expected users of the system and undertake a thorough analysis of the functions they need from the new system. Each use case corresponds to a specific system use that is triggered by an actor.
An actor represents the role of a user (person or thing) that interacts with the system with the name of the actor describing the role the user plays. To determine the actors observe the direct users of a system, those responsible for its use and maintenance and other systems that interact with your system. Note that the same person can assume of the roles of several actors.
Actors usually exist outside the system, interacting with the system by information exchange. Thus you can see that determining the actors also assists in determining the system boundary. There are four main categories of actors:
principal: use the main system functions
secondary: includes people who perform administrative or maintenance tasks
external hardware: e.g. printers, scanners; not the devices actually running the system.
other systems
In UML a use case model is depicted via a diagram showing the use cases and actors of a system. The use cases are represented by ellipses within the system boundary. A very simple example of the diagrammatic notation is:
So for example, you might have a 'customer actor' of a 'drinks machine' system who can use the 'buy drink' use case. Another actor in this problem domain might be a collector actor who collects the money from the machine on a daily basis. Considering the problem decomposition further, what happens if the customer puts his money in, selects a drink but the system doesn't deliver his can. To deal with these we can break the top-level diagram down hierarchically to the required level of the detail with the help of usage scenarios (see below).
The two key pieces of information to determine when creating use cases are the actor’s action and the expected result.
Use cases are determined by observing and specifying, actor by actor, the interaction sequences (scenarios) from the user's point of view. 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. They are abstractions of dialog between the actor and the system. They describe potential interactions without going into the details of each scenario.
Use case diagrams also represent the relationships between use cases and actors via three types of link:
the communicates or association relationship (solid line): the only relationship between actors and a use case; an action by the actor triggers the use case
the uses relationship (solid arrow with 'uses'): there is a shared activity between the connected use cases; for example telephone and web ordering will have much in common.
the extends relationship (solid arrow with condition): the source use case extends the behaviour of the target. This relationship occurs when an extra step, dependent on a specific event occurring, might be needed to complete a process, e.g. when stock levels reach zero, get more stock.
Usage scenarios capture the system's requirements in the user's business context using narrative. They describe the necessary series of steps required to complete a business function. They derive from use cases to more completely describe the system, and may identify further use cases that require consideration. For example, 'report the machine defective' from the example above.
The process of defining use cases and usage scenarios provide a conceptual description of what the new system should do and provide the basis for the logical design of components in the application. As the process uses narrative one of its strengths is the ability to directly involve the user and stakeholders.
Note that UML/ use cases come into play in all stages of the project lifecycle from requirements to testing meeting design, implementation and documentation along the way. For example, you can directly derive testing scenarios from your use cases. W'’ve only had the opportunity to skim the surface of a complex topic that justifies a series of articles to itself, a task which I'll no doubt return to in the near future.
The support in .NET for localisation and globalisation of applications is a key benefit of .NET. Though requiring a little more effort initially there are several advantages to considering and implementing such requirements:
Support comes from several areas:
Unicode support: related classes such as Encoder and Decoder reside in the System.Text namespace.
System.globalisation namespace: includes classes that define culture related information including language, country/region; calendars; date, currency and number formatting; sort order for strings
System.Resources: includes classes to read and write culture-specific compiled resources
When determining the requirements for a world ready application you should divide the process into two areas: globalisation and localisation.
This is the process of designing and developing a software product for multiple cultures and locales. Each culture/ locale specifies a set of rules and a set of data that are specific to a given language and geographic areas. Thus the process involves:
The requirements gathering phases should focus on:
Additionally, being sensitive to cultural and political issues is also especially important when designing world ready applications. Key areas to consider are slang, colloquialisms, possibly offensive images and possibly controversial maps.
This is the actual customisation of your application to support a given culture/ locale. This consists primarily of translating the UI and enforcing the rules developed for specific culture/ locales. If sensible you'll factor in the localisation requirements early in the design of the application – localisation after the initial application is developed is expensive. You'll also experience the same advantages you would achieve with a well-designed application: fast total development time, efficient use of resources, lower cost of maintenance and greater stability.
See my article on Globalisation and Localisation in .NET for further information ( http://www.dotnetjohn.com/articles/articleid59.aspx ).
UML/ use cases and usage scenarios provide an excellent method of capturing user requirements in a form that is easily communicable and verifiable with the users themselves. Further, the resultant information when captured using a suitable tool such as Microsoft Visio or one of the Rational products facilitates transfer of the information through the design and implementation phases. I've barely skimmed the surface of UML here but hopefully I've piqued your interest and you'll now go elsewhere to investigate in more detail. Alternatively, let me know of this interest and I'll write a series of articles on the subject.
Also introduced was the importance of considering the geographical and cultural spread of your users during the requirements analysis phase.
Exam Cram 2 .NET Solution Architectures
Cornish et al.
Que
http://msdn.microsoft.com/architecture/
Teach Yourself UML
Sams
Joseph Schmuller
Professional UML with VS.NET
Wrox
Filev et al.