Resolution for Product Design

Forward

Resolution for Product Design
Generating Product Requirements

Prof. David Bernstein
James Madison University

Computer Science Department

bernstdh@jmu.edu

Print

A Reminder

Back

Forward

Analysis for Product Design:
- Understanding the problem
Resolution for Product Design:
- Creating a solution (i.e., generating product requirements)

Types of Requirements

Back

Forward

Functional Requirement:
- How a product must map inputs to outputs (i.e., behavioral requirements)
Nonfunctional Requirement:
- A statement that a product must have certain properties (e.g., quality, performance and security requirements)
Data Requirement:
- A statement that certain data must be input to, output from, or stored by a product

Levels of Abstraction

Back

Forward

User-Level Requirement:
- A statement about how a product must support stakeholders in achieving their goals
Operation-Level Requirement:
- A statement about individual operations, inputs, outputs, etc... that a product must have/provide
Physical-Level Requirement:
- A statement about the physical form of a product, its physical interface to its environment, or its data formats

Recording Requirements

Back

Forward

Structured Text:
- The system must...
Z (pronounced Zed):
- Uses first-order predicate logic and set theory
Use Cases:
- Use case descriptions and UML Use case Diagrams
User Stories:
- Card, conversations, and confirmation

Requirements Generation in Context

Back

Forward

In Heavyweight/Non-Incremental Software Processes:
- Product design is (mostly) completed "up front" and the result is (mostly) "set in stone"/"non-negotiable" (as would be the case for a manufactured product)
In Agile/Incremental Processes:
- The requirements are modified continuously (based on conversations and negotiations with stakeholders)

There's Always More to Learn

Back