CS 325: Software Engineering January 22, 2015 Software Requirements Elicitation Eliciting...

10
CS 325: Software Engineering January 22, 2015 Software Requirements Elicitation Eliciting Requirements Functional Requirements Non-Functional Requirements

Transcript of CS 325: Software Engineering January 22, 2015 Software Requirements Elicitation Eliciting...

Page 1: CS 325: Software Engineering January 22, 2015 Software Requirements Elicitation Eliciting Requirements Functional Requirements Non-Functional Requirements.

CS 325: Software Engineering

January 22, 2015

Software Requirements Elicitation• Eliciting Requirements• Functional Requirements• Non-Functional

Requirements

Page 2: CS 325: Software Engineering January 22, 2015 Software Requirements Elicitation Eliciting Requirements Functional Requirements Non-Functional Requirements.

Eliciting Requirements

CS 325January 22, 2015Page 2

Various techniques have emerged for determining a customer’s needs.

Traditional: Questionnaires, Interviews, Process Analysis

Group-Oriented: Focus Groups, Brainstorming, Workshops

Early Feedback: Prototyping (High- and Low-Fidelity)

Model-Driven: Goal-Based, Scenario-Based

Cognitive: Protocol Analysis, Laddering, Card Sorting

Contextual: Ethnography, Conversation Analysis

Page 3: CS 325: Software Engineering January 22, 2015 Software Requirements Elicitation Eliciting Requirements Functional Requirements Non-Functional Requirements.

Eliciting Requirements: Traditional

CS 325January 22, 2015Page 3

QuestionnairesDocuments with pre-

defined sets of questions and respective options are handed out to all

stakeholders to answer, and are later collected

and compiled.

Shortcoming: If an option for some issue is not

mentioned in the questionnaire, the issue

might be left unattended.

InterviewsStakeholder interviews may be closed (with all questions decided in

advance) or open (non-structured, more

flexible, less biased).

Shortcoming: Interviewees may be inadvertently led to emphasize or de-

emphasize the interviewer’s

viewpoint.

Process AnalysisStakeholders provide a

step-by-step explanation how they currently operate and

how they want to operate with the new

software.

Shortcoming: Critical steps in the process

might be neglected by stakeholders who

consider them obvious.

Page 4: CS 325: Software Engineering January 22, 2015 Software Requirements Elicitation Eliciting Requirements Functional Requirements Non-Functional Requirements.

Eliciting Requirements: Group-Oriented

CS 325January 22, 2015Page 4

Focus GroupsFuture users are interviewed in a

moderated group setting, in an informal manner conducive to

open discussion.

Shortcoming: Results tend to be subjective, rather than objective.

BrainstormingAn informal debate is held among various

stakeholders, with all input recorded for future

analysis.

Shortcoming: Care must be taken to ensure that the discussion does not

stray too far afield.

WorkshopsAgenda-driven

discussions in which experiences and ideas

are shared and problems are

identified.

Shortcoming: Without clear goals at the

center of the discussion, these can be a waste of time.

Page 5: CS 325: Software Engineering January 22, 2015 Software Requirements Elicitation Eliciting Requirements Functional Requirements Non-Functional Requirements.

Eliciting Requirements: Early Feedback

CS 325January 22, 2015Page 5

High-Fidelity PrototypingWhen the client’s requirements are well-defined, the developer creates a prototype with the appearance of the specified interface.

Shortcoming: Clients may be reluctant to ask for modifications in what seems to be an almost complete implementation.

Low-Fidelity PrototypingWhen the requirements are more

nebulous, the developer creates a rough prototype to provide the broad

strokes.

Shortcoming: Clients may not get a clear idea of the developer’s

conceptualization if the prototype is too rough.

Page 6: CS 325: Software Engineering January 22, 2015 Software Requirements Elicitation Eliciting Requirements Functional Requirements Non-Functional Requirements.

Eliciting Requirements: Model-Driven

