Page 111 - Software and Systems Requirements Engineering in Practice

80 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

underwriting staff operated under (e.g., time, quality, organizational).
The output of early modeling efforts would be a business model that
described either the customer’s “as is” or “to be defined” processes.
From that business modeling effort, a product or set of IT services
would be derived to support the underwriting process as a set of
product features. As product features tend to be high level, they then
need to be analyzed by expanding all the features to show how they
are used. This is typically done in an analysis model, where each feature
is a starting point for analysis (note: features typically are shown as
abstract use cases). The analysis of each feature then results in a
coherent use case model (typically, in the same modeling tool). As the
use cases are decomposed during analysis, testable functionality is
described in concrete use cases. The full, hierarchical set of use cases
then become the requirements for product construction.
The following activities are from a project to develop an
underwriting system for a major insurance company, and they
illustrate the approach used for a typical MDRE effort.
• A business model of the organization was created, showing
how underwriting works in an insurance company. This was
accomplished by conducting requirements elicitation
meetings with corporate officers and underwriters, and
building the model in their presence with their inputs.
• When reviewing the business model, we observed that certain
operations were being done inefficiently. For example, letters
would be sent to various parties containing forms that had to
be filled out and returned (e-mail was not acceptable, as many
of the forms required signatures or notarization). There was
no tracking of when the letters were sent, and when (or if)
they came back.
• A feature was added to the new, planned underwriting
system called a “Diary” that would track all sent and returned
mail, and would automatically notify officials if responses
were not received in a timely manner.
• During analysis, the Diary feature was expanded through use
cases to define the interaction of the new underwriting system
with users, including data, form, and function. Each of the
low-level functions supported by the Diary feature, after
careful review, became a customer requirement. Finally, during
triage, the requirements were prioritized by the stakeholders
and then allocated to product releases by the project staff.
• The business model and use case model were seamlessly
integrated in that the use case (or analysis) model was an
extension of the business model. The requirements were
generated from the use case model and loaded into a
requirements database for tracking.