CS616 – Software Engineering II

Lecture 4

 

IDENTIFYING OTHER REQUIREMENTS

 

·       Not sufficient to write use cases

·       Other kinds of requirements that captured in the Supplementary Specification:

o      documentation,

o      packaging

o      supportability

o      licensing

·       Glossary captures terms and definitions

o      Plays the role of a data dictionary.

·       Vision summarizes the “vision” of the project

o      Serves to tersely communicate the big ideas regarding:

§       why the project was proposed

§       what the problems are

§       who the stakeholders are

§       what they need

§       what the proposed solution looks like

NextGen Example: (Partial) Supplementary Specification

Supplementary Specification

Revision History

Introduction

Document is the repository of all NextGen POS requirements not captured in the use cases.

 

Functionality

(Functionality common across many use cases)

Log all errors to persistent storage.

At various scenario points of several use cases (to be defined) support the ability to customize the functionality of the system with a set of arbitrary rules that execute at that point or event.

All usage requires user authentication.

 

Usability

Human Factors

The customer will be able to see a large-monitor display of the POS

Therefore:

· Text should be easily visible from 1 meter.

· Avoid colors associated with common forms of color blindness.

 

Speed, ease, and error-free processing are paramount in sales processing, as the buyer wishes to leave quickly, or they perceive the purchasing experience (and seller) as less positive.

 

The cashier is often looking at the customer or items, not the computer display. Therefore, signals and warnings should be conveyed with sound rather than only via graphics.

 

Reliability

Recoverability

If there is failure to use external services (payment authorizer, accounting system, ...) try to solve with a local solution (e.g., store and forward) in order to still complete a sale. Much more analysis is needed here...

 

Performance

As mentioned under human factors, buyers want to complete sales processing very quickly. One potential bottleneck is external payment authorization. Our goal is to achieve authorization in less thani minute, 90% of the time.

 

Supportability

Adaptability

Different customers of the NextGen POS have unique business rule and processing needs while pro­cessing a sale. Therefore, at several defined points in the scenario (for example, when a new sale is initi­ated, when a new line item is added) pluggable business rule will be enabled.

Contigurability

Different customers desire varying network configurations for their POS systems, such as thick versus thin clients, two-tier versus N-tier physical layers, and so forth. In addition, they desire the ability to modify these configurations, to reflect their changing business and performance needs. Therefore, the system will be somewhat configurable to reflect these needs. Much more analysis is needed in this area to dis­cover the areas and degree of flexibility, and the effort to achieve it.

 

Implementation Constraints

NextGen leadership insists on a Java technologies solution, predicting this will improve long-term porting and supportability, in addition to ease of development.

 

Purchased Components

·    Tax calculator. Must support pluggable calculators for different countries.

 

Free Open Source Components

Although it is premature to definitively design and choose components, we suggest the following as likely candidates:

·    JLog logging framework

·   …

 

Interfaces

Noteworthy Hardware and Interfaces

·    Touch screen monitor (this is perceived by operating systems as a regular monitor, and the touch gestures as mouse events)

·    Barcode laser scanner (these normally attach to a special keyboard, and the scanned input is per­ceived in software as keystrokes)

·    Receipt printer

·    Credit/debit card reader

·    Signature reader (but not in release 1)

 

Software Interfaces

For most external collaborating systems (tax calculator, accounting, inventory, ... ) we need to be able to plug in varying systems and thus varying interfaces.

 

Domain (Business) Rules

ID

Rule

Changeability

Source

RULE l

Signature required for credit payments.

Buyer “signature” will
continue to be required,
but within 2 years most
of our customers want
signature capture on a
digital capture device,
and within 5 years we
expect there to be
demand for support of
the new unique digital
code “signature” now
supported by USA law.

The policy of virtually all credit authorization companies.

RULE2

Tax rules. Sales require added taxes. See government statutes for current details.

High. Tax laws change annually, at all govern ment levels.

law

RULE3

Credit payment reversals may only be paid as a credit to the buyer’s credit account, not as cash.

Low

credit authorization company policy

RULE4

Purchaser discount rules. Examples:
Employee—20% off.
Preferred Customer—l 0% off.
Senior—i 5% off.

High. Each retailer uses different rules.

Retailer policy.

RULE 5

Sale (transaction-level) discount rules. Applies to pre-tax total. Examples:
10% off if total greater than $100 USD.
5% off each Monday.
10% off all sales between lOam and 3pm
today.
Tofu 50% off from 9am-l Oam today.

High. Each retailer uses different rules, and they may change daily or hourly.

