Gerhard Dueck -- CS3013 Requirements Capture 1

Requirements Capture

From Vision to Requirements Why it 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.

Gerhard Dueck -- CS3013 Requirements Capture 2

Traditional approach ==> assign analysts to record the requirements

Even with analysts users did not (fully) understand the software until it was completed

Problem: the analyst specification may not be readily transformed into software

Requirements capture remains difficult!

Gerhard Dueck -- CS3013 Requirements Capture 3

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

Gerhard Dueck -- CS3013 Requirements Capture 4

Overview of Requirements Capture

Start with a business model (may already exist)

Next develop a domain model Sometimes we only have “vague

notion” Eg p. 113 (USDP)

Gerhard Dueck -- CS3013 Requirements Capture 5

List candidate requirements by feature list

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)

Gerhard Dueck -- CS3013 Requirements Capture 6

Understand system context

Domain modeling– A domain model describes the important

concepts of the context as domain objects– Identifying and naming these objects helps

us develop a glossary of terms that will enable everyone who is working on the system to communicate better

– Helps to identify classes (later)

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

Gerhard Dueck -- CS3013 Requirements Capture 7

Capture functional requirements

Uses cases User interface prototypes

Gerhard Dueck -- CS3013 Requirements Capture 8

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

Eg. p. 116

How to specify nonfunctional requirements– Use cases with tagged values

Gerhard Dueck -- CS3013 Requirements Capture 9

Resulting artifacts of workflow

Work flow Resulting artifacts

List candidate

requirementsFeature list

Understand system

context

Business or domain

model

Capture functional

requirementsUse-case model

Capture

nonfunctional

requirement

Supplementary

requirements or

individual use cases

Gerhard Dueck -- CS3013 Requirements Capture 10

Understanding the system context using 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, …

Gerhard Dueck -- CS3013 Requirements Capture 11

Eg. p. 120

Gerhard Dueck -- CS3013 Requirements Capture 12

Developing a domain model

Who should 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– Don’t give too much detail

Gerhard Dueck -- CS3013 Requirements Capture 13

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.

Gerhard Dueck -- CS3013 Requirements Capture 14

Fif. 6.4 p. 124

Gerhard Dueck -- CS3013 Requirements Capture 15

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.