Supplementary Requirements: Hapter

C HAPTER 7
Supplementary
Requirements
The true goal of requirements engineering is not to create documentation; it is to

convey ideas from project stakeholders to developers.
Modern-day businesses are complex, as are the systems that support them.
To make matters worse, there are various aspects to the complexities. For ex-
ample there are business complexities that you need to understand, technical
complexities, even constraints imposed on you by outside authorities. The
implication is that you need techniques with which to explore these com-
plexities, techniques that produce something that I will call “supplementary
requirements” in this book. Table 7.1 summarizes the supplementary require-
ments artifacts described in this chapter.
This chapter discusses
r Business rules;
r Technical requirements;
r Constraints;
r Object constraint language (OCL);
r Glossaries; and
r Supplementary specifications.
209
Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:04:32, subject to the Cambridge Core terms of use, available at
Cambridge Books Online © Cambridge University Press, 2010
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.010
210 SUPPLEMENTARY REQUIREMENTS
TABLE 7.1. Supplementary Requirements Artifacts

Artifact Description
A business rule defines or constrains one aspect of

Business rules your business that is intended to assert business
structure or influence the behavior of your
business. Business rules often supplement usage or
user interface requirements.
A constraint is a restriction on the degree of freedom
Constraints you have in providing a solution. Constraints will
supplement other development artifacts, in
particular architecture and design-oriented
models.
A glossary is a collection of definitions that
Glossary supplements a wide range of development artifacts
by defining a common business and technical
vocabulary.
A technical requirement pertains to the technical
Technical aspects that your system must fulfill, such as
requirements performance-related, reliability, and availability
issues. Technical requirements are often the main
driver of your technical architecture (Chapter 10).
7.1 BUSINESS RULES
A business rule defines or constrains one aspect of your business that is in-
tended to assert business structure or influence the behavior of your business.
Business rules often focus on access control issues; for example, professors
are allowed to input and modify the marks of the students taking the seminars
they instruct, but not the marks of students in other seminars. Business rules
may also pertain to business calculations, for example, how to convert a per-
centage mark (for example, 91 percent) that a student receives in a seminar
into a letter grade (for example, A-). Some business rules focus on the policies
of your organization; perhaps the university policy is to expel for one year
anyone who fails more than two courses in the same semester.
Figure 7.1 summarizes several examples of business rules. Notice how
each business rule has a unique identifier. My convention is to use the format
of BR#, but you are free to set your own numbering approach. The unique
7.1 Business Rules 211
TIP
You Need Multiple Models
The requirements for a system are typically complex, dealing with a wide variety
of issues. Because every model has its strengths and weaknesses no one single
model is sufficient for your needs; therefore you will need several types of models
to get the job done.
identifier enables you to refer easily to business rules in other development

