程序代写代做代考 data science algorithm flex 17spm_L06

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).