Rules of writing SW Requirements

Basic rules of writing SW Requirements

Dealing with ambiguous requirements with duplicities or contradictions is a real pain for everybody involved.
It would not take too much extra time to create them right from the beginning.
Poor requirements can be a ticket to end station unsuccessful project.
There are a few fundamental rules for writing requirements I would emphasize these:
(1) Be specific
System must comply with local legislation of each country.
It is a stakeholder requirement of a very general level
It should not to be inserted into Functional requirements.
(2) Do not try to reduce number of requirements by merging them. It is a way to the hell!
Describe only one need. Words and or or indicate more needs within one requirement.
Atomic requirements can differ in priority or other attributes and could be even dropped later.
(3) Write clear simple sentences avoid misunderstanding.
(4) Use uniform sentence structure: Most frequently used are:
System is able to System is able to display list of active products for given person.
User is able to User is able to modify own nick name.
It is / It is possible Transaction detail is displayed in new browser window.
(5) Create and utilize dictionary of terms and acronyms (separately from list of requirements)
(6) Do not use an examples in description of a requirement; place it into comment attribute
(7) Do not mix a process description or even fragments of meeting minutes with requirements; put
such texts aside and use it as an input for creation of real requirements
An activity (type 'inbound email') is created based on the email from Avaya (with the original
e-mail from Avaya attached to the activity). In case a response email is generated, the
Activity - interaction ID must be included in this email. If an existing contact/ prospect is
identified, it is automatically assigned to the email (request).
(8) Use unique IDs:
Use unique requirement ID without any information coded in it e.g. FR0123 works well.
Avoid structure like FR_CRM05.1.23.
o Implementation stream or area should be an attribute, which can be changed if needed
without modification of requirement ID.
o Dotted substructure is more difficult to maintain.
Never recycle requirement IDs within a project. In addition , dropped requirements should not
be deleted, better to mark them via status (e.g. rejected or dropped)
(9) Help the user to understand requirements visualize them.
E.g. you have a matrix with systems and modules in rows and columns BA creates bunch of
requirements with very similar wording for each cell of a matrix. Consumers of these requirements
should have available that matrix summarizing bunch of similar requirements
(10) Do not forget on quality (non-functional requirements) and transition (migration) requirements
(11) Do not put LOV (List of Values) items into requirements, keep them separately. Typically LOV is
enriched and changed multiple times. The exception is LOV item with some specific feature to be
described via requirement.
(12) Avoid must in requirement description. Indication of urgency or priority should be an attribute. It
can be changed more easily and it allows filtering. Some guys use always structure System must
support, please avoid must, should,... If you cannot help yourself use shell instead.
(13) Do not hurry. It is not possible to produce SMART requirements real-time during requirements
workshops; nobody can expect that Analyst makes it.
During workshop it is feasible to take notes or write some drafts of requirement-like artifacts only.

1/2
 Rules of writing SW Requirements

Examples
ID Description Area Sub Area Comment Priority
FR0001 Each customer account has Customer Rule High
assigned one active library card account
FR0002 Customer with overdue borrowed Customer Rule TBD other High
items is not able to borrow new account conditions for
items borrowing
suspension
FR0003 Administrator is able to set Administrat Global e.g. adult can High
maximum number of borrowed ion Parameters borrow maximum
items per customer type and item 50 items, maximum
type. 10 DVDs
FR0004 Library system is able to read a bar Interfaces Bar code Card code, book High
code code, frequent
operation code,..
FR0005 Customer is able to see list of Self-care Web Mid
borrowed items via web portal
FR0006 Customer is able to ask for lending Self-care E-mail TBD additional Mid
period extension of all borrowed requirements for e-
items via e-mail. mail
FR0007 It is possible to ask for prolongation Self-care Kiosk Mid
of all borrowed items via kiosk
FR0008 Administrator is able to modify Administrat Branch High
opening hours for each branch. ion
FR0009 Opening hours for each branch are Web portal Branch Mid
displayed on library web portal
FR0010 Customer is identified via bar code Self-care Kiosk The only option Mid
on library card in kiosk
FR0011 Reserved item cannot be prolonged Loan Rule business rule High
FR0012 Customer is able to modify own nick Web Chat Low
name via web portal.

Other commonly used attributes:

Status (New, Approved, Open, Dropped,..)
Business owner
Modify date
GAP ID

Those seeking a comprehensive guide to writing requirements should invest a time to W. Dijkgraaf book
Start at the end with SMART requirements. The book is simple brilliant and it has strongly influenced me.

About Tomas Filipek: Tomas worked 12 years as Requirement Engineer, Business Analyst or Business
Architect for various clients mostly from banking and telco.
He was involved in several core system replacements / package SW implementations utilizing heaps of
functional requirements.

2/2