1 Representations for requirements Unified Modeling Language UML - PDF document

Today CSE 403, Software Engineering � Representation of requirements Lecture 4 � Use of requirements � Key parts of the discussion will (probably) be about process, not Documenting and Using artifacts Requirements � Non-functional requirements User requirements Who are requirements for? � Customer Business � To know what they are getting Requirements � Management � To know what they are sponsoring User User Use Cases � Marketing Requirements Study � To know what they are selling � Test � To know what they are testing Requirements � Dev Documentation � To know what they are building Managing the requirements process Documenting requirements � Recognizing requirements documents � Multiple representations are probably needed � Process for updating requirements � Contradictory goals � Tracking process for requirements changes � Conciseness vs. completeness � Formality vs. comprehensibility � Arbitration process for resolving ambiguity and inconsistency 1

Representations for requirements Unified Modeling Language � UML (1997) � Requirement lists Window � Object diagrams � Diagrams origin � Behavioral Notations size � A picture is worth a thousand words I Unknown open() � Diagram notations � Entity Data Diagrams close() � Use case diagrams move() � Data Flow Diagrams display() � Interaction diagrams � State Charts IPersistable � Activity diagrams � Activity Diagrams � Statechart diagrams Approaches to UML UI Mockup � "Whiteboard UML" � Advantages � Disadvantages � Use notation for expository tool � Flexible use � Partial tool support � "Formal UML" � Substantial tool support � Restrictive � Assigning semantics very challenging � 37 different semantics for Statecharts Write the user's manual first Redundancy: Good or bad? � Advantages � Disadvantages � Multiple forms of documentation � Used for different audiences or views � But risk of inconsistency � Functional spec and user spec � Should describe the same thing! � But what if they differ � Isn't that Test's job? � Development principle � Avoid computing the same thing in multiple places 2

Brooks on flow charts Flow charts � The flow chart is the most thoroughly � "The emperor has no clothes" oversold piece of program documentation � Formal processes � I have never seen an experienced � Many processes are onerous and programmer who routinely made detailed unpleasant to follow – but enhance overall flow charts before beginning to write product quality programs. Where organization standards � Some are without value, and should be require flow charts, these are invariably done dropped after the fact. � Process is not the end in itself User requirements Non-functional requirements � Requirements beyond user interaction Business Requirements with the system � Kulak and Guiney User User Use Cases Requirements � Availability, cost of ownership, Study maintainability, data integrity, extensibility, Functional functionality (?), installability, reuse, Requirements Requirements operability, performance, portability, Documentation quality, robustness, scalability Non-functional Requirements Non-functionality requirements Safety requirements � Wiegers � Safety critical applications � Performance requirements � Where bugs can kill � Safety requirements � Famous cases � Security requirements � Therac-25 radiation therapy machine � Software quality attributes � US Air traffic control which failed in UK � Reflected map on Greenwich Median � US Aviation software failed in Israel � Encountered negative altitudes over Dead Sea 3

Safety critical systems Security requirements � Very high cost of failure � Applications are run in a hostile world � Application compromise vs. system � Software component of a large system compromise � e.g. nuclear reactor � Example requirements � Characteristics of software lead to � Only authenticated users can change data failures � Application can change security permissions or execute programs � Safety requirements � Malicious user cannot crash system with bad data � Low probability of failure (risk analysis) � Threat analysis � Understood failure modes Security requirements for multiplayer games � Cheating ruins game play (and consequently market) � Threats � Players introducing counterfeit weapons � Sending packet of death across network � Using profiling tools to detect areas of activity in dungeons 4