1 / 28

Requirements Specification

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

cody
Download Presentation

Requirements Specification

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Requirements Specification

  2. Welcome to Software Engineering: • “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.

  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 things the system has to do for the designers. • Statement of reference for maintenance

  6. Formality • Informal: not formal • 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 languages have formal, mathematically defined semantics

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

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

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

  10. Example of Concise, not ClearHamlet 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 …” • Grouped by functionality or subsystem

  13. Learning to Write Requirements • Learn to critique problems. • Learn to rework those requirements. • Learn to critique and rework your requirement statements. • 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) • SDL • SCR

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

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

  19. SCR: Software Cost Reduction • Heitmeyer, Navy Research Lab • 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 tables are composed in a data-flow format

  20. Execution of SCR models • Execution is modeled as a flow of variable updates • 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 • Used to clarify and model requirements • Some work on automated translation of SCR models to code

  21. Classification of Specification Styles • Formal vs Informal • 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? • For software, does the system implement the requirements? • Verification: did we build the product right? • Does each function work correctly? (For software, does it match the specification?)

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

  26. Verification of Specifications • Recall that correctness does not imply that the program matches the intentions. • 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 • Informal: walkthroughs, inspections • Formal: prototyping • Static Checking • Consistency • Completeness • 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 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.

More Related