Avoid Requirements-related Defects in IT-Systems

Name: Avoid Requirements-related Defects in IT-Systems
Type: Process
Version: 2007-04-20
Referring to: Principles for Requirements Engineering Tasks.P3
Source: Sorry, I know I used somebody else's material here but I failed to write the source down. If you feel like "hey, that's my idea" please let me know and I will be more that happy to properly credit you.

Note: The sooner a defect ist detected, the cheaper is its removal. This is a well known fact, nicely pointed out by for example by this article at Tyner Blain <…>. Why? Because in systems engineering usually things are described more than once - from different perspectives. As a rather coarse requirement, as an architecture, as a detailed requirement, as a design, as a test, as code, in manuals. The more of these artifacts have to be changed due to a defect, the more expensive. Add the cost of bringing the system to the user.
Therefore it is a good idea to avoid defects in the first place.

Concerning requirements, defects occur in 4 different steps in the process:
S1: When stakeholders incorrectly or incompletely define their requirements.
S2: When analysts document the requirements incorrectly or incompletely. Writing good requirements is not too difficult.
S3: When developers write unit tests that test the wrong implementation. Even very effective methods of continuous integration then result in very effective testing of the wrong thing.
S4: When testers make sure, that the wrong requirements were implemented or that nat all of the requirements were realised. Then we waste our time by testing for requirements that aren't really requirements

What do we do about it? We add feedback cycles accordingly:
S1: We focus on the ROI, so the stakeholders concentrate on the important requirements. Using different requirements gathering techniques on the same stakeholders help a great deal. Stakeholders oficially approve the requirements that were documented by the analysts. (BTW, that means that the requirements must be readable by stakeholders)
S2: We use a strict Specification Quality Control process to make sure we get well written requirements. One or more analysts approve the work of one other analyst. The ultimate goal in doing so is to improve the author, not the specification itself.
S3: intensive communication with analysts and architects helps developers while comprehending the requirements.
S4: Test cases and test data will be approved by the analysts.

Nonfunctional requirements and level of specification

Name: Nonfunctional requirements and level of specification
Type: Theory
Version: 2007-04-18
Source: My friend Sven

"The higher the level of a system's requirements specification, the greater the portion of non-functional requirements."

This is, because no computer system can directly realise a non-functional requirement; it has to be broken down to a set of functional requirements. This set interacts and thereby attains (or does not attain) a certain non-functional attribute.

Sven's sentence describes a necessary characteristic of good specifications. In other words if you find a high-level spec with few or no non-functional requirements, it does not mean it is not high-level. It probably means that the author forgot to include non-functional requirements.

Also, "portion" is maybe not the correct term (he used the German "Anteil"), but I think the idea is clear.

Signs and Symbols

Name: Signs and Symbols
Type: Explanation
Status: Draft
Version: 2007-04-18
Rationale: This blog makes use of Planguage, a planning language from the Gilb family.

Here's my dialect:

E Entry-Condition
S Step in a process
P Principle
R Rule
X Exit-Condition
[…] Qualifyer, Condition
<...> not sufficiently specific
or
{…} set of things
F(x) s.th. that has been derrived from x using a function F
' commentary text afterwards
italics commentary text

Principles for Requirements Engineering Tasks

Name: Principles for Requirements Engineering Tasks
Type: principles
Status: finished
Version: 2007-04-28
German: RE-Prinzipien

The RE in my projects follows these guidelines:

P1: Requirements are driven by business; technical aspects or solutions to problems never constrain requirements without a clear, documented cause.
P2: Requirements with high business value will be analysed and realised first.
P3: We avoid defects in the system instead of testing them out.
P4: (Potentially) controversal discussions take place as early as possible. Unclear, risky or hard to describe requirements are analysed early.
P5: Bandwidth will be maximised while communicating requirements and while communicating on requirements.
P6: If a rule, standard or other regulatory asset - whether it originates from the outside or inside of the project - hinders understandability of a requirement, the rule will be ignored.
P7: Solutions (Designs) to requirements can occur, but only as suggestions w/o any legal consequences.
P8: The (document) "Requirements Management Plan" will be improved continuously.
P9: ruleset.PrioritizeInEvoDevelopments applies

Evaluate the presentations

Name: Evaluate the presentations
Type: rule set
Status: Draft
Version: 2007-04-18
Referring to: Process.Call for tenders

R1: Have the presentations scheduled with little time between them.
R2: Again have different evaluation tasks assigned to the people on the team (e.g. According to their roles in the project)
R3: Have a list prepared with questions you will definately ask each supplier
R4: be strict about presentation time