Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "CS 325: Software Engineering January 22, 2015 Software Requirements Elicitation Eliciting Requirements Functional Requirements Non-Functional Requirements."— Presentation transcript:

1

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

3 Eliciting Requirements CS 325 January 22, 2015 Page 34 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

4 Eliciting Requirements: Traditional CS 325 January 22, 2015 Page 35 Questionnaires Documents 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. Interviews Stakeholder 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 Analysis Stakeholders 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.

5 Eliciting Requirements: Group-Oriented CS 325 January 22, 2015 Page 36 Focus Groups Future 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. Brainstorming An 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. Workshops Agenda-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.

6 Eliciting Requirements: Early Feedback CS 325 January 22, 2015 Page 37 High-Fidelity Prototyping When 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 Prototyping When 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.

7 Eliciting Requirements: Model-Driven CS 325 January 22, 2015 Page 38 Goal-Based Modeling By 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 Modeling By 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.

8 Eliciting Requirements: Cognitive CS 325 January 22, 2015 Page 39 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. Laddering In 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 Sorting Class-Responsibility-Collaboration (CRC)) cards are a popular brainstorming tool for analyzing object-oriented software projects.

9 Eliciting Requirements: Contextual CS 325 January 22, 2015 Page 40 Ethnographic Observing 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 Analysis By 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.

10 Functional Requirements CS 325 January 22, 2015 Page 41 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 system 2. Teacher selects enter child comments from main menu 3. System prompts for name or ID of child 4. System sends information to web server 5. Web server verifies that child is currently enrolled 6. System prompts teacher for comments 7. Teacher enters comments and selects save from menu of options 8. System sends comments to web server for storage 9. Teacher’s employee ID number, date, and nature of change are logged 10. Teacher receives confirmation that info was saved

11 Non-Functional Requirements CS 325 January 22, 2015 Page 42 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 Documentation Extensibility Fault Tolerance Interoperability 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


Download ppt "CS 325: Software Engineering January 22, 2015 Software Requirements Elicitation Eliciting Requirements Functional Requirements Non-Functional Requirements."

Similar presentations


Ads by Google