Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
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