CS 325January 22, 2015Page 6

Goal-Based ModelingBy tying each software requirement to a specific objective that the software needs to meet, developers avoid over-specifying or missing actual requirements.

Shortcoming: Articulating the goals of the software might be difficult and time-consuming.

Scenario-Based ModelingBy expanding use cases into full narratives

about how particular users will utilize the software system, the requirements of the

system become clearer.

Shortcoming: Developing these scenarios can be an arduous process, involving

extensive creativity.

Page 7: CS 325: Software Engineering January 22, 2015 Software Requirements Elicitation Eliciting Requirements Functional Requirements Non-Functional Requirements.

Eliciting Requirements: Cognitive

CS 325January 22, 2015Page 7

Protocol Analysis

This psychology technique asks users

to verbalize their thought processes as they perform tasks in order to gain insight into how they think about those tasks.

Shortcoming: Users sometimes get

distracted while trying to verbalize, resulting in a loss of speed and

accuracy.

LadderingIn an effort to

uncover deeper motivations, this method probes

progressively further into the responses of each question asked

of the user.

Shortcoming: Users may get frustrated

by the repeated probing, which can get repetitive and

tedious.

Card SortingClass-Responsibility-

Collaboration (CRC)) cards are a popular brainstorming

tool for analyzing object-oriented software projects.

Page 8: CS 325: Software Engineering January 22, 2015 Software Requirements Elicitation Eliciting Requirements Functional Requirements Non-Functional Requirements.

Eliciting Requirements: Contextual

CS 325January 22, 2015Page 8

EthnographicObserving potential users in their actual work environment can provide developers a clearer, unfiltered notion of their actual requirements

Shortcoming: User behavior might be affected by the knowledge that they are being observed.

Conversation AnalysisBy analyzing transcripts of video or audio

interactions of potential users, developers discern patterns of behavior that can

subtly impact a system’s requirements.

Shortcoming: Deciding whether turn-taking, interruptions, etc., are an essential

part of system interaction is frequentlydifficult to accomplish.

Page 9: CS 325: Software Engineering January 22, 2015 Software Requirements Elicitation Eliciting Requirements Functional Requirements Non-Functional Requirements.

Functional Requirements

CS 325January 22, 2015Page 9

While use cases outline the general use of a software system, scenarios provide narratives of its use by specific users.Use-Case: Enter child comments

Primary Actor: Teacher

Goal in Context: To add comments about a child

Preconditions: The child is enrolled in the day care center

Trigger: A teacher needs to enter a comment about a child

Scenario:1. Teacher logs onto system2. Teacher selects enter child comments from main

menu3. System prompts for name or ID of child4. System sends information to web server5. Web server verifies that child is currently enrolled6. System prompts teacher for comments7. Teacher enters comments and selects save from

menu of options8. System sends comments to web server for

storage9. Teacher’s employee ID number, date, and nature

of change are logged10. Teacher receives confirmation that info was

saved

Page 10: CS 325: Software Engineering January 22, 2015 Software Requirements Elicitation Eliciting Requirements Functional Requirements Non-Functional Requirements.

Non-Functional Requirements

CS 325January 22, 2015Page 10

While use cases model the functional requirements of the planned software (i.e., the actions the software will be able to perform), non-functional requirements stipulate the inherent properties of the planned software.

Examples:• Accessibility• Backup• Compliance• Documentatio

n• Extensibility• Fault

Tolerance• Interoperabilit

y

• Maintainability• Open Source• Price• Reliability• Security• Testability• Usability

Non-Functional

Requirements

Product Requirements

Usability Requirements

Efficiency Requirements

Performance Requirements

Space Requirements

Reliability Requirements

Portability Requirements

Organizational Requirements

Delivery Requirements

Implementation

Requirements

Standards Requirements

External Requirements

Interoperability

Requirements

Ethical Requirements

Legislative Requirements

Privacy Requirements

Safety Requirements