SDT-Lec 3 - Other Requirments

3/17/2022
EC-460
Software Design and Testing
(SDT)
Lec 3: Other Requirements
1
3/17/2022
Sequence
◼ Introduction
◼ (Partial) Supplementary Specification
◼ (Partial) Vision
◼ (Partial) Glossary
◼ Business Rules (Domain Rules)
Dr Farooque Azam, CEME, NUST 4
2
3/17/2022
INTRODUCTION
Other Requirements
Use cases aren't the whole story: -
◼ The Supplementary Specification captures and identifies other kinds
of requirements, such as reports, documentation, packaging,
supportability, licensing, and so forth.
◼ The Glossary captures terms and definitions; it can also play the role
of a data dictionary.
◼ The Vision summarizes the "vision" of the project an executive
summary. It serves to tersely communicate the big ideas.
◼ The Business Rules (or Domain Rules) capture long-living and
spanning rules or policies, such as tax laws, that transcend one
particular application.
3
3/17/2022
Should We Analyze Requirements Thoroughly

During Inception? (1/2)
◼ No. The UP is an iterative and evolutionary method.

◼ Feedback from early programming and tests evolve the
requirements.
◼ Research shows that: -
1. It is useful to have a high-level "top ten" list of
coarse-grained requirements near the start.
2. It is also useful to spend significant early time
understanding the Non-Functional Requirements
(NFRs) (such as performance or reliability), as these
have a significant impact on architectural choices
Should We Analyze Requirements Thoroughly

During Inception? (2/2)
3. It is a misunderstanding to believe that early detailed

requirements are useful or reliable on software
projects
4. In fact, almost 50% of early waterfall-specified
features are never used in a system
◼ What really matters is quickly building software that
passes the acceptance tests defined by the users, and
that meets their true goals, which are often not
discovered until users are evaluating or working with the
software
4
3/17/2022
Need for Vision & SS

◼ Writing a Vision and Supplementary Specification (SS) is
worthwhile as an exercise in clarifying a first
approximation of what is wanted, the motivation for the
product, and as a repository for the big ideas.
◼ But these are not expected to be reliable specifications
in early phases
◼ Hence, treat written requirements lightly, start
programming early, and continually; ideally, daily engage
users for feedback
◼ Requirement artifacts should usually be digital artifacts
recorded only online at the project website
SUPPLEMENTARY
SPECIFICATIONS
10
5
3/17/2022
SS Template – Main Heading

1. Introduction
2. Functionality
3. Usability
4. Reliability
5. Performance
6. Supportability
7. Design Constraints
8. Online User Documentation and Help System Requirements
9. Purchased Components
10. Interfaces
11. Licensing Requirements
12. Legal, Copyright, and Other Notices
13. Legal, Copyright, and Other Notices
11
NextGen Example:
(Partial) Supplementary Specification –(1/ 16)
1. Revision History
2. Introduction
This document is the repository of all NextGen POS requirements
not captured in the use cases
3. Functionality
(Functionality common across many use cases)
12
6
3/17/2022
NextGen Example:
4. Logging and Error Handling

Log all errors to persistent storage.
5. Pluggable Rules
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
13
NextGen Example:
6. Security
All usage requires user authentication
7. 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.
14
7
3/17/2022
NextGen Example:
8. Reliability
Recoverability
If there is a 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....
15
NextGen Example:
9. Performance
As mentioned under human factors, buyers want to complete sales
processing very quickly. One bottleneck is external payment
authorization.
Our goal: authorization in less than 1 minute, 90% of the time.
16
8
3/17/2022
NextGen Example:
10. Supportability
Adaptability
 Different customers of the NextGen POS have unique business

rule and processing needs while processing a sale.
 Therefore, at several defined points in the scenario (for

example, when a new sale is initiated, when a new line item is
added) pluggable business rule will be enabled.
17
NextGen Example:
10. Supportability
Configurability
 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 discover the
areas and degree of flexibility, and the effort to achieve it..
18
9
3/17/2022
NextGen Example:
11. 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
12. Purchased Components

