Requirements Capture: From Vision to Requirements

What is requirements capture

It is the process of finding out what is to be built in terms of software system development.

Why requirements capture is difficult

Developers are not users
Inadequate requirements information from users

Individual types of users may have their individual requirements, but not the overall system requirements.
Users do not know what a software system can do or cannot do.
Users do not know performance issues of required operations.

Traditionally requirements capture is done by system analysts by interviewing users and creating a system requirements specification listing overall requirements.

Potential problem:

Requirement specifications may not readily transform into design and implementation specification.

Ever changing requirements with business changes

The purpose of the requirements workflow

Purpose: to aim development toward the right system.

How: describing the system requirements well enough so that an agreement can be reached between the customers (purchasers and users) and the system developers on what the system should and should not do.
Language: the language of the customer

Overview of requirement Capture

List candidate requirements by feature list

Content of a feature:

Name
Definition
Status (proposed, approved, incorporated, validated)
Estimated cost to implement (resource type and man-hours)
Priority (critical, important, ancillary)
Associated level of risks in implementing the feature (critical, significant, ordinary)

Understand system context

Domain modeling

A domain model describes the important concepts of the context as domain objects.

Business modeling

A business model describes the (existing or perceived) processes of the business of which the software system to be developed will be a part.

Capture functional requirements

Uses cases
User interface prototypes

Capture nonfunctional requirements

What are nonfunctional requirements:

Environmental and implementation constraints
Reliability: availability, accuracy, failure mean time, defects per k-lines/class.
Performance: speed, throughput, response time, memory usage.
Platform dependencies
Maintainability
Extendibility

How to specify nonfunctional requirements

Use cases with tagged values

Resulting artifacts of workflow

(as requirement specification)

Work flow	Resulting artifacts
List candidate requirements	Feature list
Understand system context	Business or domain model
Capture functional requirements	Use-case model
Capture nonfunctional requirement	Supplementary requirements or individual use cases.

Understanding the system context using a domain model

What is a domain model?

A domain model consists of domain objects and their relationships.

A domain object represents a thing that exists or event that transpires in environment in which the system works.

Types of domain objects:

Business objects: orders, accounts, contracts, …
Real-world objects: cars, trucks, buildings, …
Events (transpired or future): bus arrival, bus departure, dinner, …

Developing a domain model
Who do it:

Workshop with domain experts, domain analysts and modeler

How many classes in a domain model

Modest-sized: 10-50 classes

Simple domain model: glossary of terms
What should be modeled

The context of the system to be developed, not the system itself.

Use of the domain model
Use case analysis
User interface design
Class design

6. Understanding the system context using a business model

What is a business model?
A business model consists of a business use case model and a business object model.
Business use case model

describes the business process of a company in terms of business use cases and business actors corresponding to business processes and customers.
presents a business system from the usage perspective and outline how it provides value to it users (customers and partners).

Business object model

An interior model of a business
It describes how each business use case is realized by a set of workers who are using a set of business entities and work units, using interaction and activity diagrams.
Business entity

It represents something which workers access, inspect, manipulate, produce, or use in a business use case.

Work unit

A set of such entities that form a recognizable whole to an end user

How to develop a business model

Step 1: Build a business use case model

Step 2: Build an object model for each business use case

Find use cases of the (software) system from a business model

Identify an actor for every worker and business actor (i.e. customer of the business), who will become a user or actor of the system
Identify each worker/business actor's role(s) in each business case realization
Create a tentative use case for each role of each worker and business actor.