Q-Patterns
What are
Q-Patterns?
1. Q-Patterns are a set of interrelated questions,
grouped together.
2. These
Questions relate to some aspect of user/software
requirements
3. They try to provide you with various
alternatives which could be
used to provide a solution. For
your needs either you could pick up a
solution from the
questions OR based on the solution, pick up
required review
comments, test cases etc. THUS you get a good set
of
PRE-COOKED, pre-though out review comments, design
strategies and
test cases etc.
4. You can add to
the existing Q-Patterns to enhance them or create
new ones,
based on your own experiences, needs etc.
5. They follow a
format different from GOF patterns but that may
change. We
have to think on this aspect and come up with a
template
generic enough to be useful to all types of
Q-Patterns.
Understanding
Q-Patterns by the help of an example
Password
management
Passwords are used for security almost everywhere.
But probably the
policies are
not implemented in a similar manner by all. Even the
same
company has two different policies of handling password in
two
different products.
Some questions
(without any attempt to categorize them...) that can
be asked
are...
1. How many characters can the password accept?
What are the maximum and the minimum number of characters?
2.
What is the policy on password strength
2.1 It should contain
some minimum numbers of numeric characters
2.2 It should
contain some minimum number of characters long
3. Does the
Password expire in X number of days? If yes then can the
user
set the value of X?
4. Does the administrator have control
over whose password does not
expire?
5. When the
password is changed after expiry can it be reset to the
same
password again? Or last N number of password can not be
used?
6. Display: When password is typed (Either for login OR
for first
time entry/changing) is password displayed in clear
text or as some
other common character as * etc.? Or is it
invisible?
7. When the password is shown as * to the user say,
for changing, how
many characters are displayed? As many as
the length of password OR a
fixed number of characters?
Example: In Windows NT open control
panel/services. The
password with which a service is running is
displayed as a
fixed number of *s as compared to say Microsoft
word's
password storage mechanism for protecting a
document.
...
Some of these questions may
have already been answered in the
specifications, but the
chances are that there will be many unanswered
questions. If
we could provide some structure to these questions which would help us
categorize these questions, could provide us with framework where many
more questions come to your mind naturally, it would enable us to write
more complete test cases.
It is also amply evident from the questions that
we are not trying to force a particular line of thought hence our
Q-Patterns, based on these questions, will not be rigid depending on a
particular implementation. Most important is the fact that we are not
assuming any implementation. We are simply asking relevant questions. And
these questions can help at the time of reviews or writing
specs/design/test cases.
Q-Patterns
FAQ
Q1. Why is a structure required for describing a
Q-Pattern?
A structure is
required to effectively capture the information in
represented
in a UNIFORM manner for ease of RECORDING and
SHARING.
Structure also promotes structured thoughts. At the
same time a
structure also poses some restrictions and a
possibility of stunting
the growth of new thoughts. A
conscious effort may be required to
think "outside the box."
This effort may not only help in bringing to
light new ideas
but also in improving the structure.
Q2. What structure
could possibly exist for Q-Patterns, since they
can be
of
1. Different granularity
2. Different
domains
3. Different concepts etc.
It is
indeed very difficult to come up with a general structure
that
fits all. The structure that I am proposing may be valid
for the type
of Q-Patterns I have in mind. It may also be
valid for some other
domains/concepts however, there is no
guarantee. At best this is a
tentative format that I am
proposing and this is likely to
undergo
changes.
Q3. Why can we not use the
existing GOF structure
A GOF Patterns typically has the
following structure
Name: A single word or short
phrase
Problem: A statement of the
problem
Context: The environment where/for-which the problem
has been
identified and a solution
required.
Forces: Various conditions and constraints that
influence
the
solution.
Solution
Examples
Related
Patterns
Known Uses
etc...
(For
details you may refer to the Design Patterns book and also
this
link http://www.hillside.net/patterns/patterns.html)
We
use part of this structure.
Q4. What is the proposed
format?
I propose the following format for documenting
Q-Patterns
1. Name of the pattern
2.
Intent/Explanation/definition
3. Questions related
to:
a. Administration
b. Usage/User
c.
UI
d. Security
e. Performance
i.
Response Time (Fetch, insert/delete/update, Display)
ii.
Concurrency
iii. Max and Min parameters (Data size
etc.)
iv. Memory requirement
v. Disk
Space
4. Examples
5. Associated patterns: Some
times some Q-Patterns collaborate
together and these
collaborating patterns should be preferably looked
at when
looking at a given pattern.
6. Specialization: If the given
patterns can be specialized, with
extra, context specific
questions added and some specific questions
removed then that
patterns can be called as "specialized pattern."
These
patterns are specific to the given context.
We do not have
(a) Forces (b) solution as part of our
template/structure
because our questions indicate the forces and to
provide a
solution is not the aim of Q-Patterns. To ask questions and
to
enable one to choose to answer some of them is the intent.
Q5. What issues do you see with this
structure?
I am not
entirely satisfied with this structure. The reasons are
(a)
Possibility of unwieldy collection of questions.
(b)
Possibility of duplicating the questions in
various
related/unrelated patterns
(c) Ambiguity
in some heads/sections which makes it difficult to
place some
questions in correct section.
(d) All the sections described
in the proposed structure may not be
universally
applicable.
Q6. What improvements can be made to the
existing structure?
Some things that I have in mind
are
1. Versioning the patterns: It is required for sharing the
patterns
unambiguously.
2. Use of OO techniques
like encapsulation and inheritance to take
care of some
issues. This will give us a more robust and
intuitive
structure for referencing other
Q-Patterns.
3. Some classification of various Q-Patterns as
Organizational Q-
Patterns, Design Q-Patterns, System Testing
Q-Patterns etc.
Example of a
Q-Pattern
Example: An incomplete example of a Q-Pattern is
given here. I have not completed writing all questions yet
:-)
NAME
Password Management
INTENT
The most general and common approach to
authenticate a system or user is asking for a
Password. Password authentication can be at different levels like
user level, group level etc or at different stages like Operating
System authentication, Application authentication
etc.
QUESTIONS
If you are using Password authentication anywhere
in your
spec/design/code/test you may ask
following
questions:
Administration
1. Can administrator reset the
password?
2. Can administrator's password be
reset?
3. What happens If the administrator forgets his
password (any
default password is given or reinstallation
would take place)?
4. Can administrator set the default
password?
5. Can another administrator reset an
administrator's password?
6. Can an administrator read the
password of a user?
Usage
1. What's the maximum and minimum length of
password?
2. Can we enter numbers in
password?
3. Can blank password be used?
4. Where
are passwords stored?
5. What is the default password (If
any)?
6. Can one customize the default
password?
7. Can Special characters (like #,$,ç,è,Þ,ß) be
used
in password?
8. How is password change
affected? Is original password required
before change password
is allowed?
9. Is Confirm password used?
10. Is
`Save Password' facility is there on the screen
(so
that
user may not need to enter password every
time she logs in)?
UI
11. Is password shown as stars (at the time of
entering the
password, at the time of changing or
resetting the password etc.)?
12. How many stars are shown for
a password
· When it is being entered?
· When it
is to be changed? (Note: Do not show same number of
stars as
the number of
characters.)
Security
1. How are passwords stored? Are they encrypted
before storing? If
yes what is the encryption
algorithm used?
2. Whether the password is case sensitive or
not?
3. Whether the password can be cut and
pasted?
4. Can a previously used password be used again? If
`Yes'
then
after how many changes?
5.
Is there any expiry time for the password? What happens
after
the date if user does not change the password during
that period?
6. Is there any policy to count the number of
password validations
in succession (e.g.. If user enters wrong
password 4 times then she
is not able to enter password again
in succession).
7. If application creates logs of all
activities, then the logs of
password are created or
not?
8. If logs of password are being made then the password
is stored
in encrypted form or
not?
Performance
1. Whether password is made up of single-byte
characters (even if
multi-byte character set is
being used in the application).
2. How much time will it take
to authenticate the user after the
submission of
password?
3. What is the maximum space required to store a
password? Will
all the passwords require same space
irrespective of size?
4. If wrong password is given, how much
time will it take to give
the error message?
5.
How many users can be authenticated at the same
time?
Example: Various login screens and mechanisms (web based
mail
systems, console based login
etc.)
Associated patterns: Access Rights, Error
messages
Specialization: Say, login for any particular web based mail
system.
You can prune
the question list to suite your needs, add more
questions to
the specialized list OR enhance the parent Q-Pattern.
The Q-Pattern presented here is a simple one. Once
we move to more
complex
Q-Patterns and develop a web of collaborating Q-Patterns,
the
whole concept will (hopefully) acquire a new and increased
relevance
and usefulness.
