Requirements Elicitation

References:

1. Bernd Bruegge and Allen H. Dutoit, "Object-Oriented Software Engineering", Third Edition, Chapter 4

4.1 - Introduction: Usability Examples

4.2 - An Overview of Requirements Elicitation

4.3 - Requirements Elicitation Concepts

4.3.1 - Functional Requirements

4.3.2 - Nonfunctional Requirements

• FURPS+ :
  • Functional
  • Usability
  • Reliability
  • Performance
  • Supportability
  • Implementation requirements
  • Interface requirements
  • Operations requirements
  • Packaging requirements
  • Legal requirements

4.3.3 - Completeness, Consistency, Clarity, and Correctness

4.3.4 - Realism, Verifiability, and Traceability

4.3.5 - Greenfield Engineering, Reengineering, and Interface Engineering

4.4 - Requirements Elicitation activities

4.4.1 - Identifying Actors

4.4.2 - Identifying Scenarios

• Four types of scenarios:
  • As-is scenarios describe the current situation.
  • Visionary scenarios describe a future system.
  • Evaluation scenarios describe user tasks to be used to evaluate the system.
  • Training scenarios are used for tutorials and other training aids.

  

4.4.3 - Identifying Use Cases

4.4.4 - Refining Use Cases

The following aspects of use cases are detailed during refinement:

• The elements that are manipulated by the system are detailed.
• The low-level sequence of interactions between the actor and the system are specified.
• Access rights ( to initiate scenarios ) are specified
• Missing exceptions are identified and their handling specified.
• Common functionality among use cases are factored out.

4.4.5 - Identifying Relationships among Actors and Use Cases

Communication relationships between actors and use cases

Extend relationships between use cases

Include relationships between use cases

Extend versus include relationships

• Use include relationships to factor out commonly occurring normal activities that are common to multiple use-cases. Included use-cases are often capable of standing alone as use-cases, and are usually invoked from other use-cases at predictable points. Example: Printing.
• Use extend relationships to document unusual, exceptional, error, and rarely occurring use-cases. Extend use-cases generally cannot stand alone, and in general could be invoked from any point in a number of use cases. Example: Power failure.

4.4.6 - Identifying Initial Analysis Objects

4.4.7 - Identifying Nonfunctional Requirements

4.5 - Managing Requirements Elicitation

4.5.1 - Negotiating Specifications with Clients: Joint Application Design

4.5.2 - Maintaining Traceability

4.5.3 - Documenting Requirements Elicitation

4.6 - ARENA Case Study

4.6.1 - Initial Problem Statement

4.6.2 - Identifying Actors and Scenarios

4.6.3 - Identifying Use Cases

4.6.4 - Refining Use Cases and Identifying Relationships4.6.5 - Identifying Nonfunctional Requirements

4.6.5 - Identifying Nonfunctional Requirements

4.6.6 Lessons Learned

Supplemental Material

The following material is excerpted from "Mastering the Requirements Process", 2nd edition, by Robertson and Robertson. It is a required textbook when I teach CS 442, Software Engineering II.