1. Requirements Specification

2. Welcome to Software Engineering: “Requirements Specification” “Requirements Specification”  Verb?  Noun?  “Specification” not the same as “Requirements Specification”?  “Requirements” not the same as “Specification”?

3. Requirements vs Specifications A specification is a precise statement of the requirements that the system must satisfy. A specification is a precise statement of the requirements that the system must satisfy.

4. Requirements Specification Sommerville: is the activity of translating the information gathered during the analysis activity into a document that defines a set of requirements. IEEE: Requirements specification is documentation of the essential requirements (functions, performance, design constraints, and attributes) of the software and its external interfaces. (STD 1012)

5. Uses of requirements Statement of the needs of the users Statement of the needs of the users Statement of the things the system has to do for the designers. Statement of the things the system has to do for the designers. Statement of reference for maintenance Statement of reference for maintenance

6. Formality Informal: not formal Informal: not formal Formal (Davis): Written down in an SRS in a natural language (e. g. English). Formal (Davis): Written down in an SRS in a natural language (e. g. English). Formal (Ghezzi): Written down in a formal specification language (e. g. Z, Larch, First- Order Language, VDM, …) Formal (Ghezzi): Written down in a formal specification language (e. g. Z, Larch, First- Order Language, VDM, …)  Formal languages have formal, mathematically defined semantics

7. Functional vs Non-functional functional requirements, (what does it do) functional requirements, (what does it do) non-functional requirements non-functional requirements  reliability, availability, security, accuracy  interface issues, operating constraints,  requirements on development process  quality control  system test procedures  priorities

8. Properties of Good Requirements Hamlet Understandable Understandable Nonprescriptive Nonprescriptive Correct Correct Complete Set Complete Set Individually Complete Individually Complete Concise Precise Clear Unambiguous Consistent Traceable Modifiable Testable Feasible

9. Boeing Computer Services Complete Complete Correct Correct Unambiguous, Precise, Clear Unambiguous, Precise, Clear Consistent Consistent Relevant Relevant Testable Traceable Feasible Free of Unwarranted Design Detail Manageable

10. Example of Concise, not Clear Hamlet The items in tab-separated columns and underscore-separated rows of the output may refer to each other; but no item in (row,column) position (i,j) may refer to another in position (p,q) unless p<i, or if i=p,q<j.

11. Less concise, but clear Hamlet The output shall consist of rows and columns. Items across each row shall be separated by tabs. There shall be an underscore between rows. When item X refers to item Y, Y must either be in a row above X, or if they are in the same row, Y must be in a column to the left of X. An item may not refer to itself.

12. Requirements Statement “The system shall …” “The system shall …” Grouped by functionality or subsystem Grouped by functionality or subsystem

13. Learning to Write Requirements Learn to critique problems. Learn to critique problems. Learn to rework those requirements. Learn to rework those requirements. Learn to critique and rework your requirement statements. Learn to critique and rework your requirement statements. It is difficult to get these right. It is difficult to get these right.

14. MS Word example: Selecting is the process for designating areas of your document that you want to work on. Most editing and formatting actions require two steps: first you select what you want to work on, such as text or graphics; then you initiate the appropriate action.

15. Another example: The message must be triplicated. The three copies must be forwarded through three different physical channels. The receiver accepts the message on the basis of two-out- of-three voting policy.

16. Specification Languages UML (you’ve seen some of this already) UML (you’ve seen some of this already) SDL SDL SCR SCR

17. SDL: Specification and Description Language Language standard from the International Telecommunications Union Language standard from the International Telecommunications Union Specifies real-time, concurrent, distributed processes Specifies real-time, concurrent, distributed processes Inter-process communication is through unbounded message queues Inter-process communication is through unbounded message queues 3 Diagrams and algebraic specifications 3 Diagrams and algebraic specifications  Algebraic specs here are ADTs

18. SDL Diagrams System Diagram System Diagram Block Diagram Block Diagram Process Diagram Process Diagram

19. SCR: Software Cost Reduction Heitmeyer, Navy Research Lab Heitmeyer, Navy Research Lab Models a system as a function mapping monitored environmental (input) variables to (system) controlled (output) variables Models a system as a function mapping monitored environmental (input) variables to (system) controlled (output) variables The function is decomposed into smaller functions, each of which has a table of input/output values The function is decomposed into smaller functions, each of which has a table of input/output values The tables are composed in a data-flow format The tables are composed in a data-flow format

20. Execution of SCR models Execution is modeled as a flow of variable updates Execution is modeled as a flow of variable updates Outputs of one table may be the inputs to other tables Outputs of one table may be the inputs to other tables When an input value to one table changes, the outputs are propagated to all the other tables When an input value to one table changes, the outputs are propagated to all the other tables Used to clarify and model requirements Used to clarify and model requirements Some work on automated translation of SCR models to code Some work on automated translation of SCR models to code

21. Classification of Specification Styles Formal vs Informal Formal vs Informal Operational vs Behavioral Operational vs Behavioral  Sometimes it it claimed that behavioral is more abstract than operational.

22. Example: operational: Let a be an array of n elements. The result of sorting a is an array b of n elements such that the first element of b is the smallest element of a, the second element of b is the smallest element of the array of n-1 elements obtained by removing the smallest element of a, and so on until all n elements have been removed.

23. Example behavioral (descriptive): The result of sorting a is an array b which is a permutation of a and is sorted.

24. V&V Validation: did we build the right product? Validation: did we build the right product?  For software, does the system implement the requirements? Verification: did we build the product right? Verification: did we build the product right?  Does each function work correctly? (For software, does it match the specification?)

25. Techniques for Validation Walkthroughs Walkthroughs Reviews Reviews Models Models  Use cases/Scenarios  Prototypes  Simulations Tracing Tracing

26. Verification of Specifications Recall that correctness does not imply that the program matches the intentions. Recall that correctness does not imply that the program matches the intentions. Basically there are two ways to verify things: Basically there are two ways to verify things:  observe its behavior and determine if it matches expectations  analyze the properties of the thing that can be deduced from the artifact created

27. Techniques for Verification Simulation Simulation  Informal: walkthroughs, inspections  Formal: prototyping Static Checking Static Checking  Consistency  Completeness Formal techniques Formal techniques  Model checking  Theorem proving

28. Verification of Specifications If it’s formal, you might be able to create some sort of interpreter for it. (or a simulation of it). If it’s formal, you might be able to create some sort of interpreter for it. (or a simulation of it). If it’s not formal, then a prototype might be in order. Here, prototyping as a way of verifying the specs. If it’s not formal, then a prototype might be in order. Here, prototyping as a way of verifying the specs. Compare to a bridge: A behavioral description could be the equations governing the support structure. The operational might be a model of the bridge, a mockup. Compare to a bridge: A behavioral description could be the equations governing the support structure. The operational might be a model of the bridge, a mockup.