 |
A technical requirement pertains to
the technical aspects that your system must fulfill,
such as performance-related issues, reliability issues,
and availability issues. These types of requirements are
often called quality of service (QoS) requirements, service-level requirements or
non-functional requirements (I don’t like that term as
it makes them sound like requirements that won’t work). Examples of technical requirements are
presented in Figure 1. As you can
see, technical requirements are summarized in a similar
manner as
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. |
|
Figure 1. Technical requirements
(summary form).
- TR34 The system shall be available 99.99% of the
time for any 24-hour period.
- TR78 A seminar search will occur within less than
three seconds 95 percent of the time.
- TR79 A seminar search will occur within no more
than ten seconds 99 percent of the time.
I’m a firm believer that you should
minimize the number of purely technical requirements.
Technology changes quickly and often requirements based
on technology change just as quickly. An example of a
pure technical requirement is that an application be
written in Java or must run on the XYZ computer.
Whenever you have a requirement based purely on
technology, try to determine the real underlying
business needs being expressed. To do this, keeping
asking why your application must meet a requirement. For
example, when asked why your application must be written
in Java, the reply was it has to 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 services 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, and in fact constraints can apply to
either technical or
business issues.
This artifact description is excerpted from Chapter 7 of
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2.
|
|
|
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2 is an
important reference book for agile modelers,
describing how to develop 35
types of agile
models including all 13
UML 2 diagrams.
Furthermore, this book describes the techniques
of the
Full Lifecycle Object Oriented Testing
(FLOOT) methodology to give you the fundamental
testing skills which you require to succeed at
agile software development. The book also
shows how to move from your agile models to
source code (Java examples are provided) as well
as how to succeed at implementation techniques
such as
refactoring and
test-driven development
(TDD). The Object Primer also includes a
chapter overviewing the critical database
development techniques (database refactoring,
object/relational mapping,
legacy analysis, and
database access coding) from my award-winning
Agile Database Techniques
book. |
 |
|
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
modeling and
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
XP, the
Rational Unified Process (RUP), or the
Agile Unified Process (AUP), to streamline your
modeling and documentation efforts. Modeling and
documentation are important aspects of any software
project, including agile projects, and this book
describes in detail how to
elicit requirements,
architect, and then
design your system in an agile manner. |
 |
|
The Elements of UML 2.0 Style describes a collection
of standards, conventions, and
guidelines
for creating effective
UML diagrams. They are based on sound, proven
software engineering principles that lead to diagrams
that are easier to understand and work with. These
conventions exist as a collection of simple, concise
guidelines that if applied consistently, represent an
important first step in increasing your productivity as
a modeler. This book is oriented towards
intermediate to advanced UML modelers, although there
are numerous examples throughout the book it would not
be a good way to learn the UML (instead, consider
The Object Primer). The book is a brief 188
pages long and is conveniently pocket-sized so it's easy
to carry around. |
Translations
I actively work with clients around the world to
improve their information technology (IT) practices as
both a mentor/coach and trainer. A full
description of what I do, and how to contact me, can be
found here.
|
