Chapters Notes

Chapter 7:

Requirements Elicitation

1

7.1 Elicitation

 Is the process of identifying the needs and constraints of stakeholders.

 Is process that includes activities to discover, extract and define requirements.

 Is used to discover business, user, functional and non-functional requirements.

 Is the most challenging and critical, error-prone and communication intensive aspect of software development.

2

3

7.2 Elicitation Techniques

Interviews Workshops Focus Group Observations Questionnaires System Interface Analysis User Interface Analysis Document Analysis Elicitation Techniques(V)

4

 Interview

• Traditional approach to communicate with a user or small group

• Structured vs. Non-structured (pre determined questions) Vs (open questions)

5

Workshops Encourage stakeholders collaboration in defining the requirements.  Are facilitated sessions with multiple

stakeholders and formal roles such as ◦ Facilitator—to lead the process. - Keeping to the agenda - Staying in scope - Moving items to the parking lot - set Time limits - Drawing out nonparticipants ◦ Scribe/recorder—to write things down

6

Facilitator’s role is crucial  Keeping to the agenda  Staying in scope

- Everyone reads vision and scope document before workshop

- Periodically check requirements for compliance - Stay on topic, leave other requirements for other days

7

 Draw out nonparticipants  Use parking-lots for later considerations.

- Don’t forget random but important information just because it seems off-topic - Write it down—don’t lose it so person knows he isn’t being ignored

8

Some Ground Rules for sessions

 Start and end on time  Don’t recap for latecomers  Return from breaks promptly  One conversation at a time  Everyone contributes  Focus on issues, not individuals  Stick to the agenda,  limit time on each topic

9

 Focus Group

Is a representative group of users who convene in a facilitated meetings to generate input and ideas on product functionality and quality requirements.

Participants normally do not have decision making authority for requirements

10

 Observations

• Sometimes requirements can be generated by observing how the users are performing the tasks

• Can be time consuming and disruptive to the user

• Typically important or high-risk tasks are selected

• Can be silent or interactive

11

 User interface Analysis is a technique where the existing UI is examined to discover the user and functional requirements

 Document Analysis Refers to examining any existing

documentation for potential software requirements.

E.g., business processes, decision rationals, Forms, user manual etc

12

 Questionnaires

Are a way to survey large group of users to understand their needs across geographical boundaries.

• Open-ended vs. Closed Questions • Well-written questions are key to the

success (GIGO)

13

 System Interface Analysis

It reveals functional requirements regarding the exchange of data and services between systems.

• Context Diagram or Ecosystem maps are good indicators for the start

• Can also find the validation criteria for Data being exchanged

14

7.3 Planning Elicitation

 Plan the Elicitation Objectives Estimate Schedule and Resources  Know the Expected products of

Elicitation efforts Identify Elicitation risks

Decide on Elicitation Strategy and Techniques (see next pages)

15

16

7.4 Preparing for Elicitation

 Plan Session Scope and Agenda - Need to decide on the scope taking into

account how much the time is available. - Align the scope with the overall project scope

defined in the business requirement - Agenda should be itemized with topics to be

covered, time available for each topic, and objectives.

17

Prepare Resources Schedule the physical resources needed, such as rooms, projectors, tele-conferencing needs, etc

 Prepare Questions Key to success. Usually prepare open-ended Questions, such as why?, how? Etc

 Prepare “Straw man” or “Draft” models serves as a starting point. “it is easier to revise a draft model than to create from scratch”

18

7.5 Perform the Elicitation Activities

 Educate the stakeholders - Explain the approach/technique being

used - How the information will be captured and

reviewed later 19

 Take good notes Assign a scribe who does not take active role It should contain: attendee list, invitee not

attended, decisions made, actions to be taken, division of tasks, outstanding issues, high points of key discussion

 Exploit the physical space Use white boards, white papers, sticky notes and

markers. Use 4 walls to draw diagrams and create lists of

ideas, issues etc

20

7.6 Follow up after Elicitation

 Organizing and sharing the notes - Review and update notes soon after the session is over

while memory is still fresh - keep the original, raw notes, just in case - Soon after, share the notes with participants for review - Consider to share the notes who did not participate

21

 Document the open issues - Examine Any items that need further

explanation - See if any knowledge gaps encountered - Examine the “parking lot”

22

7.7 Classifying User Input The all kinds of user input needs to be classified.

 Business Requirements—financial, marketplace, benefits

 User requirements (Use Cases and Scenarios)—user goals, paths to goals

 Business Rules—policies, laws and regulations, formulas

 Functional Requirements—observable behavior of system

23

 Quality Attributes—speed, ease of use, robust, reliable, secure, efficient (all must be quantified)

 External Interfaces—signals, messages, files, devices, UI standards

 Constraints—sizes, algorithms, platforms, languages

 Data Definitions—formats, types, ranges, defaults

 Solution Ideas—could be a valid constraint or other attribute

24

7.8 Knowing When You’re Done

 Users can’t think of more use cases  New use cases don’t lead to any more

functional requirements  Users repeat themselves  All new requirements are out of scope  Proposed capabilities are “sometime in the

future.”

25

7.9 Avoid Incorrect/missing Requirements

 Avoid fuzzy terms, such as process or manage  Watch for reviewers having different

interpretations  Use cases must have an actor  Trace system requirements, use cases, event

lists, business rules to functional requirements  Check boundary conditions

26

 Use multiple representations—text, graphics, tables

 Use decision tables or trees for complex logic  Create, Read, Update, Delete, List (CRUDL)

matrix—relate actions (use cases, system events to data

27

Sample CRUDL Matrix in Chemical ordering system

28

Entity Use Case Order Chemical Requester

Vendor Catalog

Place Order

Change Order

Manage Inventory

Report Orders

Edit Requestors

C R R R, L

U, D R R, L

C, U, D

R R, L R, L

C, U, L

C: Create R: Read U: Update D: Delete L: List

Some additional Elicitation Considerations:

 Imagine doing the user’s tasks (perhaps actually do them?) to find requirements

 Play the apprentice to the master user—it makes him guide the discussion (play dumb)

 Ask about exceptions—there should be lots of them  Ask for “three most annoying features” or “three

most tedious tasks” or “three most wanted changes”—ranking helps people think

 Walk through user’s logic behind work decisions  Interview enough users; don’t let the few dominate

29

END

30