Tax calculator. It must support pluggable calculators for different
countries
19
NextGen Example:
13. Free Open-Source Components

In general, we recommend maximizing the use of free Java
technology open-source components on this project.
Although it is premature to definitively design and choose

components, we suggest the following as likely candidates:
◼ JLog logging framework
◼ …
20
10
3/17/2022
NextGen Example:
14. 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 perceived in software as keystrokes)
• Receipt printer
• Credit/debit card reader
• Signature reader (but not in release 1)
21
NextGen Example:
14. Interfaces
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
22
11
3/17/2022
NextGen Example:
15. Application-Specific Domain (Business) Rules

(See the separate Business Rules document for General Rules.)
ID Rule Changeability Source

RULE1 Purchaser discount rules. High. Retailer
Examples: Each retailer uses different rules. policy.
Employee20% off.
Preferred Customer10% off.
Senior15% off.
RULE2 Sale (transaction-level) High. Retailer
discount rules… … policy
…..
23
NextGen Example:
16. Legal Issues

All tax rules must, by law, be applied during sales.
Note: that these can change frequently
17. Information in Domains of Interest

Pricing
Note that products have an original price, and optionally a

permanent markdown price
24
12
3/17/2022
NextGen Example:

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.
 On a nightly basis, the authorization service will perform an

electronic funds transfer to the seller's account for the daily total
25
NextGen Example:

Sales Tax
 Sales tax calculations can be very complex.
 Therefore, delegating tax calculations to third-party calculator

