1/27/11

1

Requirements Specifications

The Duomo, Firenze   Begun 1296   1367: design

competition   1418: another

competition   1436: Consecrated   1461: Lantern hoisted,

165 years after start

1/27/11

2

Requirements Specification   Negotiated contract with customer ◦  WHAT will be built ◦  What it will behave like ◦  What its quality will be verified against ◦  Not HOW it should be built

  Communication vehicle ◦  Between developers and customer ◦  Between developers and developers ◦  Between developers and others (testers, marketers,

etc …)

Req. Specification Issues   What are the qualities that requirement

specifications should have? ◦  Different from qualities of the product that it

specifies

  What product qualities must it specify?

1/27/11

3

Specification Qualities   Complete   Consistent   Unambiguous   Precise   Feasible   Even   Understandable   Testable   Free from Implementation Bias

Incompleteness   Missing requirements, details   Example: ◦  Forget to add: “All transactions by non-home

customers should result in a charge of $1.”   Causes: ◦  Customer unavailable ◦  Customer asks for too little ◦  Customer doesn’t think of everything ◦  The world changes

1/27/11

4

Inconsistency   Examples: ◦  “Response time for withdrawal should be <=

50ms.” AND “Checking the PIN should take <= 75ms” ◦  “Must check balance before checking PIN” AND

“Must check PIN before checking balance.”   Causes: ◦  Customer is a group that disagrees   Different people negotiate different parts ◦  Application is large or complex

Ambiguity   More than one possible inference   Example: ◦  “Maximum withdrawal is $200” AND

“All transactions incur a $1 charge”   Causes: ◦  Customer is group where no one person sees whole

picture ◦  Application is large or complex ◦  So many parts, related in so many ways ◦  Imprecise language

1/27/11

5

Infeasibility   Examples: ◦  Anti-gravity boots ◦  Must retrieve 1GB data record in 1 ns

  Causes: ◦  Customer asks for too much ◦  Developers don’t know what’s possible

Unevenness   Different parts defined at different levels of

detail   Causes: ◦  Different sources of info ◦  Different people write different parts ◦  Some parts more difficult than others

1/27/11

6

Non understandable   Often needs to be understood by different

stakeholders ◦  Customer may not be computer savy ◦  Developers may not be experts in the domain ◦  Requirements spec should bridge this divide

Untestable requirements   Examples: ◦  System should play a good game of chess. ◦  System should respond immediately.

  Specification should serve as basis for test plan

1/27/11

7

Implementation Bias

  Requirements should only say WHAT system should do

  Shouldn’t overly bias HOW it should do it   Don’t want to rule out future desired

implementations   Don’t give too much information.

Implementation Bias Examples   Bias order of operation: ◦  System should print receipt, then give cash

  Bias internal data structure: ◦  System should store transaction in database record

  Bias algorithm

1/27/11

8

Biases to avoid   Do not specify specific hardware unless it is really

required ◦  Sometimes it is, but rarely

  Do not specify specific operating systems unless they are really required ◦  They are almost never really required

  Do not specify coding languages ◦  This is not required by the customer ◦  Subsequent design will narrow and/or dictate the choice

of language   Wait until then   The problem dictates the language   Don’t let the reverse happen to you

Product Aspects   Functionality   But also non-functional requirements: ◦  Performance ◦  Precision ◦  Robustness ◦  Safety ◦  Environment

1/27/11

9

Functionality   Clearly say what system should do   Include all different uses of system

Performance   How fast should system perform tasks?   What is the measure? ◦  Throughput ◦  Response time ◦  etc…

  How will testing team know if delivered system is fast enough?

1/27/11

10

Precision   How precise should calculations be?   Square Root(5)

= 2.2360679775 ? = 2.24 ? = 3 ?

Robustness   How should system respond to unexpected

situations/inputs?   Examples: ◦  How should system respond if you deposited

foreign currency? ◦  How should system respond if you ask to withdraw

more than your balance?

1/27/11

11

Safety   What things shouldn’t the system do?   Examples: ◦  Radiation should never exceed 1000 RAD. ◦  System should never destroy card without manager

approval

Environment   What software/hardware must the system

work with?   Examples: ◦  ATM must work with existing bank accounting

system ◦  Power Plant controller must make audit reports in

standard NRC format

1/27/11

12

Getting Started--Understand the Customer   interview the customer   learn the customers terminology   understand the current process ◦  flow of information ◦  form of information

Getting Started--Understand the Problem   decompose the problem into manageable

tasks ◦  each step should be relatively

straightforward to comprehend ◦  focuses issues on what is relevant and

important for that task ◦  identify inter-task dependences

1/27/11

13

Getting started--Evaluate the requirements/risks   Have the customer review, correct, and refine

the description of the problem ◦  Must describe the problem in the customer's

terminology   Evaluate the risks ◦  Feasibility/difficulty ◦  Potential for change ◦  Areas of potential misunderstanding

Propose a Conceptual "solution"   may model the current approach or propose

a vastly different approach ◦  computerization provides opportunities

to optimize and improve the process   present alternative approaches ◦  customer may not be computer-savy ◦  these are not alternative implementations, but

alternative conceptual approaches   may imply different implementations, but may not

  use UI prototype to help clarify issues

1/27/11

14

Trade-offs   model physical world ◦  natural decomposition of the problem ◦  objects are resources

  modify/ improve current practices ◦  current practices based on historical accidents   out of date practices   fits current/past personalities   not optimized for automation

  innovations are not always accepted ◦  cars still have accelerator and brake pedals

  need to predict when you can change corporate culture and when you can not ◦  incremental change is sometimes more acceptable

First Law of Software Engineering   "No matter where you are in the system lifecycle, the

system will change, and the desire to change it will persist throughout the lifecycle."

  Why? ◦  Poor communication ◦  Inaccurate requirements analysis ◦  Failure to consider alternatives ◦  New users, customers, or environment ◦  Software is seen as malleable

  Changes made after the requirements are approved increase cost and schedule

1/27/11

15

Plan for change/extensions   Evaluate what are the kind of changes that probably

will occur ◦  If the customers want one particular form   Will they want an alternative form in the future   Will they want multiple forms   Will they want to modify the forms   Will they want to modify the forms dynamically

  Evaluate the cost of planning for these changes in the system development ◦  Some extensions would result in exorbitant costs, but

some do not