CS 325: Software Engineering January 22, 2015 Software Requirements Elicitation Eliciting...
-
Upload
brenda-thomerson -
Category
Documents
-
view
221 -
download
2
Transcript of CS 325: Software Engineering January 22, 2015 Software Requirements Elicitation Eliciting...
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
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.
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.
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.
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.
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.
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.
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
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