Wiegers, Chapter 7: Requirements Elicitation

A better question is

"What do you need to do?"

When working on a replacement project ask...

"What three things annoy you the most about the existing system?"

Elicitation is

A collaborative and analytical process that includes activities to collect, discover, extract, and define requirements.

The output of requirements development is

A common understanding of the needs held by the diverse project stakeholders

Anything that doesn't fit into our categories might be

A project requirement (need to train users) A project constraint (cost, schedule restriction) An assumption or a dependency Additional info Extraneous information without value

Solution idea

A specific way to interact with the system to perform some action

Requirements workshop is

A structured meeting in which a carefully selected group of stakeholders and content experts work together to define, create, refine, and reach closure on deliverables that represent user requirements

UI analysis is

An independent elicitation technique in which you study existing systems to discover user and functional requirements

Business Requirements

Anything that describes the financial, marketplace, or other business benefit that either customers or the development organization wish to gain from the product is a BReq

Take good notes

Assign sb to be the scribe, responsible for taking accurate notes. Session notes should contain an attendee list, invitees who did not attend, decisions made, actions to be taken and who is responsible for each, outstanding issues, and the high points of key discussions

Cautions about elicitation

Balance stakeholder representation Define scope appropriately Avoid the requirements-versus-design argument Research within reason

Categories of customer input

Business Requirements (BReq) User Requirements (UR) Business Rules (BRl) Functional Requirements (FR) Quality Attributes (QA) External Interface Requirements (EIR) Constraints (C) Data Requirements (DR) Solution Ideas (Sol.Id.) Data Definition (DD)

Following up after elicitation

Consolidate input from multiple sources. Review and update notes soon after the session is complete, while the content is still fresh in your mind.

Prepare for elicitation (activities)

Decide on elicitation scope and agenda Prepare resources Prepare questions and straw man models

Plan session scope and agenda

Decide on the scope of the elicitation session, taking into account how much time is available.

Elicitation strategy and planned techniques

Decide which techniques to use with different stakeholder groups

To find missing requirements:

Decompose high-level requirements into enough detail Ensure that all user classes have provided input Trace SR, UR, event-response lists, and BRls to their FRs to make sure that all necessary functionality is derived Check boundary values for missing requirements Represent requirements information in more than one way Create a checklist of common functional areas to consider for your projects Create a data model

Expected products of elicitation efforts

Define the outcomes of elicitation activities

External Interface Requirements

Describe the connections between your system and the rest of the universe.

Tips for performing elicitation activities

Educate stakeholders Take good notes Exploit the physical space

Workshops are used to

Elicit requirements from multiple stakeholders concurrently

Interviews are also appropriate for

Eliciting business requirements from executives who don't have a lot of time to meet

Tips for conducting workshops

Establish and enforce ground rules Fill all of the team roles Plan an agenda Stay in scope Use flipcharts to capture items for later consideration Timebox discussions Keep the team small but include the right stakeholders Keep everyone engaged

Useful tips for conducting interviews

Establish rapport Stay in scope Prepare questions and straw man models ahead of time Suggest ideas Listen actively

Document analysis

Examining any existing documentation for potential software requirements

Functional Requirements

FR describe the observable behaviors the systems will exhibit under certain conditions and the actions the system will let users take

Data requirements

Format, data type, allowed values, or default value for a data element

User Requirements

General statements of user goals or business tasks that users need to perform (use cases, scenarios, user stories)

Prepare questions

Go into every facilitated elicitation session with a set of prepared questions

Schedule and resource estimates

Identify both customer and development participants for the various elicitation activities, along with estimates of the effort and calendar time required

Elicitation risks

Identify factors that could impede your ability to complete the elicitation activities as intended, estimate the severity of each risk, and decide how you can mitigate or control it

Documents and systems needed for independent elicitation

Identify the materials needed to ensure that you have docs when you need them

Learn about the stakeholders

Identify the relevant stakeholders for the session, learn about their cultural and regional preferences for meetings.

Focus group

Is a representative group of users who convene in a facilitated elicitation activity to generate input and ideas on a product's functional and quality requirements

Follow up after elicitation (activities)

Organize and share notes Document open issues

Perform elicitation (activities)

Perform elicitation session

Tips for preparing for elicitation

Plan session scope and agenda Prepare resources Learn about the stakeholders Prepare questions

Tips for writing questionnaires

Provide answer option that cover the full set of possible responses Make answer choices both mutually exclusive and exhaustive Don't phrase a question in a way that implies a "correct" answer If you use scales, use them consistently throughout the questionnaire Use closed questions with two or more specific choices if you want to use the questionnaire results for statistical analysis Consider consulting with an expert in questionnaire design to ensure that you ask the right questions of the right people Always test a questionnaire before distributing it Don't ask too many questions or people won't respond

Constraints

Restrict the options available to the developer.

Prepare resources

Schedule the physical resources needed, such as rooms, projectors, teleconference numbers, and videoconferencing equipment; and participants being sensitive to time zone differences.

Comparative reviews point out

Shortcomings in other products that you could address to gain a competitive advantage

Quality Attributes

Statements that describe how well the system does something are QA. (fast, user-friendly, reliable, secure)

Educate stakeholders

Teach your SHs about your elicitation approach and why you chose it, explain techniques you'll be using and how they can help provide better requirements

Facilitation is

The art of leading people through processes toward agreed-upon objectives in a manner that encourages participation, ownership, and productivity from all involved

An elicitation plan includes

The techniques you'll use, when you plan to use them, and for what purpose

Exploit the physical space

Use something to draw diagrams or create lists

Business Ruless

When a customer says that only certain users perform an activity under specific conditions, he might be presenting a BR

Questionnaires are

an inexpensive way to survey large groups of users to understand their needs

Hold additional discussions to resolve...

any inconsistencies and to fill in any blanks.

Implied requirements

are necessary because of another requirement but aren't explicitly stated

Assumed requirements

are those that people expect without having explicitly expressed them

Interface analysis

entails examining the systems to which your systems connect, reveals functional requirements regarding the exchange of data and services between systems

Plan the elicitation objectives...

for the entire project and the objective for each planned elicitation activity

For observations in agile,

have the user demonstrate only the specific tasks related to the forthcoming iteration

For observations, select

important or high-risk tasks and multiple user classes

If you are new to an application domain,

interviews with experts can help you get up to speed quickly

Imagine yourself learning the user's job,

or actually do the job under the user's direction

The most useful documentation includes

requirements specifications, business processes, lessons-learned collections, and user manuals for existing or similar applications

Soon after each activity,

share the consolidated notes with the participants and ask them to review them to ensure that they accurately represent the session

Probe around...

the exceptions. What could prevent the user from successfully completing a task? How should the system respond to various error conditions?

Document...

the source of each requirement so that you can obtain further clarification if needed and trace development activities back to specific customer origins

Goal of elicitation is

to accumulate a shared understanding of requirements that is good enough to let construction of the next release or increment proceed at an acceptable level of risk

Phrase questions...

to avoid leading customers down an unintended path or a specific answer

Elicitation is used

to discover business, user, functional, and nonfunctional requiremtns, along with other types of information.

To facilitate clear communication,

use the vocabulary of the business domain instead of forcing customers to understand technical jargon

Observing users helps to

validate information collected from other sources, identify new topics for interviews, see problems with the current system