1. Human Computer Interaction G52HCI
Steve Benford
Specifying Requirements

2. Learning outcomes
An understanding of what ‘requirements specification’ means
Specifically the meaning of
User versus system requirements
Functional versus non-functional requirements
Software Requirements Specification (SRS) document
Appreciation of legal issues
Requirements specification in your coursework
CW1 (second part): 2,500 word group report
20% of overall module mark

3. The Human Centred Design Cycle
Context: Users, tasks, hardware, software, materials, physical and social environments
From: ISO Human Centred Design Process for Interactive Systems (1999)
Plan the user-centred process
Understand and specify
the context of use
Evaluate Designs
Against User Requirements
Specify the user and
organisational requirements
Produce Design Solutions
Meets requirements

4. Software Engineering 8 Ian Sommerville
Requirements engineering
“Requirements engineering is concerned with establishing what the system should do, its desired and essential emergent properties, and the constraints on system operation and the software development processes.”
“You can therefore think of requirements engineering as the communications process between the software customers and users and the software developers.”

5. Requirements Specification
“The requirements for a system are the descriptions of the services provided by the system and its operational constraints”
2 key types of requirement
User requirements:
“ … statements, in a natural language plus diagrams, of what services the system is expected to provide and the constraints under which it must operate.”
System requirements:
“… set out the system’s functions, services and operational constraints in detail. The system requirements document (sometimes called a functional specification) should be precise. It should define exactly what is to be implemented. It may be part of the contract between the system buyer and the software developers.”

6. Example: A Library System
User requirement:
LIBSYS shall keep track of all data required by copyright licensing agencies in the UK and elsewhere
System requirement:
LIBSYS shall maintain a log of all requests that have been made to the system
Records of LIBSYS requests will be stored on the system for five years from the date of the request
For material where authors’ lending rights apply, loan details shall be sent monthly to copyright licensing agencies that have registered with LIBSYS

7. Functional & Non-Functional Requirements
“These are statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.”
Non-functional Requirements:
These are constraints on the services or functions offered by the system. They include timing constraints, constraints on the development process and standards. Non-functional requirements often apply to the system as a whole. They do not usually just apply to individual system features or services.

8. Example functional requirements
From our LIBSYS example:
The user shall be able to search all of the initial set of databases or selected a subset from it
The system shall provide appropriate viewers for the user to read documents in the document store
Every order shall be allocated a unique identifier which the user shall be able to copy to the accounts permanent storage area

9. Non-Functional Requirements (Ian Sommerville)

10. Usability requirements
Revisit the five core goals of usability
Time to learn
Speed of performance once learned
Rate of errors
Retention over time
Satisfaction
… and comment on each … with estimated figures where possible

11. Legal requirements for interface designers?

12. Documenting Requirements
The Software Requirements Specification (SRS)
“ … the official statement of what the system developers should implement. It should include both the user requirements for a system and a detailed specification of the system requirements.”
“The requirements document has a diverse set of users, ranging from the senior management of the organization that is paying for the system to the engineers responsible for developing the software.”
There is an international standard for SRS: ISO/ANSI
We will be using our own stripped down version which focuses specifically on user interface issues

13. Challenges of requirements
Being clear
speaking to your audience(s)
Being unambiguous
Clearly separating requirements
Being complete
Not overly constraining design
Being grounded and justifiable
Prioritising
Separating user from system requirements
Evolving requirements during iterative design

14. Coursework 1 (second part)
Produce a Group Requirements Specification
Share your study reports among your group (who will all have worked on the same topic)
Compare them in a series of group discussions
Arrive at an idea for a new system that is grounded in your studies
Produce a common SRS for this new system
Write this up in a group report using the template provided
Hand in a 2,500 word group report
Worth 20% of the overall mark for G52HCI
Due Thursday 3rd March at 15:00 PM

15. General guidelines
Focus on initial requirements for a first prototype as part of early iterative design
Set out requirements, but don’t overly constrain solutions
You might find it useful to do a task analysis
Justify your requirements by formally referencing your studies
Use clear language and plenty of structure
Give each requirement a code
Put your group names, names and addresses on the front page – does this seem obvious

16. Lectures and support sessions
Wednesday 16thFeb
introduction to requirements
set coursework
meet your group and get some dates in the diary
Friday 18th Feb - support session
exchange and discuss each other’s studies
plan the process in detail
Friday 25th Feb - group support session
Filling in the SRS

17. See the module webpage for
Group names and members
SRS template