artifacts, such as class models and use cases. You saw an example of this in
the use cases of Chapter 5.
In some situations you will discover that business rules can be described
very simply, perhaps with a single sentence. In other situations this is not the
case. Figure 7.2 presents one way to fully document BR123. There are several
sections in this figure:
r Name. The name should give you a good idea about the topic of the business
rule.
r Description. The description defines the rule exactly. Although I used
text to describe this rule it is quite common to see diagrams such as
flow charts or UML activity diagrams (Chapter 6) used to describe an
algorithm. Other options include business rule languages such as ob-
ject constraint language (OCL) (http://www.omg.org), the ILOG rules lan-
guage (http://www.ilog.com), or business rules markup language (BRML)
(http://xml.coverpages.org/brml.html). As agile modeling (Chapter 4) sug-
gests, apply the right artifact for your situation.
r Example (optional). An example of the rule is presented to help clarify it.
r BR123 Tenured professors may administer student grades.

r BR124 Teaching assistants who have been granted authority by a tenured
professor may administer student grades.
r BR177 Table to convert between numeric grades and letter grades.
r BR245 All master’s degree programs must include the development of a
thesis.
FIGURE 7.1. Example business rules (summarized).
Name: Tenured professors may administer student grades

Identifier: BR123
Description: Only tenured professors are granted the ability to
initially input, modify, and delete grades students
receive in the seminars that they and they only
instruct. They may do so only during the period a
seminar is active.
Example: Dr. Bruce, instructor of “Biology 301 Advanced
Uses of Gamma Radiation,” may administer the
marks of all students enrolled in that seminar, but
not those enrolled in “Biology 302 Effects of
Radiation on Arachnids,” which is taught by Dr.
Peters.
Source: University Policies and ProceduresDoc ID:
U1701Publication date: August 14, 2000
Related rules: BR12 Qualifying for TenureBR65 Active Period for
SeminarsBR200 Modifying Final Student Grades
Revision History: Defined March 2, 2001, by D. Prince. Updated
October 10, 2001, by G. Stacy to reference-related
rule BR200.
FIGURE 7.2. A fully documented business rule.
r Source (optional). The source of the rule is indicated so it may be verified

(it is quite common that the source of a rule is a person, often one of your
project stakeholders, or a team of people).
r Related rules (optional). A list of related business rules, if any, is provided
to support traceability between rules.
r Revision history (optional). An indication of the date a change was made,
the person who made the change, and a description of the change.
Figure 7.2 is clearly a lot wordier than most project teams need. A more
agile approach would be to simply write the name of the business rule, the
business rule number, and the description on an index card and leave it at
that. Or you might want to get a little fancier and type the business rule into
a Wiki page (http://www.wiki.org) or a word processor. Remember to keep
your models as simple as possible.
Business rules are identified in the normal course of requirements gathering
and analysis. While you are usage modeling, perhaps with use cases or user
7.1 Business Rules 213
TIP
You Only Need a Subset of the Models
When you fix something at home you will only use a few of the tools, such as a
screwdriver and a wrench, in your tool box. The next time you fix something you
will use different tools. Even though you have multiple tools available, you will
not use them all at any given time. It is the same thing with software development;
although you have several techniques in your “intellectual toolbox” you will only
use a subset on any given project.
stories, you will often identify business rules. A rule of thumb is if something
defines a calculation or operating principle of your organization then it is
likely a good candidate to be documented as a business rule. You want to
separate business rules out from your other requirements artifacts because
they may be referred to within those artifacts several times. For example,
BR129 was referenced by the Enroll Student in Seminar use case and likely
would be referenced by your class models (Chapter 6) and perhaps even your
source code. However, if you have only a handful of business rules or use
cases, you may choice to document them right in the use cases. A rule of
thumb: start out including them in the use cases until it becomes obvious, or
painful, to do so. This may be because the sheer number of business rules is
dominating the use case or because the same business rule is referenced in
two or more use cases.
A good business rule is cohesive: in other words, it describes one, and only
one, concept. By ensuring that business rules are cohesive, you make them
easier to define and increase the likelihood they will be reused (every time
one of your artifacts refers to a business rule, even other business rules, it is
effectively being reused). Unfortunately, because business rules should focus
on one issue, you often must identify a plethora of rules.
Ross (2003) describes several basic principles of what he calls “the business
rule approach.” He believes that rules should
r Be written and made explicit;

r Be expressed in plain language;
r Exist independent of procedures and workflows (e.g., multiple models);
r Build on facts, and facts should build on concepts as represented by terms
(see Section 7.5, Glossaries);
r Guide or influence behavior in desired ways;
r Be motivated by identifiable and important business factors;
TIP
Use the Terminology of Your Stakeholders
Do not force artificial, technical jargon onto your project stakeholders. They are
the ones doing the modeling and they are the ones the system is being built for;
therefore, you should use their terminology to model the system. As Constantine
and Lockwood (1999) say, avoid geek-speak.
r Be accessible to authorized parties (e.g., collective ownership);

r Be single sourced;
r Be specified directly by those people who have relevant knowledge (e.g.,
active stakeholder participation); and
r Be managed.
Many business rules can actually be thought of as constraints (see Section

7.3), and in fact constraints can apply to either technical or business issues. In
the UML business rules are often described on diagrams using OCL (Warner
and Kleppe 1999), which can add to people’s confusion regarding the differ-
ences between the two concepts. Don’t worry about it. The important thing
is to identify and understand the requirement, not categorize it.
7.2 TECHNICAL REQUIREMENTS
A technical requirement pertains to the technical aspects that your system

must fulfill, such as performance-related issues, reliability issues, and avail-
ability issues. These types of requirements are often called service-level re-
quirements or nonfunctional requirements (I do not like that term as it makes
them sound like requirements that will not work). Examples of technical re-
quirements are presented in Fig. 7.3. As you can see, technical requirements
are summarized in a manner similar to that of business rules: they have a
name and a unique identifier (my convention is to use the format TR#, where
TR stands for technical requirement). You document technical requirements
in the same manner as business rules, including a description, an example, a
source, references to related technical requirements, and a revision history.
I am a firm believer that you should minimize the number of purely techni-
cal requirements. Technology changes quickly and often requirements based
on technology change just as quickly. An example of a pure technical re-
quirement is that an application be written in Java or must run on the XYZ
7.3 Constraints 215
r TR34 The system shall be available 99.99 percent of the time for any 24-
hour period.
r TR78 A seminar search will occur within less than three seconds 95 per-
cent of the time.
r TR79 A seminar search will occur within no more than ten seconds 99
percent of the time.
FIGURE 7.3. Potential technical requirements for the university system.
computer. Whenever you have a requirement based purely on technology, try

to determine the real underlying business needs being expressed. To do this,
keep asking why your application must meet a requirement. For example,
when asked why your application must be written in Java, the reply was it
must run on the Internet. When asked why it must run on the Internet, the
reply was your organization wants to take orders for its products and ser-
vices on the Internet. The real requirement is to sell things to consumers at
their convenience; one technical solution to this need (and a good one) is
to write that component in Java that can be accessed via the Internet. A big
difference exists between having to write the entire application in Java and
having to support the sales of some products and services to consumers over
the Internet.
Many technical requirements can actually be thought of as constraints (see
Section 7.3) and in fact constraints can apply to either technical or business
issues.
7.3 CONSTRAINTS
A constraint is a restriction on the degree of freedom you have in providing

a solution (Leffingwell and Widrig 2000). Constraints are effectively global
requirements, such as limited development resources or a decision by senior
TIP
Requirements Must Be Prioritized
Your project stakeholders must prioritize the requirements, enabling you to
constantly be working on the most important requirements and thus provide the
most value for their IT investment.
r C24 The system will work on our existing technical infrastructure—no

new technologies will be introduced.
r C56 The system will only use the data contained in the existing corporate
database.
r C73 The system shall be available 99.99 percent of the time for any 24-hour
period.
r C76 All master’s degree programs must include the development of a thesis.
FIGURE 7.4. Potential constraints for the university system.
management that restricts the way you develop a system. Constraints can be
economic, political, technical, or environmental and pertain to your project
resources, schedule, target environment, or to the system itself. Figure 7.4
presents several potential constraints for the university system. Like business
rules and technical requirements, constraints are documented in a similar
manner.
An interesting thing about Fig. 7.4 is that it contains two constraints, C73
and C76, which were previously identified as a technical requirement and a
business rule, respectively. Constraints can be a little confusing because of
their overlap with business rules and technical requirements. Don’t worry
about it. The important thing is that you have identified the requirement. If
you happen to miscategorize it as a constraint instead of a business rule that
is perfectly okay; the world is not going to end as a result (unless of course
you are working on a nuclear missile guidance system). I would not identify
the same requirement as both a business rule and a constraint—that would be
busy work—but I would not waste any time arguing over whether something
is a constraint or another type of requirement.
As with business rules, you identify constraints as you are developing other
artifacts, such as your use case model and user-interface model.
7.4 OBJECT CONSTRAINT LANGUAGE (OCL)
One way to describe business rules, technical requirements, or constraints

is via the object constraint language. The OCL is a formal language simi-
lar to structured English to express side-effect-free constraints within UML
models (Warner and Kleppe 1999). OCL can appear on any UML diagram
or in the supporting documentation describing a diagram, such as business
7.5 Glossaries 217
rule definitions. OCL can be used for a wide variety of purposes, including
specifying the invariants of classes, preconditions and postconditions on op-
erations, and constraints on operations. The reality is that a graphical model,
such as a UML class diagram, is not sufficient for a precise and unambiguous
specification. You must describe additional constraints about the objects in
the model, constraints defined in your supplementary specification.
I rarely use OCL when I am modeling. First, few people know how to
read OCL, let alone write it, so you are restricting the audience of your mod-
els when you use it. Second, it is complex. OCL statements are depicted on
UML diagrams in the format “{constraint description},” where the constraint
description may be in any format, including predicate calculus. I personally
find that free-form text, along the lines of Fig. 7.2, is far more effective. Third,
if I want to describe rules in such a way that I can generate working soft-
ware from them I will use a real programming language such as Java or C#
to do it.
The OCL was an interesting concept but it has not been adopted by the
industry. Because it shows no signs of being adopted any time soon, in my
opinion it is not worth the effort to learn.
7.5 GLOSSARIES
A glossary is a collection of definitions of terms, an example of which is

presented at the back of this book. Every company has its own specialized
jargon, and you need to understand it if you want to communicate effectively
with the experts with which you working.
You may want to include both technical and business terms in your glos-
sary. Although you may understand what terms such as XP, C#, J2EE, and
application server all mean your stakeholders likely do not. Similarly your
stakeholders may understand what business terms such as convocation, grant,
and transcript mean, but some developers may not. A glossary that includes
TIP
Reuse Existing Resources
Your organization may already have an existing glossary in place; if so then reuse
appropriate terms from it. Often your industry will already have a specialized
dictionary describing common terms that you may want to adopt as well.
both the relevant technical and business terminology goes a long way to im-
proving the communications between developers and users—if you do not
understand each other’s language you cannot communicate effectively.
The best advice that I can give about creating a glossary is to be realistic.
You are not Webster’s—you do not have to get the definitions perfect, they just
need to be good enough. Furthermore, dictionaries have multiple definitions
for most words so do not be afraid to do the same. Ideally you want a single
definition; realistically it often is not worth the effort to argue it out if it is
even possible to come to agreement.
An important issue with glossaries, with all artifacts for that matter, is to
make them available to people. This is one of the reasons AM includes the
display models publicly practice. You might want to consider documenting your
glossary as a single HTML page that everyone can access and hopefully edit
(remember the practice of collective ownership). Another option, particularly
if editing a major concern, is to use a Wiki (http://www.wiki.org).
7.6 SUPPLEMENTARY SPECIFICATIONS
A supplementary specification is a RUP document that contains requirements

not contained directly in your use cases. This often includes business rules,
technical requirements, and constraints. The best way to think of a supple-
mentary specification is that it is a container into which you place other
requirements. In my opinion supplementary specifications are not models in
their own right but instead are the documentation of models.
7.7 WHAT YOU HAVE LEARNED
Successful software systems are based on requirements, and because mod-

ern software systems are complex you need a wide variety of techniques to
address this complexity. In this chapter you were introduced to several re-
quirements modeling techniques—business rules, constraints, and technical
requirements. You also saw how these techniques could be applied in an ag-
ile manner, by working closely with your stakeholders (some techniques can
be applied by the stakeholders themselves), and by taking an iterative and
incremental approach to development.
In addition to understanding the technical aspects of requirements gather-
ing, the philosophical aspects are also critical. You learned that your project
7.8 Review Questions 219
stakeholders are the best source of requirements because they are the experts.
You also learned that requirements have nothing to do with the development
paradigm you are following—any of these techniques could be used with ob-
ject technology, component technology, structured technology, or any other
technologies.
7.8 REVIEW QUESTIONS
1. Identify the three most important business rules referenced by your use
cases in Question 2 of Chapter 5 and describe them appropriately.
2. What were the benefits of developing the three models of Questions 1
through 3 of Chapter 5 in parallel? Discuss, from the point of view of the
quality of the requirements, their consistency and their reliability.
3. Discuss the term “supplementary specification.” Is it a good name? Discuss
the subconscious implications of the name.
4. How are essential use cases, essential user-interface prototypes, and busi-
ness rules interrelated? Discuss from the point of view of the changes you
made to the three models from Questions 1 through 3 of Chapter 5. What
are the strengths and weaknesses of each technique? Do you need all of
them?
5. Compare and contrast small development groups of three or four peo-
ple versus larger development groups of ten to twenty people. Take into
consideration management issues, communication issues, logistical issues,
decision-making ability, group dynamics, skills, and knowledge. What do
you believe is the ideal size for a development team? Why?
6. With several other people, go through a brainstorming session to iden-
tify nonfunctional requirements and constraints for the university system.
Identify potential sources for these requirements, such as roles within the
organization (the Dean, an instructor, a registrar, and so on) and docu-
ments.
7. Identify the categories of tools, such as requirements management systems
and computer-aided software engineering (CASE) tools, which you could
potentially use during requirements gathering. For each category, present
three examples of them in the marketplace: one should be an open-source
software (OSS) tool and one should be a commercial package. Identify how
each category is used and the potential skills required of the people using
them.

Supplementary Requirements: Hapter

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Supplementary Requirements: Hapter

Uploaded by

Copyright:

Available Formats

C HAPTER 7

The true goal of requirements engineering is not to create documentation; it is to

TABLE 7.1. Supplementary Requirements Artifacts

A business rule defines or constrains one aspect of

7.1 BUSINESS RULES

identifier enables you to refer easily to business rules in other development

r BR123 Tenured professors may administer student grades.

FIGURE 7.1. Example business rules (summarized).

Name: Tenured professors may administer student grades

FIGURE 7.2. A fully documented business rule.

r Source (optional). The source of the rule is indicated so it may be verified

r Be written and made explicit;

r Be accessible to authorized parties (e.g., collective ownership);

Many business rules can actually be thought of as constraints (see Section

7.2 TECHNICAL REQUIREMENTS

A technical requirement pertains to the technical aspects that your system

FIGURE 7.3. Potential technical requirements for the university system.

computer. Whenever you have a requirement based purely on technology, try

A constraint is a restriction on the degree of freedom you have in providing

r C24 The system will work on our existing technical infrastructure—no

FIGURE 7.4. Potential constraints for the university system.

7.4 OBJECT CONSTRAINT LANGUAGE (OCL)

One way to describe business rules, technical requirements, or constraints

A glossary is a collection of definitions of terms, an example of which is

7.6 SUPPLEMENTARY SPECIFICATIONS

A supplementary specification is a RUP document that contains requirements

7.7 WHAT YOU HAVE LEARNED

Successful software systems are based on requirements, and because mod-

7.8 REVIEW QUESTIONS

You might also like