• Actor
• Elicitation
• Functional Requirement
• JAR/JRP and JAD
• Non-functional Requirement
• Release Management
• Requirement
• Requirements Acquisition
• Requirements Analysis
• Requirements Capture
• Requirements Discovery
• Requirements Engineering
• Requirements Gathering
• Requirements Management
• SME
• Stakeholder
• Systems Analysis
• User Story
• Use Case
• Use Case Model
• Use Case Narrative

Actor

A user (person or external system) who initiates the use case.

Elicitation

Finding the right people (stakeholders or SMEs) to talk with, conducting interviews and JAR/JAD sessions, and capturing the the requirements.

Functional Requirement

A requirement that specifies an action the system must be capable of performing. (As opposed to a Non-functional Requirement.)

JAR / JRP and JAD

Joint Application Requirement (JAR) session.  Also known as a Joint Requirement Planning (JRP) session.
Versus a Joint Application Design (JAD) session.

These sessions are workshops attended by stakeholders, SMEs, and users so the project team can capture requirements.  The are typically used for rapid prototyping.  The purpose of the JAR/JRP is to capture functional requirements, while the JAD's purpose is to define the user and application interfaces.

Non-functional Requirement

A requirement that specifies an aspect of the system that does not directly relate to behavior, such as reliability, maintainability, and performance. (As opposed to a Functional Requirement.)

Release Management

An activity that defines the contents of iterations and releases; also known as Iteration Planning. This is typically driven by requirements' priority, but other factors can come into play as well.

• A product plan describes (among other things) the product's lifetime and when certain features are needed in the marketplace.

• This leads to planning multiple external releases. These are releases to the customer that might or might not be deployed to all sites. Each external release is considered a project. The project lifecycle pertains to that specific project. Release 1's SRS contains only the requirements for that release. Release 2's SRS is a modification of the Release 1 SRS, and so on.

• Within the project, multiple iterations are planned. Typically, an internal release marks the end of each iteration. An iteration can be sent to the client's site, but is considered preliminary and not an official external release that can be deployed.

• Release planning is dictated by market need, whereas iteration planning is usually guided by risks and achieving small successes.

• Refer to my Configuration Management page.

Requirement

A capability and objective to which a system must conform.  A requirement should be necessary, testable, feasible, clear, and traceable.  Most requirements are dynamic; they change over time.

Writing Good Requirements.

University of Bath's definitions.

Requirements Acquisition

See Requirements Capture.

Requirements Analysis

The process of studying a business's processes to determine the business needs and functional requirements that a system must meet.

The process of studying user needs to arrive at a definition of system or software requirements. -- ANSI/IEEE Std 729/1983.

Requirements Capture

Finding, identifying, obtaining, and determining requirements.  This activity involves understanding the customer's business needs.

Requirements Discovery

See Requirements Capture.

Requirements Gathering

See Requirements Capture.

Requirements Engineering

A systematic approach to:

• analyze and manage requirements,
• establish and maintain agreement between the customer and the project team, and
• produce a system of good quality.

See Requirements Analysis and Requirements Management.

Requirements Management

The process of:

• maintaining the set of requirements that the product must satisfy and
• supporting the Requirements Analysis effort and its relationships with the other development stages.

SEI's CMM definition

SME

Subject Matter Expert.  A personal who is knowledgeable about a particular topic.

Stakeholder

A person who holds a stake, or has an interest in, the particular subject.

Systems Analysis

See Requirements Engineering.

University of San Francisco's definitions.

User Story

A user story is sometimes used instead of a use case. Here is a sample:

As a supervisor, I want to review my staff's timesheets and approve or reject them so that they can be paid, and time accounting and payroll are accurate.

Use Case

A sequence of actions that occur in the system, upon an actor's request, that produce an observable result.  Use cases are part of the Unified Modeling Language (UML) and are used in most object-oriented software development processes such as Rational?s Unified Process^TM and Select?s Perspective^TM.  See Use Case Model.

Use Case Model

1. A system's intended functions (use cases bundled into major functional areas) and its surroundings (actors).  It describes the complete system from the user perspective.  It typically includes a system context diagram to relay the scope of the system.

2. The combination of all use-cases for a particular system. The sum of all use-cases should be the complete set of functional requirements for the system.

Use Case Narrative

A descriptive narrative of a behavior or set of behaviors triggered by events sent to the system by human user(s), other systems, hardware components, or an internal clock.

QUOTES

• Software Productivity Center Inc. (http://www.spc.ca/)

  • If there is a single collection of information that should be clearly documented and maintained on a software project, it is the software requirements (variously known as the SRS, the spec, the requirements, etc). A specification of the product to be produced is the central source of information for all stakeholders in a project.

    It should be complete, consistent, understood and agreed upon and followed by everyone in the organization. It should cover both the functional capabilities of the product ... as well as the non-functional capabilities .... It should be the basis of estimates ..., test activities ..., development activities, and marketing projections ....

    It needs to be managed ..., not only in its original creation, but in the changes to the specification throughout the life of the project .... There is likely a need for the contents to be prioritized ..., and all stakeholders must agree on the content: Development, QA, Marketing, Project Management, and the end-user representative, if not included in this list ....

    While you may have documents for your project, if you don't have all the attributes above covered, you likely don't have an adequate spec!

• I have two favorite quotes that you can think about:

  • Customer: "I know that's what I said, but it's not what I want."

  • Developer: "Why are the requirements changing!?!"