Capturing Requirements

1. Problem statement
 : a clear and concise description of the issue(s) that need(s) to be addressed by a problem-solving team
 - Issues: one or two sentences that describe the problem using specific issues
 - Vision / Goals: what does the world look like if we solve the problem?
 - Method: the process that will get followed to solve the problem
 - Scope: boundaries of the proposed solution / new system
 - The 5 'W's (Who / What / Where / When / Why) is a great tool that helps write a problem statement
  * Who does the problem effect?
  * What is the issue?
  * Where is the issue occurring?
  * When does the issue occur?
  * Why is it important that we fix the problem?

http://www.ceptara.com/blog/how-to-write-problem-statement

2. From Problem Statements to the Requirements
 - Requirement engineering: the process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed
 - Types of requirement
  * User requirements: Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers
  * System requirements: A structured document setting out detailed descriptions of the system's functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor
  * Functional requirements: Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. May state what the system should not do.
  * Non-functional requirements: Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Often apply to the system as a whole rather than individual features or services

http://reqtest.com/requirements-blog/functional-vs-non-functional-requirements/

3. Requirement Engineering
 - Components
  * Requirements gathering: identifying and communicating the purpose of a software-intensive system, and the contexts in which it will be used
  * Requirements analysis: about what is need and what is possible
  * Requirements specification: documenting the system requirements in a semi-formal or formal manner
   => Desiderata for requirement specification: Valid / Unambiguous / Complete / Understandable / Consistent / Ranked / Verifiable / Modifiable / Traceable

http://www.sei.cmu.edu/productlines/frame_report/req_eng.htm

4. Tools for Requirement Engineering
 1) User Stories: similar to system requirements, but focus on the user benefits, instead on system features
 2) Scenario-Based Analysis: provides a more user-oriented view perspective on the design and development of an interactive system
 3) Use Cases: Abstractions from scenarios for usage of the system typically describing series of interactions between users and the system to be developed
  * Convenient way of generating requirements

http://www.romanpichler.com/blog/10-tips-writing-good-user-stories/

http://searchsoftwarequality.techtarget.com/definition/use-case