Requirements Specifications

Transcription

1 Requirements Specifications The Duomo, Firenze Begun : design competition 1418: another competition 1436: Consecrated 1461: Lantern hoisted, 165 years after start 1

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? 2

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 3

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 4

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 5

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 6

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 7

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 8

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? 9

10 Precision How precise should calculations be? Square Root(5) = ? = 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? 10

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 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 12

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 13

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 14

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 15