3.2 Functional requirements
3.3 Performance requirements
3.4 Design constraints
3.5 Software system attributes
3.6 Other requirements
3.1.1 User interfaces
3.1.2 Hardware interfaces
3.1.3 Software interfaces
3.1.4 Communication interfaces
3.1 Interface requirements
3 Specific requirements
Kristian Sandahl, IDA
krisa@ida.liu.se
Kristian Sandahl, IDA
krisa@ida.liu.se
write a good one
The RS, or SRS avoids many misunderstandings
The RS is of special importance in outsourcing
programming
Eight good advice and some templates.
There is no perfect specification, but you can
Advice towards a good
specification
Costs:
bad attitude against
standards
3.2.1 Information flows
3.2.2 Process description
3.2.3 Data construct specification
3.2.4 Data dictionary
3.2 Functional requirements
3.2.1 Class1
3.2.1.1 Attributes
3.2.1.2 Functions
....
3.2.n Class n
3.2.n.1 Attributes
3.2.n.2 Functions
3.2 Classes
Kristian Sandahl, IDA
krisa@ida.liu.se
Kristian Sandahl, IDA
krisa@ida.liu.se
Developers can have a
standard
Finding the right standard
Configure variants
Periodically review
3.1 Interface requirements
3.1.1 User interfaces
3.1.2 Hardware interfaces
3.1.3 Software interfaces
3.1.4 Communication interfaces
3 Templates
Benefits:
Readers can reuse
knowledge from previous
RSs in understanding
Writers’ checklist
Tools can be adapted to
generate RSs
Define a standard document
structure
3.3.1 Information flows
3.3.2 Process description
3.3.3 Data construct specification
3.3.4 Data dictionary
3.3 Functional requirements
3.3.1 Class1
3.3.1.1 Attributes
3.3.1.2 Functions
....
3.3.n Class n
3.3.n.1 Attributes
3.3.n.2 Functions
3.3 Classes
3.1 User interface requirements
3.2 Other interfaces
3.2.2 Hardware interfaces
3.2.3 Software interfaces
3.2.4 Communication interfaces
Kristian Sandahl, IDA
krisa@ida.liu.se
Kristian Sandahl, IDA
krisa@ida.liu.se
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and
dependencies
2.6 Lower ambition levels
3 Specific requirements
4 Supporting information
4.1 Index
4.2 Appendices
Customise the template
1.1 Purpose
1.2 Scope
1.3 Definitions, acronyms
and abbreviations
1.4 References
1.5 Overview
2 Overall description
2.1 Product perspective
2.2 Product functions
Table of contents
1 Introduction
Template IEEE Std. 830
There are many readers of a RS:
Customers
Managers
Software engineers
Testers
Maintenance staff
Technical writers
Subcontractors
Kristian Sandahl, IDA
krisa@ida.liu.se
Part of introduction
Types of reader
Technical background needed
Sections for different readers
Sections skipped 1st time
Order of section
Dependence between section
Takes an hour to write
Explain how to use the document
Kristian Sandahl, IDA
krisa@ida.liu.se
Can be downloaded from
http://www.volere.co.uk/
(registration required,
free for students)
references
Focus attention on critical
and prioritised
requirements
Map to find specific
requirements
Better than forward
Kristian Sandahl, IDA
krisa@ida.liu.se
relations
Per chapter basis
Though for large number
of requirements
Table of classification
Graphic presentation with
requirements in a list
Highlight most important
Include a summary of the
requirements
Kristian Sandahl, IDA
krisa@ida.liu.se
agreement
Requires that top management have an
Kristian Sandahl, IDA
krisa@ida.liu.se
Special document, section or part of introduction
Helps change assessment
Helps understanding
Make a business case for the
system
Kristian Sandahl, IDA
krisa@ida.liu.se
PROJECT ISSUES
18. Open Issues
19. Off-the-Shelf Solutions
20. New Problems
21. Tasks
22. Cutover
23. Risks
24. Costs
25. User Documentation and Training
26. Waiting Room
27. Ideas for Solutions
NON-FUNCTIONAL
REQUIREMENTS
10. Look and Feel Requirements
11. Usability and Humanity
Requirements
12. Performance Requirements
13. Operational Requirements
14. Maintainability and Support
Requirements
15. Security Requirements
16. Cultural and Political Requirements
17. Legal Requirements
PROJECT DRIVERS
1. The Purpose of the Project
2. Client, Customer and other
Stakeholders
3. Users of the Product
PROJECT CONSTRAINTS
4. Mandated Constraints
5. Naming Conventions and
Definitions
6. Relevant Facts and
Assumptions
FUNCTIONAL REQUIREMENTS
7. The Scope of the Work
8. The Scope of the Product
9. Functional and Data
Requirements
The Volere RS template
The Volere RS template
Units
Tolerance
Value ranges
Error values
Name of entity
Aliases
Type
Description
Rationale
Constraints
Human-made indices are still better
Kristian Sandahl, IDA
krisa@ida.liu.se
Easy to find support for automatic generation
Kristian Sandahl, IDA
krisa@ida.liu.se
write a personal reflection.
Ask a friend to criticize them writtenly, or
different type.
Continue writing about 10 requirements of
Requirements will be changed
Quite easy with tools
Paper-based specifications needs some thinking:
Loose-leaf binders
Change bars
Short, self-contained chapters
Refer to labels, not pages
Create table of contents
Create index
Home assignment
Kristian Sandahl, IDA
krisa@ida.liu.se
newly hired personnel
Kristian Sandahl, IDA
krisa@ida.liu.se
Kristian Sandahl, IDA
krisa@ida.liu.se
It is worthwhile to buy professional training for
word processor and common sense
Meanwhile, use your standard templates of your
Many, many readers justify the investment
Make documents easy to change
Relations
Links
Lay out the document for
readability
Help readers find information
Kristian Sandahl, IDA
krisa@ida.liu.se
adherence
Can develop into an ontology
=> massive information
exchange, search and checking
Often well-supported in tools
Often forgotten in student-RSs
Needs maintenance and
terms in diagrams
A glossary for variables and
Readers and writers might have their own
meaning of terms
Requirements engineer develops a jargon that
need to be explained
Use a glossary, start with a standard one, adapt
and maintain
Highlight terms in the text that can be found in the
glossary
Use a data dictionary
Define special terms
Function
Function
It shall be possible to set different privileges for
each participator in a course. The privileges are:
add news, remove news, add files, remove files.
ID (sorted)
10XX – Product level
20XX – Feature level
30XX – Function level
40XX – Component level
Course Start Page The Course Start Page shall contain: Course
Contents
News, Link to Course Participators, Link to Course
File Archive, Course Calendar, Link to Course
Information, Link to Course Literature List, Link to
Course Links, Link to Course Discussion Forum.
Participator
Privileges
LEVEL
3 065
3 062
3 065
3 062
3 147
Change Privileges for Course
Participators
Related req. on
the level
below
Discussion Forum
Product Access
Course Info
Manage Course
Participators
Related req. on
the level
above
2 107
2 120
2 097
2 057
• 4 sections (Product-, Feature-, Function-, and Component level)
• The req. present are the basis of the experiment (what you should base
your answers on!)
The requirements specification - 1
BESQ - www.bth.se/besq
SERL - http://www.bth.se/tek/serl
SIREN - http://www.siren.lth.se/
Department of Systems and Software Engineering
School of Engineering
Blekinge Institute of Technology
Tony Gorschek & Mikael Svahnberg
Experiment Design by
- Experiment in Requirements Engineering
Requirements Abstraction and Work-up
Feature
Function
3 147
3 065
3 062
3 060
3 059
3 058
3 069
3 148
2 057
2 057
3 059
2057
3 148
3 150
3 149
Manage Course
Participators
Course Participant
Administration
2 057
2 057
2 057
2 057
2 057
1 118
2 057
What if a user is no longer a
participator of any course?
What should happen to his/her
profile? What if I want to
remove 100 users in one go?
Course participators also include
Course Tutors.
2 057
When conducting a course it is good
to have access to the participants in
the course. This enables quick and
easy communication with them, and
enables them to find and
communicate with each other.
The requirements specification - 2
It shall be possible to attach and manage
participators to a course.
Remove
It shall be possible to remove users as
Participators from participators from a course.
Course
Manage Course
Participators
2 057
2 057
A structured way of working
Access to Add and Remove
Course Participators
3059
Access to Change Course
Participator Role
Access to Add and Remove
Course Participators
Change Privileges for Course
Participators
Course Start Page Contents
Participator Privileges
Course Participator Roles
Remove Participators from
Course
Add Participators to Course
Course Administration Contents
Access to Change Course
Participator Privileges
Utilizing several levels of abstraction
Requirements Abstraction Model
Up to product level and down to function level
RAM example