Page 188 - Software and Systems Requirements Engineering in Practice

154 S o f t w a r e & S y s t e m s R e q u i r e m e n t s E n g i n e e r i n g : I n P r a c t i c e

unwieldy effort that is vulnerable to analysis paralysis. Therefore, we
recommend these approaches:

• Use brainstorming to identify factors, issues, and strategies,
but don’t insist on fully documenting every idea that comes
up. Use priority and status attributes to mark certain items as
deferred (we’ve decided not to work on it right now), and/or
low priority.
• Use face-to-face prioritization meetings within the analysis
team to narrow down the list of high-priority issues to less
than 20. Eventually, the architects will most likely focus on
fewer than 10 issues, but they need a longer list to choose
from. Simple voting can help focus the meeting’s attention,
but then you should discuss the borderline cases to seek
consensus on whether to include them or exclude them from
the high-priority list.
• Use time-boxed scheduling (e.g., sprints in agile terminology)
to limit the amount of time you spend on global analysis;
then pull together what you know and assess whether
additional time is needed, and how it should be spent.
• Drive the analysis toward the document in which it will be
published for outside review. The purpose of this document
will typically be to win buy-in for the early architecture
concepts you’ve selected, by showing how they address
stakeholder concerns and other dangers you’ve uncovered.
The document only needs to include the factors and issues
that justify the strategies selected and the key architectural
concepts adopted. It should be a persuasive document with a
flowing narrative, and not just a catalog of factors, issues,
strategies, and architecture concepts.

5.6 Testing ASRs
Although we have argued that architecturally significant requirement
(ASRs) carry high risk because they cannot be fully tested until very
late in development, we now argue almost the opposite: critical ASRs
should be partially tested early in development, and retested frequently
as development proceeds.
The problem with not testing ASRs is that whatever is not being
tested tends to be ignored. Therefore, once you have prioritized the
ASRs on a project, you must devise a way to test the most important
ones, in order to keep the team’s attention focused on them. However,
the most important ASRs are typically based on quality-in-use
attributes, which by definition cannot be measured until the system
is put into use. Fortunately, as you saw in our earlier example, one
can usually find internal quality attributes that are indicative of
quality-in-use attributes.