Presentation discussed during the IREB roundtable How to Write good Requirements with Sylwia Kopczyńska and Karolina Zmitrowicz, moderation Stan Buhne.
During the roundtable we had a lively discussion with Requirements Engineering experts Karolina and Sylwia, who gave many insightful points on how to write good requirements. Some points that were discussed included the importance of writing good requirements, their quality criteria and which are most common, examples for good and bad requirements, and standards for requirements specification.
Recording available on YouTube https://youtu.be/m_JFdblX4KU
1. Kapitelname
1
Slides provided by: Sylwia Kopczyńska & Karolina Zmitrowicz
How to write good requirements – in a Nutshell
IREB Roundtable: How to Write Good Requirements?
3. What are requirements’ quality characteristics (criteria)?
For example:
IEEE 830
Unambiguous, Complete, Concise, Prioritized, Verifiable, Modifiable, Traceable
IEEE29148
For a single requirement: Unambiguous, Complete, Necessary, Verifiable, Traceable, Singular,
Implementation free, Consistent
For a set of requirements: Complete, Consistent, Affordable, Bounded
INVEST
Independent, Negotiable, Valuable, Estimatable, Small
IREB
For single requirements
Adequate, Necessary, Unambiguous, Complete (self-contained), Understandable, Verifiable
For a set of requirements
Consistent, Non-redundant, Complete, Modifiable, Traceable, Conformant
3
by Sylwia Kopczyńska & Karolina Zmitrowicz
4. What are the examples of requirements that are not so good?
The system shall respond immediately
The system shall be fast
GUI shall be nice
Allowing cash withdrawal
The system shall be available on all browsers
4
by Sylwia Kopczyńska & Karolina Zmitrowicz
5. 5
How to check / improve my requirements? (1)
E.g. Reviews
e.g., based on the quality characteristics
Adherence to notation (form, format) and using templates, e.g.,
EARS, Rupp’s, NoRTs
Formal spec (e.g., LTL) vs. Natural language spec (e.g., User Story, Use Case)
Planguage
Guidelines, e.g.:
Writing Effective Use Cases by A. Cockburn
Standards
IEEE830, IEEE29148
ISO25010, ISO27000
Prototypes
e.g. paperbased- or software prototypes
Definition of Ready
especially in an agile environment
Remember about Acceptance Criteria and Acceptance Tests
e.g., BDD approach
by Sylwia Kopczyńska & Karolina Zmitrowicz
6. How to check / improve my requirements? (2)
Select a work product type that fits the intended purpose
Avoid redundancy by referencing content instead of repeating the same content
again
Avoid inconsistencies between work products, particularly when they cover
different aspects
Use terms consistently, as defined in the glossary
Structure work products appropriately — for example, by using standard
structures
6
Check also: CPRE Foundation Level https://www.ireb.org/en/cpre/foundation/
by Sylwia Kopczyńska & Karolina Zmitrowicz
7. How to check / improve my requirements? (3)
Remember about trade-offs quality-cost
Look for studies/reports about experience, lessons learned, benchmarks,
experiments of using different techniques, for example:
When considering using
Non-functional Requirements Templates (NoRTs):
you might look at the case studies
and lab experiments to learn that:
so that you can see if it fits your context
and make an informed decision
7
• NFRs elicited with the use of templates are:
Less ambiguous
More detailed
Better from the point of view of testability
More complete
Templates do not speed up the elicitation process
Kopczyńska,
S.,
Nawrocki,
J.,
Ochodek,
M.
On
usability
and
maintainace
issues
of
catalog
of
non-functional
requirements
templates
–
empirical
study,
Information
and
Software
Technology,
103,
75-91,
2018
by Sylwia Kopczyńska & Karolina Zmitrowicz
8. Thank you!
Reach out for us at LinkedIn
Sylwia Kopczyńska
https://www.linkedin.com/in/sylwiakopczynska/
Karolina Zmitrowicz
https://www.linkedin.com/in/karolinazmitrowicz/
8
by Sylwia Kopczyńska & Karolina Zmitrowicz