Page 353 - Software and Systems Requirements Engineering in Practice

x
n
d
e
I I n d e x 315 315
conflicting, 237–238 system boundaries, 45–46
consistency, 11–12 team isolation and, 4
context, 44 tips for gathering, 68–69
contradictions, 11–12 traceability. See traceability
correct, 9 transparency, 250
covered by test cases, 217 “umbrella,” 14
cross-cutting, 85–86, 128 unambiguous, 10–11
defect rates, 15, 129, 221 valid, 9, 10
dependencies, 214 verifiable, 11
detail level, 238–239 volatility, 45, 198, 206
eliciting. See elicitation requirements analysis, 8
example of, 63 requirements analysis model, 74
vs. factors, 151–152 Requirements Analyst role, 201
feasibility of, 9, 14 requirements artifacts. See
function points and, 16 artifacts
functional. See functional requirements automation, 67
requirements requirements baseline, 195, 199
high-level, 238 requirements data management
identifying risks, 15 system (RDMS), 198–199,
importance of good 212–213
practices, 194 requirements database (RDB),
incompatible, 243 291–300
incomplete, 217 advanced features, 297–299
marketing/sales and, 6 attribute propagation, 297–299
modifiable, 11 basic features, 295–297
new/changed, 6 commercial, 210–211, 293
nonfunctional. See NFRs configuration, 292
nonprioritized, 237–238 considerations, 300
performance, 227–228 creating, 210–213
prioritizing, 53–55, 69, 199, 210 hazard analysis activities,
project failure and, 15 280–281
quality attribute. See quality metrics, 217, 294–295
attribute requirements multidimensional support,
ranking, 53–55 299, 300
rapid development. See rapid overview, 292–295
development techniques prerequisites, 293
rapid iteration of feedback, product line RDB, 299–300
244–245 product maps, 299–300
vs. requests, 44 vs. traditional database, 292
reuse, 254 terminology, 293–295
scalability, 227–228 requirements database
separating context from, 44 schema, 217