Retailer policy.

RULE 6

Product (line item level) discount rules.
Examples:
10% off tractors this week.
Buy 2 veggieburgers, get 1 free,

High. Each retailer uses different rules, and they may change daily or hourly.

Retailer policy.

 

Legal Issues

We recommend some open source components if their licensing restrictions can be resolved to allow resale of products that include open source software.

 

All tax rules must, by law, be applied during sales. Note that these can change frequently.

 

Information in Domains of Interest

Pricing

In addition to the pricing rules described in the domain rules section, note that products have an original price, and optionally a permanent markdown price. A product’s price (before further discounts) is the per­manent markdown price, if present. Organizations maintain the original price even if there is a permanent markdown price, for accounting and tax reasons.

 

Credit and Debit Payment Handling

When an electronic credit or debit payment is approved by a payment authorization service, they are responsible for paying the seller, not the buyer. Consequently, for each payment, the seller needs to record monies owing in their accounts receivable, from the authorization service. Usually on a nightly basis, the authorization service will perform an electronic funds transfer to the seller’s account for the daily total owing, less a (small) per transaction fee that the service charges.

 

Sales Tax

Sales tax calculations can be very complex, and regularly change in response to legislation at all levels of government. Therefore, delegating tax calculations to third-party calculator software (of which there are several available) is advisable. Tax may be owing to city, region, state, and national bodies. Some items may be tax exempt without qualification, or exempt depending on the buyer or target recipient (for example, a farmer or a child).

 

Item Identifiers: UPCs, EANs, SKUs, Bar Codes, and Bar Code Readers

The NextGen POS needs to support various item identifier schemes. UPCs (Universal Product Codes),EANs (European Article Numbering) and SKUs (Stock Keeping Units) are three common identifier sys­tems for products that are sold. Japanese Article Numbers (JANs) are a kind of EAN version.

 

SKUs are completely arbitrary identifiers defined by the retailer.

Commentary:       Supplementary Specification

Supplementary Specification captures other requirements, information, and constraints not easily captured in the use cases or Glossary, including system-wide “URPS+” quality attributes or requirements.

 

Elements of the Supplementary Specification could include:

·    FURPS+ requirements—functionality, usability, reliability, performance, and supportability

·    reports

·    hardware and software constraints (operating and networking systems, -)

·    development constraints (for example, process or development tools)

·    other design and implementation constraints