software (of which there are several available) is advisable
26
13
3/17/2022
NextGen Example:
17. 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
systems for products that are sold.
❑ Japanese Article Numbers (JANs) are a kind of EAN version
27
Commentary: Supplementary Specification
◼ The 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
◼ Note that non-functional requirements specific to a use case can
(and probably should) be first briefly written within the use case, in
the Special Requirements section while you are thinking through
the use case.
◼ But, after that informal step, these should then be moved to the
Supplementary Specification (SS), to keep all non-functional
requirements in one place, and not duplicated.
[#] "URPS+" (usability, reliability, performance, supportability, and more)
28
14
3/17/2022

◼ Quality Attributes (usability, reliability, and so forth…)
 Architectural analysis and design are largely concerned with the
identification and resolution of the quality attributes in the
context of the functional requirements
 For example, suppose one of the quality attributes is that the

NextGen system must be quite fault-tolerant when remote
services fail.
 From an architectural viewpoint, that will have a significant

influence on large-scale design decisions
29
◼ Which Functional Req to be placed in SS?

 Some functions or features don't fit in a use case format. For
example: “add EJB Entity Bean 1.0 support.“
 The UP certainly allows this feature-oriented approach to
requirements, in which case the feature list goes in the
Supplementary Specification
◼ Business Rules
 Broad domain rules such as tax laws belong in the UP
Business Rules artifact
 However, more narrow application-specific rules, such as how
to calculate a line-item discount, can be recorded in the SS
30
15
3/17/2022
VISION
31
Vision Template – Main Headings
1. Introduction
2. Positioning
3. Stakeholder and User Descriptions
4. Product Overview
5. Product Features
6. Constraints
7. Quality Ranges
8. Precedence and Priority
9. Other Product Requirements
10. Documentation Requirements
32
16
3/17/2022
NextGen Example: (Partial) Vision (1/9)

1. Revision History
2. Introduction
We envision a next-generation fault-tolerant point-of-sale (POS)
application, NextGen POS, with the flexibility to support varying
customer business rules, multiple terminal and user interface
mechanisms, and integration with multiple third-party supporting
systems
33

3. Positioning
a. Business Opportunity (write as a small paragraph)
◼ 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 businesses
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…
34
17
3/17/2022
NextGen Example: (Partial) Vision (3/9 )

3. Positioning
c. Problem Statement
[Provide a statement summarizing the problem being solved by this project. The
following format may be used:]
The problem of [describe the problem]

[the stakeholders affected by the
affects
problem]
the impact of which is [what is the impact of the problem?]
a successful solution [list some key benefits of a successful

would be solution]
35

3. Positioning
c. Problem Statement
traditional POS systems is that, they are inflexible, fault
The problem of intolerant, and difficult to integrate with third-party systems
cashiers, store managers, system administrators, and corporate
affects management
problems in timely sales processing, instituting improved
processes that don't match the software, and accurate and timely
the impact of which is accounting and inventory data to support measurement and
planning, among other concerns
a successful solution to provide flexibility to support varying customer business rules,

multiple terminal and user interface mechanisms, and integration
would be with multiple third-party supporting systems
36
18
3/17/2022

3. Positioning
b. Product Positioning Statement
For [target customer]

Who [statement of the need or opportunity]
The (product name) is a [product category]
[statement of key benefit; that is, the

That
compelling reason to buy]
Unlike [primary competitive alternative]

Our product [statement of primary differentiation]
37

3. Positioning
b. Product Positioning Statement
For POS System Users / Stores / Retailers
Who Need a flexible POS System
The (product
NextGen POS System
name)
Provides fault-tolerant sales processing and the ability to customize the
That business rules
Traditional POS systems that are inflexible, fault intolerant, difficult to
Unlike integrate with third-party systems and integrable with multiple third-party
supporting systems
Is capable to support varying customer business rules, multiple terminal and
Our product user interface mechanisms, and integration with multiple third-party
supporting systems
38
19
3/17/2022

4. Key High-Level Goals and Problems of the Stakeholders
A one-day requirements workshop with subject matter experts and
other stakeholders, and surveys at several retail outlets led to the
identification of the following key goals and problems:
High-Level Priority Problems and Concerns Current

Goal Solutions
Fast, high •Reduced speed as load increases. Existing POS
robust, •Loss of sales processing capability if components fail. products
integrated •Lack of up-to-date and accurate information from accounting provide basic
sales and other systems due to non-integration with existing sales
processing accounting, inventory, and HR systems. Leads to difficulties in processing,
measuring and planning. but do not
•Inability to customize business rules to unique business address these
requirements. problems.
•Difficulty in adding new terminal or user interface types (for
example, mobile PDAs).
39

4. User-Level Goals
A one-day requirements workshop with subject matter experts and other
stakeholders, and surveys at several retail outlets led to the
identification of the following key goals and problems:
[This may be the Actor-Goal List created during use-case modeling, or a
more terse summary.]
• 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
• …
40
20
3/17/2022

4. Summary of System Features
[As discussed below, system features are a terse format to summarize
functionality].
 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
 …
41
Commentary: Vision
◼ When someone joins the project, it is useful to be able to say,
"Welcome! Please go read the 7-page Vision at the project website”
Summary of System Features
◼ Simply listing the use case names is not sufficient in the Vision to
grasp the major features. Why?
 The use case name can hide interesting major features stakeholders
really want to know about
 Some noteworthy features span or are orthogonal to the use cases
 People want a short summary of the big ideas
◼ Therefore, an alternative, complementary way to express system
functions is with system features, which are high-level, terse
statements summarizing system functions
◼ More formally, in the UP, a system feature is "an externally
observable service provided by the system which directly fulfills a
stakeholder need”
42
21
3/17/2022
Guideline: How to Write the System Feature List?

◼ It is common to organize a two-level hierarchy of system features.
But in the Vision document, more than two levels lead to excessive
detail
◼ The point of system features in the Vision is to summarize the
functionality, not decompose it into a long list of fine-grained
elements. A reasonable example in terms of detail
◼ The major features include:
 POS services:
◼ sales capture
◼ payment authorization
◼ …
 Inventory management:
◼ automatic reordering
◼ …
43
Guideline: Should We Duplicate Other

Requirements in the Vision?
◼ In the Vision, the system features briefly summarize functional
requirements often detailed in the use cases.
◼ Likewise, the Vision can summarize other requirements (for

example, reliability and usability) that are detailed in the
Supplementary Specification
◼ For other requirements, avoid their duplication or near-duplication in

both the Vision and Supplementary Specification (SS).
◼ Rather, record them only in the SS.
◼ In the Vision, direct the reader to the SS for the other requirements
44
22
3/17/2022
Guideline: Should You Write the Vision or

Use Cases First?
◼ Don’t be rigid about the order.
◼ While developers are collaborating to create different requirements

artifacts, a synergy emerges in which working on one artifact
influences and helps clarify another.
◼ Nevertheless, a suggested sequence is:
1. Write a brief first draft of the Vision.
2. Identify user goals and the supporting use cases by name.
3. Write some use cases in detail and start the Supplementary

Specification.
4. Refine the Vision, summarizing information from these.
45
GLOSSARY
46
23
3/17/2022
Glossary Template
47
NextGen Example: A (Partial) Glossary
48
24
3/17/2022
BUSINESS RULES
49
Business Rules Template
50
25
3/17/2022
NextGen Example: Business Rules

(Domain Rules)
51
51
Evolutionary Requirements in Iterative Methods
SUMMARY
52
26
3/17/2022
Table 7.1. Sample UP artifacts and

timing. s - start; r - refine
53
END Lec 3
54
27

SDT-Lec 3 - Other Requirments

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SDT-Lec 3 - Other Requirments

Uploaded by

Copyright:

Available Formats

3/17/2022

Lec 3: Other Requirements

◼ (Partial) Supplementary Specification

◼ Business Rules (Domain Rules)

Dr Farooque Azam, CEME, NUST 4

Dr Farooque Azam, CEME, NUST 5

Dr Farooque Azam, CEME, NUST 6

Should We Analyze Requirements Thoroughly

◼ No. The UP is an iterative and evolutionary method.

Dr Farooque Azam, CEME, NUST 7

Should We Analyze Requirements Thoroughly

3. It is a misunderstanding to believe that early detailed

Dr Farooque Azam, CEME, NUST 8

Need for Vision & SS

Dr Farooque Azam, CEME, NUST 9

Dr Farooque Azam, CEME, NUST 10

SS Template – Main Heading

Dr Farooque Azam, CEME, NUST 11

4. Logging and Error Handling

Dr Farooque Azam, CEME, NUST 13

• Avoid colors associated with common forms of color

Dr Farooque Azam, CEME, NUST 14

Much more analysis is needed here....

Dr Farooque Azam, CEME, NUST 15

Our goal: authorization in less than 1 minute, 90% of the time.

Dr Farooque Azam, CEME, NUST 16

 Different customers of the NextGen POS have unique business

 Therefore, at several defined points in the scenario (for

Dr Farooque Azam, CEME, NUST 17

11. Implementation Constraints

12. Purchased Components

Dr Farooque Azam, CEME, NUST 19

13. Free Open-Source Components

Although it is premature to definitively design and choose

◼ JLog logging framework

Dr Farooque Azam, CEME, NUST 20

• Barcode laser scanner (these normally attach to a special keyboard,

• Credit/debit card reader

• Signature reader (but not in release 1)

Dr Farooque Azam, CEME, NUST 21

For most external collaborating systems (tax calculator, accounting,

Dr Farooque Azam, CEME, NUST 22

15. Application-Specific Domain (Business) Rules

ID Rule Changeability Source

Dr Farooque Azam, CEME, NUST 23

16. Legal Issues

Note: that these can change frequently

17. Information in Domains of Interest

Note that products have an original price, and optionally a

Dr Farooque Azam, CEME, NUST 24

17. Information in Domains of Interest

 When an electronic credit or debit payment is approved by a

 On a nightly basis, the authorization service will perform an

Dr Farooque Azam, CEME, NUST 25

17. Information in Domains of Interest

 Sales tax calculations can be very complex.

 Therefore, delegating tax calculations to third-party calculator

Dr Farooque Azam, CEME, NUST 26

17. Item Identifiers: UPCs, EANs, SKUs, Bar Codes, and

Dr Farooque Azam, CEME, NUST 27

Commentary: Supplementary Specification

◼ The Supplementary Specification captures other requirements,

[#] "URPS+" (usability, reliability, performance, supportability, and more)

Dr Farooque Azam, CEME, NUST 28