17spm_L06
Gathering Requirements
SPM 2017 © Ron Poet Lecture 6 1
Gathering Requirements is Difficult
� Customers/users might have contradictory requirements.
� Customers/users might have different priorities.
� Customers/users might be unaccustomed to articulating their
requirements.
SPM 2017 © Ron Poet Lecture 6 2
� Customers/users might propose requirements that are technically
infeasible, or too costly
Techniques
� Read documentation of existing system and processes.
� Consult customers.
� Issue questionnaires to users.
� Observe users at work.
SPM 2017 © Ron Poet Lecture 6 3
� Interview users.
� Brainstorm customers and users.
� Build a prototype and get feedback from customers/users.
Questionnaires
� Issue a questionnaire to all users, or a representative sample of users.
o Then summarise the responses.
� Closed questions constrain the possible responses, e.g.:
o Should the system enable students to enrol themselves on courses?
SPM 2017 © Ron Poet Lecture 6 4
o
(Tick one box.)
□ strongly agree □ agree □ neutral □ disagree □ strongly disagree
� Open questions allow users to frame their own responses, e.g.:
o To what extent should advisers be involved in getting students to
enrol?
� Closed questions are easier to summarise, but open questions are more
likely to be informative.
Quantitative and Qualitative Results
� Answers to closed questions can be analysed automatically.
o Assign numbers 0 .. 4 to the 5 possible answers.
o Average result is 2.5, slightly disagree.
o The hypothesis that users would like a new system is supported o
with a 95% confidence level.
o These are quantitative results and produce conclusions with little
effort.
� Answers to open questions provide qualitative results.
o There are a large number of possible answers.
o The answers are free text and difficult to analyse automatically.
o Data science research is making this task easier.
SPM 2017 © Ron Poet Lecture 6 5
Observation
� Observe a representative selection of users at work.
� Note how they work with the existing system.
� Get them to explain what they are doing.
� Advantages and disadvantages:
SPM 2017 © Ron Poet Lecture 6 6
+ likely to expose hidden assumptions
+ likely to reveal undocumented shortcuts and workarounds
– time-consuming (only one user at a time)
– possibly stressful for users.
– users may not behave naturally.
Interviews (1)
� Interview a representative selection of users.
� The interviews should be structured:
o Prepare core questions in advance, and ask each interviewee the
same core questions.
SPM 2017 © Ron Poet Lecture 6 7
o But be flexible enough to follow up any unexpected responses.
� Ask for specific facts:
o How does the existing system work?
o What are its limitations?
o Who does what, and when?
Interviews (2)
� Ask for sources of information:
o Documents
o Other experts.
� Ask for ideas:
SPM 2017 © Ron Poet Lecture 6 8
o What should the proposed system do?
o What must it do?
o What should it not do (things better left to humans)?
� Ask for views on alternative ideas.
� Note or record the interviewees’ responses.
Interviews (3)
� The interviewer needs good listening skills:
o Listen carefully to the interviewee’s responses.
o Summarise the responses to ensure there is no misunderstanding.
� The interviewer needs empathy:
SPM 2017 © Ron Poet Lecture 6 9
o Put the interviewee at ease. Start by asking straightforward
questions (current role? how long in this role? etc.)
o Try to discover the interviewee’s true views. (He/she might be
reluctant to criticise the existing system or colleagues.)
� If the interviewee’s responses suggest unhappiness, try to discover
why.
Interviews (4)
� Advantages and disadvantages:
+ systematic
– time-consuming (only one interviewee at a time)
– possible communication problems
SPM 2017 © Ron Poet Lecture 6 10
– possibly stressful for interviewees.
– interviewees may not behave naturally.
Workshops (1)
� A workshop is an intensive discussion by a group of 5–20 participants.
� Participants may be customers, users, developers.
� The workshop should be led by a trained facilitator.
� The workshop should be structured to cover all issues and involve all
SPM 2017 © Ron Poet Lecture 6 11
participants.
� Advantages and disadvantages:
+ systematic
+ less time-consuming
– some participants might dominate discussion.
Example: Brainstorming Workshop (1)
� The participants sit round a table. Each participant has several blank
sheets of paper.
� The facilitator poses a relevant trigger question. (E.g., what should the
proposed system do? what should it not do?)
� Each participant writes down one or more ideas – one idea per sheet.
SPM 2017 © Ron Poet Lecture 6 12
� Each participant writes down one or more ideas – one idea per sheet.
� Participants pass their sheets clockwise.
� Each participant considers each idea in front of him/her, adds a
comment to the sheet, and uses it to stimulate his/her own ideas.
Example: Brainstorming Workshop (2)
� This is repeated until ideas stop flowing.
� Each participant reads out the ideas and comments in front of him/her.
The facilitator writes each idea on a flip-chart, and the whole group
discusses it.
� The whole group then decides which ideas are most worth pursuing.
SPM 2017 © Ron Poet Lecture 6 13
� The whole group then decides which ideas are most worth pursuing.
Example: Requirements Refining
Workshop
� The facilitator circulates a draft requirements document (preferably in
advance).
� The facilitator asks each participant in turn to comment on the draft.
� The facilitator initiates discussion of each requirement in turn.
SPM 2017 © Ron Poet Lecture 6 14
� If there is a consensus to change it, the facilitator records the change.
Prototypes
� A prototype is an incomplete quick-and-dirty implementation of a
system.
� It is used to get feedback from users and hence refine requirements.
� It may be implemented using a rapid prototyping language.
SPM 2017 © Ron Poet Lecture 6 15
o But must later be re-implemented in a normal programming
language.
Example: User Interface Prototyping
� Mock-up the user interface on paper:
o very rapid paper prototype
o rough idea of look-and-feel.
� Mock-up the user interface on a computer, but with no functionality
SPM 2017 © Ron Poet Lecture 6 16
behind it:
o better idea of look-and-feel.
� Build a rapid prototype with limited functionality.
o better idea of interaction.
Reviewing Requirements
� Are all requirements essential to solve the problem?
o Prioritise 20% of the requirements that really matter.
o (Pareto principle: 80% of any problem can be solved with 20% of
the work.)
SPM 2017 © Ron Poet Lecture 6 17
� Does each requirement’s benefits outweigh its costs?
o Each requirement has costs (e.g., development, user training).
o Each requirement should have benefits (e.g., productivity, sales).
� Is every requirement realistic?
o Can it be met within available resources (e.g., equipment,
expertise)
Completeness and Consistency (1)
� Are the requirements complete?
o Do they cover all desired functionality?
o Do they ensure sufficient quality?
(This is particularly important for a critical system.)
SPM 2017 © Ron Poet Lecture 6 18
� Are all requirements consistent?
o Do any requirements contradict each other?
o Is each requirement consistent with domain standards? (see
domain description in lecture 7)
o Are any requirements duplicated?
(Duplication risks future inconsistency if requirements change.
Completeness and Consistency (2)
� Does any requirement over-constrain the system?
o Does it specify a particular implementation?
o Does it make implementation impossible?
� Is every requirement verifiable?
SPM 2017 © Ron Poet Lecture 6 19
o Will it be possible to test whether the system meets the
requirement?
o A customer should not sign off and pay for a system without
verifying that the requirements have been met.
Organization
� Are the requirements well-organised?
o Does the requirements document have a clear structure?
o Where necessary, is there a hierarchy of documents?
� Is each requirement uniquely identified?
SPM 2017 © Ron Poet Lecture 6 20
o Requirements should be numbered for easy reference.
� Are requirements clearly prioritised?
Language
� Is each requirement expressed in clear and precise language?
o An unclear requirement cannot be implemented or verified
properly.
� Is each requirement unambiguous?
SPM 2017 © Ron Poet Lecture 6 21
o An ambiguous requirement could be interpreted differently by
different stakeholders.
� Do the requirements have a clear rationale?
o The Background section of the requirements document should
explain the reasoning behind decisions made.
Examples of Poor Language
1. Student: enrol on a course and choose their lab group.
2. Staff : upload results as grades or percentages
3. Course Coordinator: allocate enrolled students to lab groups.
� 1 and 3 are inconsistent
SPM 2017 © Ron Poet Lecture 6 22
� 2 is inconsistent with the University of Glasgow standards.
More Examples of Poor Language
4. Staff: withdraw a course
5. Students: enrol themselves for their chosen courses
6. The system will respond within a reasonable time.
7. Staff: generate an exam timetable using the XYZ algorithms.
SPM 2017 © Ron Poet Lecture 6 23
� 4 is ambiguous
� 5 is vague
� 6 is vague and unverifiable.
� 7 is too constraining
Change (1)
� Everything changes and nothing stands still. The only constant is
change.
o Hiraclitus of Ephesus, 435 – 375 BCE
� This applies to requirements, even after they have been gathered,
documented, and approved.
SPM 2017 © Ron Poet Lecture 6 24
documented, and approved.
� During system development, customers/users tend to gain a better
understanding of the problem.
� Over time, business processes tend to change.
� Over time, technologies tend to change.
� Therefore requirements might need to evolve.
Change (2)
� Requirement changes tend to disrupt system development.
� Uncontrolled requirement changes are a major cause of IT project
failures.
� Advice:
SPM 2017 © Ron Poet Lecture 6 25
o Implement only high-priority requirement changes.
o Defer low-priority requirement changes to a future version of the
system.
o Avoid requirements creep (cumulative inessential enhancements).