The first step in the elicitation process occurs at the very start of the project during an activity sometimes referred to as “project blastoff”[12]. During this phase of the project, the problem domain is explored in order to understand the
context in which the proposed software application will execute. The task can be
simplified by decomposing the domain into subdomains [13]. As illustrated in Figure 3, a preliminary decomposition of an emergency dispatch center identifies subdomains such as GPS tracking, emergency services such as police and fire services, and call dispatch. Robertson refers to sub-domains as ‘adjacent systems’, because they are the systems (whether manual or automated), with which the proposed application will interact [9,12].
The requirements elicitor works with an initial group of stakeholders to identify the sub-domains of the problem. Once these sub-domains have been identified, an additional set of stakeholders or “Subject Matter Experts” (SMEs) are selected
to explore each one more fully.
Defines standard
Replaced/Superseded by document(s)
Cancelled by
Amended by
| File | MIME type | Size (KB) | Language | Download | |
|---|---|---|---|---|---|
| Paper Software Reqts CSDP_RE.pdf | application/pdf | 366.58 KB | English | DOWNLOAD! |
Provides definitions
Abstract
This tutorial describes the activities and work products that contribute to the specification and validation of the software requirements of a system. Although requirements practices are closely related to specific software development life cycle models, the general activities described in this paper are common to most process models. The activities of elicitation, analysis, specification, validation, and requirements management are discussed and recommended practices in each of those areas are highlighted. Characteristics of a quality requirements specification are also described.