·    internationalization concerns (units, languages,

·    documentation (user, installation, administration) and help

·    licensing and other legal concerns

·    packaging

·    standards (technical, safety, quality)

·    physical environment concerns (for example, heat or vibration)

·    operational concerns (for example, how do errors get handled, or how often to do backups?)

·    domain or business rules

·    information in domains of interest (for example, what is the entire cycle of credit payment handling?)

 

Constraints are not behaviors, but some other kind of restriction on the design or project.

For example:

Must use Oracle (we have a licensing arrangement with them). Must run on Linux (it will lower cost).

 

Quality Attributes

·       Some requirements are called quality attributes of a system.

·       These include:

o Usability

o Reliability

o etc.

 

·       Two types of quality attributes:

1.  Observable at execution (functionality, usability, reliability, performance, ...)

2.  Not observable at execution (supportability, testability, ...)

 

·       Functionality is specified in use cases

·       Other system-wide FURPS+ quality attributes are described in the Supplementary Specification.

·       Quality attribute most often meant to imply “qualities of the system other than functionality”

·        Quality attributes have interdependencies and involve trade-offs.

 

Domain (Business) Rules

·       Domain rules dictate how a domain or business may operate.

·       e.g.

Company policies

physical laws

government laws

·       Commonly called business rules

·       Useful to identify and record domain rules that influence the requirements realized in the use cases

o They can clarify incomplete or ambiguous use case content

o e.g., NextGen POS

if someone asks if the Process Sale use case should be written with an alternative to allow credit payments without signature capture, there is a business rule (RULE 1) that clarifies whether this will not be allowed by any credit authoriza­tion company.

 

Information in Domains of Interest

·       Often valuable for a subject matter expert to write some explanation of domains related to the new software system

·       It may contain pointers to important literature or experts, formulas, laws, or other references.

NextGen Example: (Partial Vision)

Vision

Revision History

Introduction

We envision a next generation fault-tolerant point-of-sale (POS) application, NextGen POS, with the flexi­bility to support varying customer business rules, multiple terminal and user interface mechanisms, and integration with multiple third-party supporting systems.

 

Positioning

·   Business Opportunity

Existing POS products are not adaptable to the customer’s business, in terms of varying business rules and varying network designs (for example, thin client or not; 2, 3, or 4 tier architectures). In addition, they do not scale well as terminals and business increase. And, none can work in either on-line or off-line mode, dynamically adapting depending on failures. None easily integrate with many third-party systems. None allow for new terminal technologies such as mobile PDAs. There is marketplace dissatisfaction with this inflexible state of affairs, and demand for a POS that rectifies this.

·   Problem Statement

Traditional POS systems are inflexible, fault intolerant, and difficult to integrate with third-party systems. This leads to problems in timely sales processing, instituting improved processes that don’t match the software, and accurate and timely accounting and inventory data to support measurement and planning, among other concerns. This affects cashiers, store managers, system administrators, and corporate management.

·   Product Position Statement

Terse summary of who the system is for, its outstanding features, and what differentiates it from the competition.

·   Alternatives and Competition...

 

Stakeholder Descriptions

·   Market Demographics...

·   Stakeholder (Non-User) Summary…

·   User Summary...

A one day requirements workshop with subject matter experts and other stakeholders, and surveys at several retail outlets led to identification of the following key goals and problems:

 

High-Level Goal

Priority

Problems and Concerns

Current Solutions

Fast, robust, inte-grated sales processing

high

Reduced speed as load increases.

Loss of sales processing capability if components fail,

Lack of up-to-date and accurate information from accounting and other systems due to non-integra-tion with existing accounting, inventory, and HR sys tems. Leads to difficulties in measuring and planning.

 

Existing POS prod-ucts provide basic sales processing, but do not address these problems.

 

 

Inability to customize business rules to unique busi ness requirements.

 

 

 

Difficulty in adding new terminal or user interface types (for example, mobile PDAs).

 

…

…

…

…

 

·   User-Level Goals

The users (and external systems) need a system to fulfill these goals:

·       Cashier: process sales, handle returns, cash in, cash out

·       System administrator manage users, manage security, manage system tables

·       Manager: start up, shut down

·       Sales activity system: analyze sales data

·       …

·       User Environment...

 

Product Overview

·   Product Perspective

The NextGen POS will usually reside in stores; if mobile terminals are used, they will be in close proximity to the store network, either inside or close outside. It will provide services to users, and collaborate with other systems, as indicated in figure below.

 

·       Summary of Benefits

Supporting Feature

Stakeholder Benefit

Functionally, the system will provide all the common ser-vices a sales organization requires, including sales capture, payment authorization, return handling, and so forth.

Automated, fast point-ot-sale services.

Automatic detection of failures, switching to local offline pro-cessing for unavailable services,

Continued sales processing when exter nal components fail.

Pluggable business rules at various scenario points during sales processing.

Flexible business logic configuration.

Real-time transactions with third-party systems, using industry standard protocols.

Timely, accurate sales, accounting, and inventory information, to support measur ing and planning.

 

·   Assumptions and Dependencies...

·   Cost and Pricing...

·   Licensing and Installation...

 

Summary of System Features

·       sales capture

·       payment authorization (credit, debit, check)

·       system administration for users, security, code and constants tables, and so forth.

·       automatic offline sales processing when external components fail

·       real-time transactions, based on industry standards, with third-party systems, including inventory, accounting, human resources, tax calculators, and payment authorization services

·       definition and execution of customized pluggable business rules at fixed, common points in the processing scenarios

·       …

 

Other Requirements and Constraints

Including design constraints, usability, reliability, performance, supportability, design constraints, documentation, packaging, and so forth

Commentary: Vision

Are We Solving the Same Problem? The Right Problem?

 

The Problem Statement

During early requirements work in the inception phase, collaborate to define a terse problem statement

 

Rather than prose, a table format offered in the RUP templates for problem statements is:

 

The problem of

…

affects

...

the impact of which is

...

a successful solution would be

...

 

The Key High-Level Goals and Problems of the Stakeholders

·   Table summarizes the goals and problems at a higher level than task level use cases, and reveals important nonfunctional and quality goals that may belong to one use case or span many, such as:

·       We need fault-tolerant sales processing.

·       We need the ability to customize the business rules.

 

What Are the Root Problems and Goals?

·   Common for stakeholders to express their goals in terms of envisioned solutions,

o      e.g.

“We need a full-time programmer to customize the business rules as we change them.”

·   Solutions are sometimes perceptive, because they understand their problem domain and options well.

·   Sometimes stakeholders jump to solutions that are not the most appropriate or do not address the root underlying major problems.

·   System analyst needs to investigate the problem and goal in order to learn the underlying problems and their relative importance and impact.

 

Group Idea Facilitation Methods

·   Group facilitation techniques:

o      help discover root problems and goals

o      support idea generation and prioritization

o      e.g.:

§       mind mapping

A Mind Map uses words, lines, logic, colors, images, and even sounds to stimulate your brain.

Four important characteristics:

·       The subject is represented by a central image.

·       The main themes of the subject radiate from the central image as main branches.

·       Minor themes are linked to the main themes.

·       All the branches are connected forming a nodal structure.

 

§       fishbone diagrams

·       Fishbone diagrams are cause and effect diagrams.

·       Method used to systematically define factors that may cause a problem or prevent a process from operating at its maximum efficiency (quality defects).

·       Assumes that few events have single causes and that there can be several intervening causes.

 

§       pareto diagrams

·       Pareto diagram named after Vilfredo Pareto, a 19th-century Italian economist who postulated that a large share of wealth is owned by a small percentage of the population.

·       Basic principle used to represent quality problems –

1.     Most quality problems result from a small number of causes.

2.     Quality experts refer to the principle as the 80-20 rule; that is, 80% of problems are caused by 20% of the potential sources.

·       Pareto diagram puts data in a hierarchical order allowing most significant problems to be corrected first.

 

§       brainstorming

·       Attempts to come up with many radical solutions to a problem.

·       Ideas should deliberately be as broad and odd as possible, and should be developed as fast as possible.

 

§       multi-voting

·       Narrows down a broad list to those most important

·       Used in conjunction with brainstorming

·       Procedure:

1.     group ideas/solutions if similar

2.     members who generated ideas try to combine if OK,

3.     number ideas

4.     members assign points to list,

5.     tally votes

6.     organize list by priority

 

§       dot voting

·       Way to prioritize issues

·       Dot voting gives each person several votes and allows them to distribute their votes, evenly or unevenly, across the choices.

·       Allows weighing of support for different options.

·       e.g.

1.     three dots allocated to each individual

2.     Can allolcate:

o       one dot to three separate issues

o       give all three dots to one issue

§       nominal group process

·       generic name for face-to-face group techniques in which instructions are given to group members not to interact with each other except at specific steps in the process

1.     silent idea generations

2.     round-robin sharing of ideas

3.     feedback to the group

4.     explanatory group discussion

5.     individual re-assessment

6.     mathematical aggregation of revised judgments

§       brainwriting

·       silent, written generation of ideas in a group

·       brainwriting always results in more ideas than BrainStorming

·       Adv.

1.     overcoming different levels of hierarchy in a group

2.     making participants more comfortable speaking in front of a group

3.     fostering general participation by reducing dominated conversations

4.     initially boosting ideas before a BrainStorm

§       affinity grouping

·       brainstorming method in which participants write down their ideas, organize them, and identify common themes

·       advantages over standard brainstorming:

·        Physical mobility of several ideas:

o       Each idea on a separate slip of paper

o       more difficult to organize lengthy lists of ideas on flipchart paper.

·        identifies clusters of thoughts shared by several people.

·        encourages more participation by members who are inclined to be introverted or reluctant to articulate ideas/concerns out loud.

System Features—Functional Requirements

Use cases not only way to express functional:

·        They are detailed.

o Stakeholders often want a short summary that identifies the most noteworthy functions.

·        Some functionality is naturally expressed as short statements that do not conveniently map to use case names or Elementary Business Process-level goals.

 

Alternative => system features =>  high-level, terse statements summarizing system functions.

·       Features are things a system can do.

·       They should pass this linguistic test:

The system shall do <feature X>.

The system shall do payment authorization.

·       Most system features will find detailed expression in use case text.

 

Notation and Organization

·   Short high-level descriptions are important.

·   Should be able to read the system features list quickly.

·   High level feature example:

a large multi-system project of which the POS is just one element:

·       POS services

·       Inventory management

·       Web-based shopping

·       …

·       Organize a two-level hierarchy of system features

·       Point of system features in the Vision is to summarize the functionality, not decompose it into a long list of fine-grained elements

·       e.g.:

The major features include:

·    POS services:

·       sales capture

·       payment authorization

·       ...

·    Inventory management:

·       automatic reordering

·       …

·       Sometimes second level features are equivalent to use case names

·       Most system features will find detailed expression in the use cases

 

Other Requirements in the Vision

·       System features briefly summarize functional requirements expressed in detail in the use cases.

·       The Vision can summarize other requirements that are detailed in the Special Requirements sections of use cases and in the Supplementary Specification (SS).

·       There is some risk of unhelpful duplication

·       Suggestion

o      Record other requirements in the SS or uses cases (if use case specific).

o      In the Vision, direct the reader to these for the other requirements.

 

Vision, Features, or Use Cases—Which First?

Suggested sequence for order of artifacts:

1.  Write a brief first draft of the Vision.

2.  Identify user goals and the supporting use cases.

3.  Write some use cases and start the Supplementary Specification.

4.  Refine the Vision, summarizing information from these.

NextGen Example: A (Partial) Glossary

Glossary

Revision History

Definitions

Term

Definition and Information

Aliases

Payment authorization

Validation by an external payment authorization service that they will make or guarantee the payment to the seller

 

Payment authorization request

A composite of elements electronically sent to an authorization service, usually as a char array. Elements include: store ID, customer account number, amount and timestamp

 

UPC

12 digit code that identifies a product. Usually symbolized with a bar code placed on products. See http://www.uc-council.org for details.

Universal Product Code

…

…

…

Commentary:       Glossary (Data Dictionary)

·       Glossary is a list of noteworthy terms and their definitions.

·       Goal is to record terms that are unclear, ambiguous, or which require some kind of noteworthy elaboration, such as format information or validation rules.

 

Glossary as Data Dictionary

·       Glossary also plays the role of a data dictionary,

·       Data dictionary records data about the data — metadata.

o During inception the glossary should be a simple document of terms and descriptions.

o During elaboration, it may expand into a data dictionary.

·       Term attributes:

·      aliases

·    description

·    format (type, length, unit)

·    relationships to other elements

·    range of values

·    validation rules

·       The range of values and validation rules in the Glossary constitute requirements with implications on the behavior of the system.

 

Units

·       Units (currency, measures, ...) must be considered

·       e.g. in the NextGen syste

o price cannot be just a raw number.

o must be in a Money or Currency unit that captures the notion of varying currencies .

 

Composite Terms

·       Not only for atomic terms such as “product price.”

·       Glossary should include:

o composite elements such as “sale” (which includes other elements, such as date and location)

o nicknames used to describe a collection of data transmitted between actors in the use cases.

·       e.g. in Process Sale use case, the following statement:

 

System sends payment authorization request to an external Payment Authorization Service, and requests payment approval .

 

“Payment authorization request” is a nickname for an aggregate of data, which needs to be explained in the Glossary

Reliable Specifications: An Oxymoron?

·       Written requirements can promote the illusion that the real requirements are understood and well-defined

·       A Vision and Supplementary Specification is worthwhile as an exercise in clarifying:

o  a first approximation of what is wanted

o  the motivation for the product

o  as a repository for the big ideas

Online Artifacts at the Project Website

·       Should have digital artifacts recorded only online at the project website.

·       Should be hyperlinked, or recorded in tools other than a word processor or spreadsheet.

·       e.g., the Glossary could be stored in a database table.

Not Much UML During Inception?

·       Purpose of inception is to:

·       Beyond simple UML use case diagrams, not much diagramming is often motivated.

·       More focus in inception on understanding the basic scope and 10% of the requirements, expressed in textual forms.

Other Requirement Artifacts Within the UP

·       Table below summarizes a sample of artifacts and their timing.

·       All requirements artifacts are started in inception, and primarily worked on through elaboration.

 

Discipline

Artifact

Iteration ->.

Incep.
Ii

Elab.
E1..En

Const.
C1..Cn

Trans.
T1..T2

Business Modeling

Domain Model

 

s

 

 

Requirements

Use-Case Model

s

r

 

 

Vision

s

r

 

 

Supplementary Specification

s

r

 

 

Glossary

s

r

 

 

Design

Design Model

 

s

r

 

SW Architecture Document

 

s

 

 

Data Model

 

s

r

 

Implementation

Implementation Model

 

s

r

r

Project Management

SW Development Plan

s

r

r

r

Testing

Test Model

 

s

r

 

Environment

Development Case

s

r

 

 

Sample UP artifacts and timing. s - start; r – refine

 

Inception

·       Requirements artifacts are NOT finalized in the inception phase

·       During inception, the Vision summarizes the project idea in a form to help decision makers determine if it is worth continuing, and where to start.

·       Supplementary Specification should be lightly developed during inception

·       Input into artifacts could be generated during an inception phase requirements workshop

 

Elaboration

·       Vision is refined through elaboration iterations based on feedback from:

·       Ongoing requirements investigation and iterative development make other requirements more clear and can be recorded in the SS

·       Quality attributes (for example, reliability) identified in the SS become key drivers in shaping the core architecture that is designed and programmed during elaboration.

·       Majority of terms discovered and elaborated in the Glossary during this phase.

 

·       At elaboration’s end, it is feasible to have:

o use cases

o Supplementary Specification

o Vision

·       These artifact will reasonably reflect the stabilized major features and other requirements to be completed for delivery.

 

·       At end of elaboration —

o form an agreement with stakeholders about what will be done in the remainder of the project

o make commitments (perhaps contractual) regarding requirements and schedule.

·       Need a reliable idea of “what, how much, and when.”

·       A formal agreement on the requirements is normal and expected.

·       Need a change control process (one of the explicit best practice in the UP) so that changes in requirements are formally considered and approved, rather than chaotic and uncontrolled change.

 

·       frozen sign off comment:

o In iterative development and the UP it is understood that no matter how much due diligence is given to requirements specification, some change is inevitable, and should be acceptable.

o This change could be a late-breaking opportunistic improvement in the system that gives its owners a competitive advantage, or change due to improved insight.

 

Construction

·        By construction, the major requirements—both functional and otherwise— should be stabilized

·        The SS and Vision are unlikely to experience much change in this phase.

 

FROM INCEPTION TO ELABORATION

Elaboration is the initial series of iterations during which:

·    the majority of requirements are discovered and stabilized

·    the major risks are mitigated or retired

·    the core architectural elements are implemented and proven

Checkpoint:          What Happened in Inception?

·        Inception step of the NextGen POS project may last only one week.

o      Artifacts created should be brief and incomplete

o      The phase should be quick

o      The investigation light.

 

·        Short step to determine basic

o      feasibility

o      risk

o      scope

o      decide if the project is worth more serious investigation,

·        Some likely activities and artifacts in inception include:

·    a short requirements workshop

·    most actors, goals, and use cases named

·        most use cases written in brief format

o 10-20% of the use cases are written in fully dressed detail to improve understanding of the scope and complexity

·    most influential and risky quality requirements identified

·    version one of the Vision and Supplementary Specification written

·    risk list

o      e.g.

§       leadership wants a demo at the POSWorld trade show in Hamburg, in 18 months

§       effort for a demo cannot yet be even roughly estimated until deeper investigation.

·    technical proof-of-concept prototypes and other investigations to explore the technical feasibility of special requirements

·    user interface-oriented prototypes to clarify the vision of functional requirements

·    recommendations on what components to [buy l build l reuse], to be refined in elaboration

o      e.g. a recommendation to buy a tax calculation package.

·    high-level candidate architecture and components proposed

o      brief speculation as a starting point of investigation in elaboration

§       e.g., “A Java client-side application, no application server, Oracle for the database

·    plan for the first iteration

 

On to Elaboration

·       Elaboration is the initial series of iterations during which the team:

o does serious investigation

o implements (programs and tests) the core architecture

o clarifies most requirements

o tackles the high-risk issues

·       Elaboration usually from two to four iterations

·       Each iteration is between two and six weeks

·       Each iteration is timeboxed, meaning its end date is fixed

 

·       During this phase the code and design are production-quality portions of the final system.

·       Elaboration in one sentence:

Build the core architecture, resolve the high-risk elements, define most require­ments, and estimate the overall schedule and resources.

 

·       Some key ideas and best practices that will manifest in elaboration include:

·    do short timeboxed risk-driven iterations

·    start programming early

·    adaptively design, implement, and test the core and risky parts of the architecture

·    test early, often, realistically

·    adapt based on feedback from tests, users, developers

·    write most of the use cases and other requirements in detail, through a series of workshops, once per elaboration iteration

What Is Architecturally Significant in Elaboration?

·       Early iterations build and prove the core architecture.

·       For the NextGen POS project—indeed, most—this will include:

·    Employing “wide and shallow” design and implementation

·       identify the separate processes, layers, packages, and subsystems, and their high-level responsibilities and interfaces.

·       Partially implement these in order to connect them and clarify the interfaces.

·       Modules may contain mostly “stubbed” code.

·    Refining the inter-module local and remote interfaces (this includes the finest details of the parameters and return values).

·    Integrating existing components.

o   e.g., a tax calculator.

·    Implementing simplified end-to-end scenarios that force design, implementation, and test across many major components.

o   e.g., the main success scenario of Process Sale, using the credit payment extension scenario.

 

·       Early testing for the NextGen project will include:

·    Usability testing of the user interface for Process Sale.

·    Testing of recovery when remote services, such as the credit authorizer, fail.

·    Testing of high load to remote services, such as load on the remote tax calcu­lator.

Planning the Next Iteration

Organize requirements and iterations by risk, coverage, and criticality.

· Risk includes both technical complexity and other factors, such as uncertainty of effort or usability

·   Coverage implies that all major parts of the system are at least touched on in early iterations

·   Criticality refers to functions of high business value.

 

·   Risk, Coverage, Criticality used to rank work across iterations

·   Use cases or use case scenarios are ranked for implementation

o      early iterations implement high ranking scenarios

·        ranking is done before Iteration 1

·        again before Iteration 2

·        etc

o      new requirements and new insights influence the order.

 

·       Usually based on some small-group collaborative ranking technique, a fuzzy grouping of requirements will emerge e.g.:

 

Rank

Requirement
(Use Case or Feature)

Comment

High

Process Sale Logging

Scores high on all ranking criteria. Pervasive. Hard to add late.

Medium

Maintain Users

affects security subdomain.

Low

….

...

 

·       Based on this ranking, some key architecturally significant scenarios of the Process Sale use case should be tackled in early iterations.

·       List is not exhaustive; other requirements will also be tacked.

·       An implicit or explicit Start Up use case will be worked on in each iteration, to meet its initialization needs.

 

·        Chosen requirements for the next iteration are briefly listed in an Iteration Plan.

·        If the short description in the Iteration Plan is insufficient, a task or requirement for the iteration may be written in greater detail in a separate Change Request, and given to the responsible party.

·        The overall requirements ranking is recorded in the Software Development Plan.

Iteration 1 Requirements and Emphasis: Fundamental OOA/D Skills

·        Iteration 1 of the elaboration phase emphasizes a range of fundamental and common OOA/D skills used in building object systems  

 

Iteration 1 Requirements

The requirements for the first iteration of the NextGen POS application:

·        Implement a basic, key scenario of the Process Sale use case: entering items and receiving a cash payment.

·        Implement a Start Up use case as necessary to support the initialization needs of the iteration.

·        Nothing fancy or complex is handled, just a simple happy path scenario, and the design and implementation to support it.

·        There is no collaboration with external services, such as a tax calculator or product database.

·        No complex pricing rules are applied.

·        The design and implementation of the supporting UI would is done

Incremental Development for the Same Use Case Across Iterations

·        Not all requirements in the Process Sale use case are being handled in iteration 1.

·        Common to work on varying scenarios or features of the same use case over several iterations and gradually extend the system to ultimately handle all the functionality required

·        Simple use cases may be completed within one iteration.

Use case implementation may be spread across iterations.

What Artifacts May Start in Elaboration?

·        Table below lists sample artifacts that may be started in elaboration

·        For brevity, the table excludes artifacts that may have begun in inception

·        It introduces artifacts that are more likely to start in elaboration

·        These will not be completed in one iteration - refined over a series of iterations.

 

Artifact

Comment

Domain Model

This is a visualization of the domain concepts; it is similar to a static information model of the domain entities.

Design Model

This is the set of diagrams that describes the logical design. This includes software class diagrams, object interaction dia grams, package diagrams, and so forth.

Software Architecture Document

A learning aid that summarizes the key architectural issues and their resolution in the design. It is a summary of the out standing design ideas and their motivation in the system.

Data Model

This includes the database schemas, and the mapping strate gies between object and non-object representations.

Test Model

A description of what will be tested, and how.

Implementation Model

This is the actual implementation—the source code, executa bles, database, and so on.

Use-Case Storyboards, UI Prototypes

A description of the user interface, paths of navigation, usabil ity models, and so forth.

Sample elaboration artifacts, excluding those started in inception.

USE-CASE MODEL: DRAWING SYSTEM SEQUENCE DIAGRAMS

Moving on to Iteration 1

·        The NextGen POS project has entered the first real development iteration.

·        Some light requirements work was done in inception to help decide if the project was worth more serious investigation.

·        Planning for the first iteration has been completed

·        Decided to tackle a simple cash-only success scenario of Process Sale (with no remote collaborations)

·        Goal - start a “wide and shallow” design and implementation that touches on many major architectural elements of the new system.

·        In the first iteration, many tasks related to establishing the environment (tools, people, process, and setting) occur

 

·        Focus on use case and domain modeling analysis

·        Before starting iteration 1 design work

o      further investigation of the problem domain is useful.

o      clarify the input and output system events related to our system

o      can be illustrated in UML sequence diagrams.

Introduction

·        System sequence diagram (SSD) is a fast and easily created artifact that illustrates input and output events.

·        The UML contains notation in the form of sequence diagrams to illustrate events from external actors to a system.

System Behavior

·        Before proceeding to a logical design of how a software application will work, it is useful to investigate and define its behavior as a “black box.”

·        System behavior is a description of what a system does, without explaining how it does it.

·        One part of that description is a system sequence diagram.

·        Other parts include the use cases, and system contracts

System Sequence Diagrams

·        Use cases describe how external actors interact with the software system

·        During this interaction an actor generates events to a system, usually requesting some operation in response.

·        e.g. when a cashier enters an item’s ID, the cashier is requesting the POS system to record that item’s sale.

o      That request event initiates an operation upon the system.

 

·        Isolate and illustrate the operations that an external actor requests of a system, to understand system behavior

·        The UML includes sequence diagrams as a notation that can illustrate actor interactions and the operations initiated by them.

 

·        A system sequence diagram (SSD) is a picture that shows, for a particular scenario of a use case, the events that external actors generate, their order, and inter-system events.

·        All systems are treated as a black box; the emphasis of the diagram is events that cross the system boundary from actors to systems.

 

·        An SSD should be done for the main success scenario of the use case, and frequent or complex alternative scenarios.

Example of an SSD

·        An SSD shows, for a particular course of events within a use case, the external actors that interact directly with the system, the system (as a black box), and the system events that the actors generate

·        Time proceeds downward, and the ordering of events should follow their order in the use case.

·        System events may include parameters.

 

This example is for the main success scenario of the Process Sale use case. It indicates that the cashier generates makeNewSale, enterltem, endSale, and makePayment system events.

 

SSDs and Use Cases

An SSD shows system events for a scenario of a use case, therefore it is generated from inspection of a use case


 


System Events and the System Boundary

·        To identify system events, it is necessary to be clear on the choice of system boundary

·        System boundary is usually chosen to be the software (and possibly hardware) system itself

·        In this context, a system event is an external event that directly stimulates the software

 

·        Consider the Process Sale use case to identify system events.

o      determine the actors that directly interact with the software system.

§       The customer interacts with the cashier

§       the customer is not a generator of system events; only the cashier is.

 


 


Naming System Events and Operations

System events (and their associated system operations) should be expressed at the level of intent rather than in terms of the physical input medium or interface widget level.

 

Clarity improved to start the name of a system event with a verb (add..., enter..., end..., make...), since it emphasizes the command orientation of these events.

 

Thus “enterltem” is better than “scan” (that is, laser scan) because it captures the intent of the operation while remaining abstract and noncommittal with respect to design choices about what interface is used to capture the system event.


 


Showing Use Case Text

·   Desirable to show at least fragments of use case text for the scenario, to clarify or enhance the two views

·   The text provides the details and context; the diagram visually summarizes the interaction.

 


 


SSDs and the Glossary

·        The terms shown in SSDs (operations, parameters, return data) are terse.

·        May need proper explanation so that during design work it is clear what is coming in and going out.

·        If this was not explicated in the use cases, the Glossary could be used.

SSDs Within the UP

·        SSDs are part of the Use-Case Model — a visualization of the interactions implied in the use cases.

·        SSDs were not explicitly mentioned in the original UP description, although the UP creators are aware of and understand the usefulness of such diagrams.

·        SSDs are an example of the many possible skillful analysis and design artifacts or activities that the UP or RUP documents do not mention.

 

Phases

Inception—SSDs are not usually motivated in inception.

 

Elaboration—Most SSDs are created during elaboration, when it is useful to identify the details of the system events to clarify what major operations the system must be designed to handle, write system operation contracts

 

Not necessary to create SSDs for all scenarios of all use cases — at least not at the same time.

Create them only for some chosen scenarios of the current iteration.

 

Finally, it should only take a few minutes or an half hour to create the SSDs.

 

Discipline

Artifact

Iteration->

Incep.
Ii

Elab.
E1..En

Const.
C1..Cn

Trans.
T1..T2

Business Modeling

Domain Model

 

s

 

 

Requirements

Use-Case Model (SSDs)

s

r

 

 

 

Vision

s

r

 

 

 

Supplementary Specification

s

r

 

 

 

Glossary

s

r

 

 

Design

Design Model

 

s

r

 

 

SW Architecture Document

 

s

 

 

 

Data Model

 

s

r

 

Implementation

Implementation Model

 

s

r

r

Project Management

SW Development Plan

s

r

r

r

Testing

Test Model

 

s

r

 

Environment

Development Case

s

r

 

 

Sample UP artifacts and timing. s - start; r - refine