Upload
zachary-rivas
View
29
Download
2
Embed Size (px)
DESCRIPTION
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 - PowerPoint PPT Presentation
Citation preview
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.