Disciplines > Requirements
Rational Unified Process
Requirements: Activity Overview
Rational Unified Process
Introduction to Requirements
The purpose of the Requirements discipline is:
· To establish and maintain agreement with the customers and other stakeholders on what the system should do.
· To provide system developers with a better understanding of the system requirements.
· To define the boundaries of (delimit) the system.
· To provide a basis for planning the technical contents of iterations.
· To provide a basis for estimating cost and time to develop the system.
· To define a user-interface for the system, focusing on the needs and goals of the users.
To achieve these goals, it is important, first of all, to understand the definition and scope of the problem which we are trying to solve with this system. Stakeholders are identified and Stakeholder Requests are elicited, gathered and analyzed.
A Vision document, a use-case model, use cases and Supplementary Specification are developed to fully describe the system - what the system will do - in an effort that views all stakeholders, including customers and potential users, as important sources of information (in addition to system requirements).
Stakeholder Requests are both actively elicited and gathered from existing sources to get a "wish list" of what different stakeholders of the project (customers, users, product champions) expect or desire the system to include, together with information on how each request has been considered by the project.
The Vision document provides a complete vision for the software system under development and supports the contract between the funding authority and the development organization. Every project needs a source for capturing the expectations among stakeholders. The vision document is written from the customers' perspective, focusing on the essential features of the system and acceptable levels of quality. The Vision should include a description of what features will be included as well as those considered but not included. It should also specify operational capacities (volumes, response times, accuracies), user profiles (who will be using the system), and inter-operational interfaces with entities outside the system boundary, where applicable. The Vision document provides the contractual basis for the requirements visible to the stakeholders.
The use-case model should serve as a communication medium and can serve as a contract between the customer, the users, and the system developers on the functionality of the system, which allows:
· Customers and users to validate that the system will become what they expected.
· System developers to build what is expected.
The use-case model consists of use cases and actors. Each use case in the model is described in detail, showing step-by-step how the system interacts with the actors, and what the system does in the use case. Use cases function as a unifying thread throughout the software lifecycle; the same use-case model is used in system analysis, design, implementation, and testing.
The Supplementary Specifications are an important complement to the use-case model, because together they capture all software requirements (functional and nonfunctional) that need to be described to serve as a complete software requirements specification.
A complete definition of the software requirements described in the use cases and Supplementary Specifications may be packaged together to define a Software Requirements Specification (SRS) for a particular "feature" or other subsystem grouping.
A Requirements Management Plan specifies the information and control mechanisms which will be collected and used for measuring, reporting, and controlling changes to the product requirements.
Complementary to the above mentioned artifacts, the following artifacts are also developed:
The Glossary is important because it defines a common terminology which is used consistently across the project or organization.
The Use-Case Storyboard and User-Interface Prototype are all results of user-interface modeling and prototyping, which are done in parallel with other requirements activities. These artifacts provide important feedback mechanisms in later iterations for discovering unknown or unclear requirements.
The Requirements discipline is related to other process disciplines.
· The Analysis & Design discipline gets its primary input (the use-case model and the Glossary) from Requirements. Flaws in the use-case model can be discovered during analysis & design; change requests are then generated, and applied to the use-case model.
· The Test discipline validates the system against (amongst other things) the Use-Case Model. Use Cases and Supplementary Specifications provide input on requirements used in the definition of the evaluation mission, and in the subsequent test and evaluation activities.
· The Configuration & Change Management discipline provides the change control mechanism for requirements. The mechanism for proposing a change is to submit a Change Request, which is reviewed by the Change Control Board.
· The Project Management discipline plans the project and each iteration (described in an Iteration Plan). The use-case model and Requirements Management Plan are important inputs to the iteration planning activities.
· The Environment discipline develops and maintains the supporting artifacts that are used during requirements management and use-case modeling, such as the Use-Case-Modeling Guidelines and User-Interface Guidelines.
Rational Unified Process
Concepts: Requirements Management
Requirements management is a systematic approach to finding, documenting, organizing and tracking the changing requirements of a system.
We define a requirement as:
A condition or capability to which the system must conform.
Our formal definition of requirements management is that it is a systematic approach to
· eliciting, organizing, and documenting the requirements of the system, and
· establishing and maintaining agreement between the customer and the project team on the changing requirements of the system.
Keys to effective requirements management include maintaining a clear statement of the requirements, along with applicable attributes for each requirement type and traceability to other requirements and other project artifacts.
Collecting requirements may sound like a rather straightforward task. In real projects, however, you will run into difficulties because:
· Requirements are not always obvious, and can come from many sources.
· Requirements are not always easy to express clearly in words.
· There are many different types of requirements at different levels of detail.
· The number of requirements can become unmanageable if not controlled.
· Requirements are related to one another and also to other deliverables of the software engineering process.
· Requirements have unique properties or property values. For example, they are neither equally important nor equally easy to meet.
· There are many interested parties, which means requirements need to be managed by cross-functional groups of people.
· Requirements change.
So, what skills do you need to develop in your organization to help you manage these difficulties? We have learned that the following skills are important to master:
Problem analysis is done to understand problems, initial stakeholder needs, and propose high-level solutions. It is an act of reasoning and analysis to find "the problem behind the problem". During problem analysis, agreement is gained on the real problem(s), and who the stakeholders are. Also, you define what from a business perspective are the boundaries of the solution, as well as business constraints on the solution. You should also have analyzed the business case for the project so that there is a good understanding of what return is expected on the investment made in the system being built.
See also Workflow Detail: Analyze the Problem.
Requirements come from many sources, examples would be customers, partners, end users, and domain experts. You need to know how to best determine what the sources should be, get access to those sources, and also how to best elicit information from them. The individuals who provide the primary sources for this information are referred to as stakeholders in the project. If you’re developing an information system to be used internally within your company, you may include people with end user experience and business domain expertise in your development team. Very often you will start the discussions at a business model level rather than a system level. If you’re developing a product to be sold to a market place, you may make extensive use of your marketing people to better understand the needs of customers in that market.
Elicitation activities may occur using techniques such as interviews, brainstorming, conceptual prototyping, questionnaires, and competitive analysis. The result of the elicitation would be a list of requests or needs that are described textually and graphically, and that have been given priority relative one another.
To define the system means to translate and organize the understanding of stakeholder needs into a meaningful description of the system to be built. Early in system definition, decisions are made on what constitutes a requirement, documentation format, language formality, degree of requirements specificity (how many and in what detail), request priority and estimated effort (two very different valuations usually assigned by different people in separate exercises), technical and management risks, and initial scope. Part of this activity may include early prototypes and design models directly related to the most important stakeholder requests. The outcome of system definition is a description of the system that is both natural language and graphical.
See also Workflow Detail: Define the System.
To efficiently run a project, you need to carefully prioritize the requirements, based on input from all stakeholders, and manage its scope. Too many projects suffer from developers working on so called "Easter eggs" (features the developer finds interesting and challenging), rather than early focusing on tasks that mitigate a risk in the project or stabilize the architecture of the application. To make sure that you resolve or mitigate risks in a project as early as possible, you should develop your system incrementally, carefully choosing requirements to for each increment that mitigates known risks in the project. To do so, you need to negotiate the scope (of each iteration) with the stakeholders of the project. This typically requires good skills in managing expectations of the output from the project in its different phases. You also need to have control of the sources of requirements, of how the deliverables of the project look, as well as the development process itself.
The detailed definition of the system needs to be presented in such a way that your stakeholders can understand, agree to, and sign off on them. It needs to cover not only functionality, but also compliance with any legal or regulatory requirements, usability, reliability, performance, supportability, and maintainability. An error often committed is to believe that what you feel is complex to build needs to have a complex definition. This leads to difficulties in explaining the purpose of the project and the system. People may be impressed, but they will not give good input since they don’t understand. You should put lots effort in understanding the audience for the documents you are producing to describe the system. You may often see a need to produce different kinds of description for different audiences.
We have seen that the use-case methodology, often in combination with simple visual prototypes, is a very efficient way of communicating the purpose of the system and defining the details of the system. Use cases help put requirements into a context, they tell a story of how the system will be used.
Another component of the detailed definition of the system is to state how the system should be tested. Test plans and definitions of what tests to perform tells us what system capabilities will be verified.
No matter how careful you are about defining your requirements, there will always be things that change. What makes changing requirements complex to manage is not only that a changed requirement means that more or less time has to be spent on implementing a particular new feature, but also that a change to one requirement may have an impact on other requirements. You need to make sure that you give your requirements a structure that is resilient to changes, and that you use traceability links to represent dependencies between requirements and other artifacts of the development lifecycle. Managing change include activities like establishing a baseline, determining which dependencies are important to trace, establishing traceability between related items, and change control.
Rational Unified Process
More information on this topic can be found at:
A requirement is defined as "a condition or capability to which a system must conform".
There are many different kinds of requirements. One way of categorizing them is described as the FURPS+ model [GRA92], using the acronym FURPS to describe the major categories of requirements with subcategories as shown below.
The "+" in FURPS+ reminds you to include such requirements as:
(See also [IEEE Std 610.12.1990].)
Functional requirements specify actions that a system must be able to perform, without taking physical constraints into consideration. These are often best described in a use-case model and in use cases. Functional requirements thus specify the input and output behavior of a system.
Requirements that are not functional, such as the ones listed below, are sometimes called non-functional requirements. Many requirements are non-functional, and describe only attributes of the system or attributes of the system environment. Although some of these may be captured in use cases, those that cannot may be specified in Supplementary Specifications. Nonfunctional requirements are those that address issues such as those described below.
A complete definition of the software requirements, use cases, and Supplementary Specifications may be packaged together to define a Software Requirements Specification (SRS) for a particular "feature" or other subsystem grouping.
Functional requirements may include:
· feature sets
Usability requirements may include such subcategories as:
· human factors (see Concepts: User-Centered Design)
· consistency in the user interface (see Guidelines: User-Interface)
· online and context-sensitive help
· wizards and agents
· user documentation
· training materials
Reliability requirements to be considered are:
· frequency and severity of failure
· mean time between failure (MTBF)
A performance requirement imposes conditions on functional requirements. For example, for a given action, it may specify performance parameters for:
· response time
· recovery time
· resource usage
Supportability requirements may include:
· localizability (internationalization)
A design requirement, often called a design constraint, specifies or constrains the design of a system.
An implementation requirement specifies or constrains the coding or construction of a system. Examples are:
· required standards
· implementation languages
· policies for database integrity
· resource limits
· operation environments
An interface requirement specifies:
· an external item with which a system must interact
· constraints on formats, timings, or other factors used by such an interaction
A physical requirement specifies a physical characteristic that a system must possess; for example,
This type of requirement can be used to represent hardware requirements, such as the physical network configurations required.
Rational Unified Process
Traceability is the ability to trace a project element to other related project elements, especially those related to requirements. Project elements involved in traceability are called traceability items. Typical traceability items include different types of requirements, analysis and design model elements, test artifacts (test suites, test cases, etc.), and end-user support documentation and training material, as shown in the figure below.
The traceability hierarchy.
Each traceability item has its own unique set of associated attributes, which is useful for tracking the status, benefit, risk, etc. associated with each item.
The purpose of establishing traceability is to help:
· Understand the source of requirements
· Manage the scope of the project
· Manage changes to requirements
· Assess the project impact of a change in a requirement
· Assess the impact of a failure of a test on requirements (i.e. if test fails the requirement may not be satisfied)
· Verify that all requirements of the system are fulfilled by the implementation.
· Verify that the application does only what it was intended to do.
Traceability helps you understand and manage how input to the requirements, such as Stakeholder Requests, are translated into a set of key stakeholder/user needs and system features, as specified in the Vision document. The Use-Case model, in turn, outlines the how these features are translated to the functionality of the system. The details of how the system interacts with the outside world are captured in Use Cases, with other important requirements (such as non-functional requirements, design constraints, etc.) in the Supplementary Specifications. Traceability allows you to also follow how these detailed specifications are translated into a design, how it is tested, and how it is documented for the user. For a large system, Use Cases and Supplementary Specifications may be packaged together to define a Software Requirements Specification (SRS) for a particular "feature" or other subsystem grouping.
A key concept in helping to manage changes in requirements is that of a "suspect" traceability link. When a requirement (or other traceability item) changes at either end of a traceability link, all links associated with that requirement are marked as "suspect". This flags the responsible role to review the change and determine if the associated items will need to change also. This concept also helps in analyzing the impact of potential changes.
Traceabilities may be set up to help answer the following sample set of queries:
· Show me user needs that are not linked to product features.
· Show me the status of tests on all use cases in iteration #n.
· Show me all supplementary requirements linked to tests whose status is untested.
· Show me the results of all tests that failed, in order of criticality.
· Show me the features scheduled for this release, which user needs they satisfy, and their status.
For a Recycling Machine system, the Vision document specifies the following feature:
· FEAT10:The recycling machine will allow the addition of new bottle types.
This feature is traced to a use case "Add New Bottle Type":
· The use case Add New Bottle Type allows the Operator to teach the Recycling Machine to recognize new kinds of bottles.
This traceability helps us verify that all features have been accounted for in use cases and supplementary specifications.
The most important traceability items are:
Other elements, such as Issues may also be useful to trace.
A typical traceability is shown in the following diagram:
This diagram only shows traceability to requirements. Other traceability may exist as well, but is not shown on this diagram: design elements trace down to implementation components, there are test cases for design and implementation, etc.
Rational Unified Process
Concepts: Types of Requirements
Traditionally, requirements are looked upon as statements of text fitting into one of the categories mentioned in Concepts: Requirements. Each requirement states "a condition or capability to which the system must conform".
To perform effective requirements management, we have learned that it helps to extend what we maintain as requirements beyond only the detailed "software requirements". We introduce the notion of requirements types to help separate the different levels of abstraction and purposes of our requirements.
We may want to keep track of ambiguous "wishes", as well as
from our stakeholders
to make sure we know how they are taken care of. The Vision
document helps us keep track of key "user needs" and
"features" of the system. The use-case
model is an effective way of expressing detailed functional
"software requirements", therefore use
cases may need to be tracked and maintained as requirements, as well as
perhaps individual statements within the use case properties which state
"conditions or capabilities to which the system must conform". Supplementary
Specifications may contain other "software requirements", such
as design constraints or legal or regulatory requirements on our system. For
a complete definition of the software requirements, use
cases and Supplementary
Specifications may be packaged together to define a Software
Requirements Specification (SRS) for a particular "feature" or
other subsystem grouping.
Rational Unified Process
Concepts: Use-Case View
To provide a basis for planning the technical contents of iterations, an architectural view called the use-case view is used in the Requirements discipline. There is only one use-case view of the system, which illustrates the use cases and scenarios that encompass architecturally significant behavior, classes, or technical risks. The use-case view is refined and considered initially in each iteration.
The use-case view shows an architecturally significant subset of the use-case model, a subset of the use cases and actors.
The analysis, design, and implementation activities subsequent to requirements are centered on the notion of an architecture. The production and validation of that architecture is the main focus of the early iterations, especially during the Elaboration phase. Architecture is represented by a number of different architectural views, which in their essence are extracts illustrating the "architecturally significant" elements of the models.
The architectural views are documented in a Software Architecture Document. You may add different views, such as a security view, to convey other specific aspects of the software architecture.
So, in essence, architectural views can be seen as abstractions or simplifications of the models built, in which you make important characteristics more visible by leaving the details aside. The architecture is an important means for increasing the quality of any model built during system development.
Rational Unified Process
Concepts: User-Centered Design
There is no clear consensus on what constitutes user-centered design. However, John Gould and his colleagues at IBM developed an approach in the 1980’s called Design for Usability [GOU88] which encompasses most commonly-accepted definitions. It developed from practical experience on a number of interactive systems, most notably IBM’s 1984 Olympic Messaging System [GOU87]. The approach has four main components as described below.
Gould suggests that developers should decide who the users will be and to involve them at the earliest possible opportunity. He suggests a number of ways of becoming familiar with users, their tasks and requirements:
In the Rational Unified Process (RUP), workshops are used at several key stages, but these must be complemented by the kinds of activities Gould describes if an accurate picture is to be formed. (Part of the argument behind this is that people frequently describe what they do quite differently from how they do it. Commonly performed tasks and seemingly unimportant details such as placement of work or the existence of "mysterious" scraps of paper are often forgotten, or omitted because they are not "officially" part of the current process.)
Usability tasks should be performed in parallel early in development. These tasks would include sketching the user interface and drafting the user guides or online help. Gould also makes the point that usability should be the responsibility of one group.
An important feature of integrated design is that the overall approach – the framework – for detailed user-interface design is developed and tested at an early stage. This is an important difference between user-centered design and other purely incremental techniques. It ensures that incremental design carried out in later phases fits seamlessly into the framework and that the user interface is consistent in appearance, terminology and concept.
Within the RUP, this framework can be established by using a domain model to ensure that all terminology and concepts that will appear in the user interface are known and understood within the business in general and with users in particular. (There will also be subsets of the domain model that will be relevant only to specific groups of users. Care should be taken to ensure that the domain model is organized so that these subsets can be easily identified.) As user-interface design progresses in the requirements discipline, many of the domain classes will be represented as boundary classes in the interface. The boundary classes, and the relationships between them, should be consistent with the domain model and should be represented consistently through all parts of the system under design. (This not only assists users, but also improves reuse of user-interface components.)
Early user testing means early prototyping, typically drawings and mockups described as low-fidelity prototypes. Hi-fidelity prototypes will follow later in the process.
Mockups can be used in conjunction with use cases to write concrete scenarios of use for the system under design. These can take the form narrative, illustrated narrative (using the mockups for illustration), storyboards, walkthroughs (with users), and the basis of user focus groups. While these approaches are unfamiliar to many software developers, they are clearly more cost effective than the discovery of inappropriate design or misunderstood requirements once implementation is under way.
Object-oriented development has become synonymous with an iterative process. Iterative design is well-suited to problems that need a refinement of understanding and have changing requirements. Not surprisingly, iterative design is a key component of user-centered design. This is partly due to the changing needs of users over time, but also the inherent complexity of producing design solutions that can deal with diverse needs.
Note that in user-centered methods, iterative design takes place within an integrated framework. We deliberately avoid incremental development, outside of an agreed framework, that might lead to a “patchwork” solution.
Interactive systems rely on their ability to accommodate the needs of users for their success. This means not only identifying diverse user communities but also recognizing the range of skills, experience and preferences of individual users.
While it is tempting for developers and managers to feel that they understand user needs, this is seldom the case in practice. Attention is frequently focused on how users ought to perform tasks rather than how they prefer to perform them. In many cases the issue of preference is much more than simply feeling in control, although that is an important issue in itself. Preference will also be determined by experience, ability and the context of use. These issues are considered sufficiently important to the design process to warrant an international standard, [ISO 13407], entitled human-centred design processes for interactive systems. The standard and related issues are discussed in general terms in the remainder of this paper.
Users understand and interact with a system through its user interface. The concepts, images and terminology presented in the interface must be appropriate to users’ needs. For example, a system that allows customers to buy their own tickets would be very different to one used professionally by ticket sales staff. The main differences are not in the requirements or even the detailed use cases, but the characteristics of the users and the environments in which the systems might operate.
The user interface must also cater for a potentially wide range of experience along at least two dimensions, computer and domain experience, as shown in Figure 1 below. Computer experience includes not only general familiarity with computers, but also experience of the system under development. Users with little experience of either computers or the problem domain, in the near left corner of the figure, will require a substantially different approach in the user interface to expert users, shown here in the far right corner.
Figure 1: The effects of computer and domain experience on ease of learning versus ease of use
Beware that it is not a forgone conclusion that inexperienced users will become experts over time. A number of factors may conspire to prevent this, for example low frequency of use, low motivation or high complexity. Conversely some systems may have predominately expert users. Factors here might be training, high frequency of use or high motivation (job dependence). Some of these issues and their effects on user-interface design are shown in Table 1.
Table 1, Some factors affecting user-interface design
Interactive systems must either be designed to cater for an appropriate range of user experience and circumstances, or steps must be taken to restrict the design universe. For instance, training can be used to reduce the requirement for ease of learning in a complex system. Alternatively a system might be reduced in its scope in order that it better meets the core requirements of its users (a suggestion made by Alan Cooper in his book The Inmates Are Running the Asylum [COO99]).
As part of user-centered design, we need to consider the skills and physical attributes of users. These issues are now being increasingly embodied in legislation. This is mostly directed at accommodating users with disabilities. However, making systems accessible to a wider range of users is generally seen as benefiting the user community as a whole.
The table below shows the relevant legislation and resources for many parts of the world:
Table 2a, Disability-related legislation by country, region or body
Aside from legislation, user-centered design and user-interface design are increasingly becoming the subject of standardization as shown below.
Table 2b, ANSI and ISO user interface and user-centered design standards
Developing systems appropriate to user needs means a significant effort in requirements analysis. In user-centered design, this effort is focused on end users. They are later described in greater detail in the Requirements discipline as Actors.
However, a substantial point of emphasis in User-Centered design is that we understand the requirements of the real people who will fill the roles described in the artifacts mentioned above. In particular, we must avoid designing hypothetical humans for whom it is convenient to design software systems. The artifacts describing end users must be written only after substantial, first-hand contact with users. In user-centered design this first-hand contact is part of a process sometimes called contextual inquiry. Hugh Beyer and Karen Holtzblatt (in their book Contextual Design, [BEY98]) describe the premise of contextual inquiry as:
"...go where the customer works, observe the customer as he or she works, and talk to the customer about the work."
(Some concrete examples of this have already been listed under Focus on Users.) This approach is used not only to have a better understanding of system requirements, but also of the users themselves, their tasks and environments. Each have their own attributes and taken together are referred to as the context of use. They are detailed in the ISO standard for user-centered design, described below.
ISO’s Human-centered design processes for interactive systems [ISO13407] identifies the first step in design as understanding and specifying the context of use. The attributes suggested are:
Table 3: Context of use from ISO standard for user-centered design
It is useful to split the user context into its two constituent parts (user type and role) and then to consider the relationships between all four contexts:
Figure 2: Relationships between contexts
Figure 2 shows that every task is performed in a role taken by a user within an environment. These contexts correspond to the RUP artifacts as shown in Table 4.
Table 4, ISO user-centered design standard contexts and their the RUP artifacts
Each of these contexts could have a significant impact on the design of an appropriate user interface. As a result we are faced with a potentially large number of permutations. Even for a small system, there may be 2 environments (e.g. office and customer site), 3 types of user (sales novice, sales expert and management) and 6 roles (telephone sales assistant, external sales representative, etc.). That means up to 36 potential variations per task, although the set of realistic combinations is usually much smaller.
Clearly tasks must be described individually, but a single description is unlikely to be appropriate for all permutations. One approach is to factor the user and environment contexts into the role description. This is the solution adopted by Constantine and Lockwood [CON99]. It involves providing a separate "user role" for each significant permutation of role, user and environment, then naming the resulting user role with a descriptive phrase, rather that a simple noun. Compare, for example, the role “Customer” with the user roles “Casual Customer”, “Web Customer”, “Regular Customer” and “Advanced Customer”.
Each user role description includes details of the role itself plus its users (referred to as role incumbents) and environment. This approach can be adopted with the RUP by choosing actors that correspond to user roles.
The terms scenarios, use cases and essential use cases have a confusing degree of overlap and are used in different design approaches to mean slightly different things. For example, within the RUP "scenario" means a use-case instance; simply a specific "path" through the possible basic and alternative flows. However, it is common to find user-centered and user-interface design methods describing scenarios as stories of use, containing substantially more detail than just the flow of events. While this additional information may be irrelevant in later design phases, it does form part of the understanding of users, tasks and environments. Consequently, scenarios may be used extensively (in storyboarding and role playing) in the Business Modeling discipline, but the focus moves towards use cases in the Requirements discipline.
Figure 3 shows the nature of this overlap. The scale at the top incorporates a number of different factors that tend to vary together. For example, as purpose moves more towards requirements, structure usually becomes more formal. Essential use cases appear to the right of generic use cases because user roles make them slightly more specific (see the preceding section) and they have a more formal structure.
Figure 3: Overlap in concepts between scenarios and use cases in user-centered design
The differences between system use cases and essential use cases are best illustrated by example. Table 5 shows a use case from Constantine and Lockwood's Software for Use [CON99]:
Table 5: Generic use case for getting cash from an ATM
This example details the sequence of events between the actor and the system, with the vertical line between the two columns representing the user interface. Notice that while Constantine and Lockwood recommend this style for essential use cases, this particular use case is not an essential one. The reason is that it based on the syntactic detail of the interaction. That is, how the interaction takes place. An essential use case focuses on what the interaction is about (called the semantics). Table 6 is the essential version of the interaction.
Table 6: Essential use case for getting cash from an ATM
This use case captures the essence of the getting cash interaction. The User Action and System Response headings have been replaced by User Intention and System Responsibility to reflect the change in emphasis. Good interface design centers on user goals and intentions; these are often hidden in conventional use cases. Essential use cases are particularly useful if:
· there are few design constraints (for example, the implied design constraint of using bank cards is false)
· the system might be enhanced to use other means of identification (such as some kind of secure internet access)
· there is a desire to create Use Cases without design constraints, for potential reuse in projects that lack these constraints.
However, essential use cases do have their drawbacks. Perfectly straightforward use cases such as that in Table 5 can be subject to considerable debate when it comes to distilling their essence. For example, does inserting a card identify the customer or the account? In most existing ATMs, it is the later although Constantine and Lockwood have chosen to interpret this as identifying the customer. This may have been a deliberate decision in light of newer technology such as retina scanning and fingerprint identification, or it may have been an oversight. The consequences in this case is an additional choice that has to be made by customers who hold more than one account.
Another difficulty that essential use cases present is that they are not as suitable for review with end users and other stakeholders because of their abstract nature. Part of this problem stems from having to translate essential use cases back to a concrete form representing user actions. This can be done once a design model is available by writing scenarios that describe the interaction in concrete terms (similar in concept to a Use Case Realization, although concerned with user-system interaction rather than internal object collaboration).
In summary, building essential use cases may not a good idea if:
· the user interface technologies are intentionally highly constrained (for example, the system must accept bank cards)
· the time to required for the users to understand the more abstract use cases is outweighed by the expected benefits.
The RUP does not explicitly refer to essential use cases, but in the Activity: Model the User Interface, essential use cases are used as a starting point, then developed and augmented with usability requirements to create use-case storyboards, as explained in Guidelines: Use-Case Storyboard.
· Start by clarifying the use case itself - not its user interface. Start by keeping the description independent of the user interface, especially if the use case is unexplored. Then, later on, as the use case is understood, the flow of events storyboard can be augmented with user interface and usability aspects. [from Guidelines: Use-Case Storyboard]
This means removing all design or current implementation detail so that only the semantics—the meaning of the interaction—remain. Then, as various design alternatives are explored, syntactic detail—how the interaction takes place—is added to the essential use case as a type of realization. (Each alternative design is, in effect, a realization of the same essential use case.)
Rational Unified Process