csce 431: requirements some material from b. meyer, m. oriol, b. schoeller, eth zurich

CSCE 431: Requirements Some material from B. Meyer, M. Oriol, B. Schoeller, ETH Zurich

Outline Motivation Ethics Overview of Requirements Task Recognizing Good Requirements Standards and Methods Requirements Elicitation About UML CSCE 431 Requirements

Requirements Are Important The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later. Fred Brooks, No Silver Bullet Essence and Accident in Software Engineering, IEEE Computer, vol. 20, no. 4, April 1987, pp. 10-19. CSCE 431 Requirements

Software Risk Barry Boehm, Software Engineering Economics, Prentice Hall, 1981 CSCE 431 Requirements

Some Statistics on Requirements 80% of interface faults and 20% of implementation faults due to requirements (Perry & Stieg, 1993) 48% to 67% of safety-related faults in NASA SW systems due to misunderstood HW interface specifications, of which 2/3 are due to requirements (Lutz, 1993) 85% of defects due to requirements, of which 49% are incorrect assumptions 29% omitted requirements 13% inconsistent requirements (Young, 2001). Requirements cause a lot of problems! CSCE 431 Requirements

Ethical View When customers present ideas that need system solutions, developers have an ethical and professional obligation to help customers define their problem. You must build the best solution to the customers problem, even if the customer does not yet understand how to ask for it. Bernstein & Yuhas More on professional ethics in future lecture CSCE 431 Requirements

Definitions A requirement is a statement of desired behavior for a system The requirements for a system are the collection of all such individual requirements Requirements process has two activities: Requirements elicitation definition of the system in terms understood by the customer and/or user Agile process user stories, customer on site Requirements analysis definition of the system in terms understood by the developer CSCE 431 Requirements

Goals of Requirements Phase Understand the problem or problems that the eventual software system, if any, should solve Prompt relevant questions about the problem and system Provide basis for answering questions about specific properties of the problem and system Decide what the system should do Decide what the system should not do Ascertain that the system will satisfy needs of its stakeholders Provide basis for development of the system Provide basis for validation and verification (especially testing) of the system B. Meyer, Object-Oriented Software Construction CSCE 431 Requirements

Products of Requirements Requirements document Development plan Validation and verification plan (test plan) CSCE 431 Requirements

How Much Effort? Should expect to allocate 15-30% of total project effort on requirements Seems like a lot, but this phase is the source of many project failures Remember that only 40-60% of requirements are known during requirements elicitation Rest are emergent requirements CSCE 431 Requirements

Stakeholders One of the first phases is to identify stakeholders Suggestions of groups to think about: Clients Customers Clients and customers customers Users Domain experts Legal experts Purchasing agents Software developers Software project managers Software documenters Trainers Consultants CSCE 431 Requirements

Components of Requirements Domain properties Assumptions that are true in the domain Functional requirements Non-functional requirements Reliability Security Accuracy of results Time and space performance Portability Others? CSCE 431 Requirements

Roles of Domain Properties vs. Requirements Requirement R: The database shall only be accessible to authorized personnel Domain Properties D: Authorized personnel have passwords Passwords are never shared with non-authorized personnel Specification S: Access to the database shall only be granted after the user enters an authorized password S, D R But what if domain assumptions are wrong? Steve Easterbrook, 2008 CSCE 431 Requirements

Domain Assumption? CSCE 431 Requirements

Quality Goals for Requirements Correct Complete Consistent Unambiguous Traceable Modifiable Verifiable Prioritized CSCE 431 Requirements 830-1998 IEEE Recommended Practice for Software Requirements Specifications

Difficulties Natural language and its imprecision Formal techniques and their abstraction Users and their vagueness Customers and their demands (or managers/marketing/sales) The rest of the world and its complexity And things change during the project CSCE 431 Requirements

Bad Requirements, Example CSCE 431 Requirements NOT SO GOOD The Background Task Manager shall provide status messages at regular intervals of not less than 60 seconds. BETTER The Background Task Manager (BTM) shall display status messages in a designated area of the user interface. 1.The messages shall be updated every 60 10 seconds after background task processing begins. 2.The messages shall remain visible continuously. 3.Whenever communication with the background task process is possible, the BTM shall display the percent completed of the background task.

Bad Requirements, Another CSCE 431 Requirements NOT SO GOOD The XML Editor shall switch between displaying and hiding non-printing characters instantaneously. BETTER The user shall be able to toggle between displaying and hiding all XML tags in the document being edited with the activation of a specific triggering mechanism. The display shall change in 0.1 seconds.

Bad Requirements, Another CSCE 431 Requirements NOT SO GOOD The XML parser shall produce a markup error report that allows quick resolution of errors when used by XML novices. BETTER 1.After the XML Parser has completed parsed a file, it shall produce an error report that contains the line number and text of any XML errors found in the parsed file and a description of each error found. 2.If no parsing errors are found, the parser shall not produce an error report.

Bad Requirements, One More CSCE 431 Requirements NOT SO GOOD The editor shall not offer search and replace options that could have disastrous results. BETTER 1.The editor shall require the user to confirm global text changes, deletions, and insertions that could result in data loss. 2.The application shall provide a multi-level undo capability limited only by the system resources available to the application.

A Balancing Act One should not over-specify == committing too early to a specific implementation One should not under-specify == leaving some parts of the problem missing CSCE 431 Requirements

A Simple Problem Peter Naur, Programming by Action Clusters, BIT, vol. 9, no. 3, pp. 250-258 CSCE 431 Requirements NAURS PROBLEM STATEMENT Given a text consisting of words separated by BLANK or by NL (new line) characters, convert it to a line-by-line form in accordance with the following rules: 1.Line breaks must be made only where the given text has BLANK or NL; 2.Each line is filled as far as possible as long as 3.No line will contain more than MAXPOS characters.

Improved Specification CSCE 431 Requirements J. B. Goodenough and S. Gerhart, Towards a Theory of Test: Data Selection Criteria, Current Trends in Programming Methodology, pp 44 79, Prentice Hall, 1977 The programs input is a stream of characters whose end is signaled with a special end-of- text character, ET. There is exactly one ET character in each input stream. Characters are classified as: break charactersBL (blank) and NL (new line); nonbreak charactersall others except ET; the end-of-text indicatorET. A word is a nonempty sequence of nonbreak characters. A break is a sequence of one or more break characters. Thus, the input can be viewed as a sequence of words separated by breaks, with possibly leading and trailing breaks, and ending with ET. The programs output should be the same sequence of words as in the input, with the exception that an oversize word (i.e., a word containing more than MAXPOS characters, where MAXPOS is a positive integer) should cause an error exit from the program (i.e., a variable, Alarm, should have the value TRUE). Up to the point of an error, the programs output should have the following properties: 1.A new line should start only between words and at the beginning of the output text, if any. 2.A break in the input is reduced to a single break character in the output. 3.As many words as possible should be placed on each line (i.e., between successive NL characters). 4.No line may contain more than MAXPOS characters (words and BLs).

Meyers Analysis The following discussion is based on Bertrand Meyers analysis of the above specifications in On Formalism in Specifications, IEEE Software, pp. 6-26, Jan. 1985 His definition of specification: Precise definition of the tasks to be performed by the system Do not confuse with requirements, which are a natural-language definition of the system objectives CSCE 431 Requirements

Seven Sins of the Specifier 1.Noise Irrelevant information, redundancy, remorse (restriction at use, not definition, of an element) 2.Silence Feature exists, but not discussed 3.Over-specification Specification of a solution to the problem, not the problem 4.Contradiction 5.Ambiguity 6.Forward reference 7.Wishful thinking Feature definition, for which candidate solutions cannot be realistically validated CSCE 431 Requirements

Noise CSCE 431 Requirements The programs input is a stream of characters whose end is signaled with a special end-of- text character, ET. There is exactly one ET character in each input stream. Characters are classified as: break charactersBL (blank) and NL (new line); nonbreak charactersall others except ET; the end-of-text indicatorET. A word is a nonempty sequence of nonbreak characters. A break is a sequence of one or more break characters. Thus, the input can be viewed as a sequence of words separated by breaks, with possibly leading and trailing breaks, and ending with ET. The programs output should be the same sequence of words as in the input, with the exception that an oversize word (i.e., a word containing more than MAXPOS characters, where MAXPOS is a positive integer) should cause an error exit from the program (i.e., a variable, Alarm, should have the value TRUE). Up to the point of an error, the programs output should have the following properties: 1.A new line should start only between words and at the beginning of the output text, if any. 2.A break in the input is reduced to a single break character in the output. 3.As many words as possible should be placed on each line (i.e., between successive NL characters). 4.No line may contain more than MAXPOS characters (words and BLs).

Remorse CSCE 431 Requirements The programs input is a stream of characters whose end is signaled with a special end-of- text character, ET. There is exactly one ET character in each input stream. Characters are classified as: break charactersBL (blank) and NL (new line); nonbreak charactersall others except ET; the end-of-text indicatorET. A word is a nonempty sequence of nonbreak characters. A break is a sequence of one or more break characters. Thus, the input can be viewed as a sequence of words separated by breaks, with possibly leading and trailing breaks, and ending with ET. The programs output should be the same sequence of words as in the input, with the exception that an oversize word (i.e., a word containing more than MAXPOS characters, where MAXPOS is a positive integer) should cause an error exit from the program (i.e., a variable, Alarm, should have the value TRUE). Up to the point of an error, the programs output should have the following properties: 1.A new line should start only between words and at the beginning of the output text, if any. 2.A break in the input is reduced to a single break character in the output. 3.As many words as possible should be placed on each line (i.e., between successive NL characters). 4.No line may contain more than MAXPOS characters (words and BLs).

Silence The obvious easily forgotten In the example: line never defined, except in the remorseful sequence of characters between successive NL characters. Are the NL characters part of the line? Are the first and the last lines lines? Behavior of NL relies on contextual knowledge of a particular encoding (or an OS) Alarm should be set to TRUE in one case, but nothing else is said about it CSCE 431 Requirements

Contradictions CSCE 431 Requirements The programs input is a stream of characters whose end is signaled with a special end-of-text character, ET. There is exactly one ET character in each input stream. Characters are classified as: break charactersBL (blank) and NL (new line); nonbreak charactersall others except ET; the end-of-text indicatorET. A word is a nonempty sequence of nonbreak characters. A break is a sequence of one or more break characters. Thus, the input can be viewed as a sequence of words separated by breaks, with possibly leading and trailing breaks, and ending with ET. The programs output should be the same sequence of words as in the input, with the exception that an oversize word (i.e., a word containing more than MAXPOS characters, where MAXPOS is a positive integer) should cause an error exit from the program (i.e., a variable, Alarm, should have the value TRUE). Up to the point of an error, the programs output should have the following properties: 1.A new line should start only between words and at the beginning of the output text, if any. 2.A break in the input is reduced to a single break character in the output. 3.As many words as possible should be placed on each line (i.e., between successive NL characters). 4.No line may contain more than MAXPOS characters (words and BLs).

Over-specification CSCE 431 Requirements The programs input is a stream of characters whose end is signaled with a special end- of-text character, ET. There is exactly one ET character in each input stream. Characters are classified as: break charactersBL (blank) and NL (new line); nonbreak charactersall others except ET; the end-of-text indicatorET. A word is a nonempty sequence of nonbreak characters. A break is a sequence of one or more break characters. Thus, the input can be viewed as a sequence of words separated by breaks, with possibly leading and trailing breaks, and ending with ET. The programs output should be the same sequence of words as in the input, with the exception that an oversize word (i.e., a word containing more than MAXPOS characters, where MAXPOS is a positive integer) should cause an error exit from the program (i.e., a variable, Alarm, should have the value TRUE). Up to the point of an error, the programs output should have the following properties: 1.A new line should start only between words and at the beginning of the output text, if any. 2.A break in the input is reduced to a single break character in the output. 3.As many words as possible should be placed on each line (i.e., between successive NL characters). 4.No line may contain more than MAXPOS characters (words and BLs).

Ambiguity CSCE 431 Requirements The programs input is a stream of characters whose end is signaled with a special end-of- text character, ET. There is exactly one ET character in each input stream. Characters are classified as: break charactersBL (blank) and NL (new line); nonbreak charactersall others except ET; the end-of-text indicatorET. A word is a nonempty sequence of nonbreak characters. A break is a sequence of one or more break characters. Thus, the input can be viewed as a sequence of words separated by breaks, with possibly leading and trailing breaks, and ending with ET. The programs output should be the same sequence of words as in the input, with the exception that an oversize word (i.e., a word containing more than MAXPOS characters, where MAXPOS is a positive integer) should cause an error exit from the program (i.e., a variable, Alarm, should have the value TRUE). Up to the point of an error, the programs output should have the following properties: 1.A new line should start only between words and at the beginning of the output text, if any. 2.A break in the input is reduced to a single break character in the output. 3.As many words as possible should be placed on each line (i.e., between successive NL characters). 4.No line may contain more than MAXPOS characters (words and BLs).

Forward References (implicit) CSCE 431 Requirements The programs input is a stream of characters whose end is signaled with a special end-of- text character, ET. There is exactly one ET character in each input stream. Characters are classified as: break charactersBL (blank) and NL (new line); nonbreak charactersall others except ET; the end-of-text indicatorET. A word is a nonempty sequence of nonbreak characters. A break is a sequence of one or more break characters. Thus, the input can be viewed as a sequence of words separated by breaks, with possibly leading and trailing breaks, and ending with ET. The programs output should be the same sequence of words as in the input, with the exception that an oversize word (i.e., a word containing more than MAXPOS characters, where MAXPOS is a positive integer) should cause an error exit from the program (i.e., a variable, Alarm, should have the value TRUE). Up to the point of an error, the programs output should have the following properties: 1.A new line should start only between words and at the beginning of the output text, if any. 2.A break in the input is reduced to a single break character in the output. 3.As many words as possible should be placed on each line (i.e., between successive NL characters). 4.No line may contain more than MAXPOS characters (words and BLs).

Improved (w/o Quotes) Given are a non-negative integer MAXPOS and a character set including two break characters blank and new_line. The program shall accept as input a finite sequence of characters and produce as output a sequence of characters satisfying the following conditions: It only differs from the input by having a single break character wherever the input has one or more break characters. Any MAXPOS+1 consecutive characters include a new_line. The number of new_line characters is minimal. If (and only if) an input sequence contains a group of MAXPOS+1 consecutive non-break characters, there exists no such output. In this case, the program shall produce the output associated with the initial part of the sequence up to and including the MAXPOS -th character of the first such group, and report the error. CSCE 431 Requirements Spec from Meyer

Verifiable Requirements Non-verifiable: The system shall work satisfactorily The interface shall be user-friendly The system shall respond in real time Verifiable: The output shall in all cases be produced 30s after the corresponding input event. It shall be produced in 10s for 80% of input events. Professional train drivers will reach level 1 of proficiency (defined in requirements) in two days of training. Favor precise, falsifiable language over pleasant generalities! CSCE 431 Requirements

Complete Requirements Complete w.r.t. what? Definition from IEEE standard: An SRS (Software Requirements Specification) is complete if, and only if, it includes the following elements: All significant requirements, whether relating to functionality, performance, design constraints, attributes, or external interfaces. In particular any external requirements imposed by a system specification should be acknowledged and treated. Definition of the responses of the software to all realizable classes of input data in all realizable classes of situations. Note that it is important to specify the responses to both valid and invalid input values. Full labels and references to all figures, tables, and diagrams in the SRS and definition of all terms and units of measure. CSCE 431 Requirements

Complete Requirements Completeness cannot be completely defined Cross-checking mutators vs. accessors (so that all effects defined) at least useful sufficient complexity E.g. consider each accessor for each possible use of mutators Think negatively how can I break it CSCE 431 Requirements

Why SE Standards? SE standards: Define common practice Guide new engineers Make software engineering processes comparable Enable certification CSCE 431 Requirements

IEEE 830-1998 IEEE Recommended Practice for Software Requirements Specifications Approved 25 June 1998 (revision of earlier standard) Descriptions of the content and the qualities of a good software requirements specification (SRS). Goal: The SRS should be correct, unambiguous, complete, consistent, ranked for importance and/or stability, verifiable, modifiable, traceable. CSCE 431 Requirements

IEEE Standard: Definitions ContractA legally binding document agreed upon by the customer and supplier. This includes the technical and organizational requirements, cost, and schedule for a product. A contract may also contain informal but useful information such as the commitments or expectations of the parties involved. CustomerThe person, or persons, who pay for the product and usually (but not necessarily) decide the requirements. In the context of this recommended practice the customer and the supplier may be members of the same organization. SupplierThe person, or persons, who produce a product for a customer. In the context of this recommended practice, the customer and the supplier may be members of the same organization. UserThe person, or persons, who operate or interact directly with the product. The user(s) and the customer(s) are often not the same person(s). CSCE 431 Requirements

Issues Addressed Basic issues to be addressed by an SRS: Functionality What is the software supposed to do? External interfaces How does the software interact with people, the systems hardware, other hardware, and other software? Performance What is the speed, availability, response time, recovery time of various software functions,? Attributes What are the portability, correctness, maintainability, security,... considerations? Design constraints imposed on an implementation Are there any required standards in effect, implementation language, policies for database integrity, resource limits, operating environment(s),? The SRS writer(s) should avoid placing either design or project requirements in the SRS CSCE 431 Requirements

IEEE Standard: SRSs Recommended Structure 1. Introduction 1.1. Purpose 1.2. Scope 1.3. Definitions, acronyms, and abbreviations Glossary 1.4. References 1.5. Overview 2. Overall description 2.1. Product perspective 2.2. Product functions 2.3. User characteristics 2.4. Constraints 2.5. Assumptions and dependencies 3. Specific requirements Appendices Index It makes sense to use the recommended structure CSCE 431 Requirements

Example Section: Scope Identify software product to be produced by name (e.g., Host DBMS, Report Generator, etc.) Explain what the product will and will not do Describe application of the software: goals and benefits Establish relation with higher-level system requirements if any CSCE 431 Requirements

Example Section: Product Perspective Describe relation with other products if any Examples: System interfaces User interfaces Hardware interfaces Software interfaces Communications interfaces Memory Operations Site adaptation requirements CSCE 431 Requirements

Example Section: Constraints Describe any properties that will limit the developers options Examples: Regulatory policies Hardware limitations (e.g., signal timing requirements) Interfaces to other applications Parallel operation Audit functions Control functions Higher-order language requirements Reliability requirements Criticality of the application Safety and security considerations CSCE 431 Requirements

Specific Requirements (Section 3) This section brings requirements to a level of detail usable by designers and testers Examples: Details on external interfaces Precise specification of each function Responses to abnormal situations Detailed performance requirements Database requirements Design constraints Specific attributes such as reliability, availability, security, portability CSCE 431 Requirements

Possible Section 3 Structure 3. Specific requirements 3.1 External interfaces 3.1.1 User interfaces 3.1.2 Hardware interfaces 3.1.3 Software interfaces 3.1.4 Communication interfaces 3.2 Functional requirements 3.3 Performance requirements 3.4 Design constraints 3.5 Quality requirements 3.6 Other requirements CSCE 431 Requirements

Requirements and Agile Methods Under XP (Extreme Programming) Requirements are taken into account as defined at the particular time considered Requirements are largely embedded in test cases Benefits Test plan will be directly available Customer involvement Risks Change may be difficult (refactoring) Structure may not be right Tests only cover the foreseen cases Possibly useful advise Retain the best agile practices, in particular frequent iterations, customer involvement, centrality of code and testing Disregard those that contradict proven SE principles CSCE 431 Requirements

Recipes for Good Requirements Managerial aspects: Involve all stakeholders Establish procedures for controlled change Establish mechanisms for traceability Treat requirements document as one of the major assets of the project; focus on clarity, precision, completeness Technical aspects: How to be precise? Formal methods? CSCE 431 Requirements

Using Natural Language for Requirements Keys are: Structure Precision (including precise definition of all terms) Consistency Minimizing forward and outward references Clarity Conciseness CSCE 431 Requirements

Advice on Natural Language Apply the general rules of good writing (e.g. Strunk & White) Use active form (Counter-example: the message will be transmitted... ). This forces you to state who does what Use prescriptive language (shall ) Separate domain properties and requirements For delicate or complex issues, use complementary formalisms: Illustrations (with precise semantics) Formal descriptions, with explanations in English Even for natural language specs, a mathematical detour may be useful CSCE 431 Requirements

Advice on Natural Language When using numbers, identify the units When introducing a list, describe all the elements Use illustrations to clarify Define all project terms in a glossary Consider placing individual requirements in a separate paragraph, individually numbered Define generic verbs (transmitted, sent, downloaded, processed... ) precisely CSCE 431 Requirements M. Mannion and B. Keepence, SMART Requirements, ACM SIGSOFT SENotes, vol. 20, no. 2, pp. 42-47, April 1995.

Techniques for Requirements Elicitation Questionnaires: Asking the end user a list of pre-selected questions Task Analysis: Observing end users in their operational environment Scenarios: Describe the use of the system as a series of interactions between a specific end user and the system Use Cases: Abstractions that describe a class of scenarios CSCE 431 Requirements

Scenario A description of an event or series of actions and events In SE: a description of a use/uses of a system The description is written from an end users point of view A scenario can include text, video, pictures and story boards. It usually also contains details about the work place, social situations and resource constraints A narrative description of what people do and experience as they try to make use of computer systems and applications [M. Carroll, Scenario-Based Design, Wiley, 1995] A concrete, focused, informal description of a single feature of the system used by a single actor Goal is to increase understanding of the system CSCE 431 Requirements Bruegge, Dutoit: Object-Oriented Software Engineering: Using UML, Java, and Patterns

Rationale for Scenarios For many, it is easier to relate to real-life examples than to abstract descriptions of possible behaviors People can understand and critique a scenario of a planned interaction with a system CSCE 431 Requirements

Finding Scenarios Do not expect the client to be verbose if the system does not exist Client understands the application domain (problem domain), not the solution domain Do not wait for information even if the system exists What is obvious does not need to be said Dialog Developer helps the client to formulate the requirements Client helps the developer to understand the requirements The requirements evolve while the scenarios are being developed CSCE 431 Requirements Bruegge, Dutoit: Object-Oriented Software Engineering: Using UML, Java, and Patterns

Scenario Example Bob, driving down Main Street in his patrol car, notices smoke coming out of a warehouse. His partner, Alice, reports the emergency from their car. Alice enters the address of the building into her wearable computer, a brief description of its location (i.e., NW corner), and an emergency level. She confirms her input and waits for an acknowledgment. John, the dispatcher, is alerted to the emergency by a beep of his workstation. He reviews the information submitted by Alice and acknowledges the report. He allocates a fire unit and sends the estimated arrival time (ETA) to Alice. Alice receives the acknowledgment and the ETA. Observations Concrete Describes a single instance, not all possible situations Mentions participants CSCE 431 Requirements

Heuristics Useful questions: What are the primary tasks that the system needs to perform? What data will an actor create, store, change, remove or add in the system? What external changes does the system need to know about? What changes or events will an actor of the system need to be informed about? Instead of only relying on questions and questionnaires, perform task observation if the system already exists (interface engineering or reengineering) Speak with end users, not just to the client Expect resistance CSCE 431 Requirements Bruegge, Dutoit: Object-Oriented Software Engineering: Using UML, Java, and Patterns

Use Cases A use case defines a goal-oriented set of interactions between external actors and the system under consideration. Actors are parties outside the system that interact with the system An actor may be a class of users, roles users can play, or other systems. A use case is initiated by a user with a particular goal in mind, and completes successfully when that goal is satisfied. Includes possible variants of a sequence interactions satisfying the goal or variants that lead to failure CSCE 431 Requirements

Use Cases The system treated as a black box (== the interactions with system, including system responses, are as perceived from outside the system) Use cases capture who (actor) does what (interaction) with the system, for what purpose (goal), without dealing with system internals A complete set of use cases specifies all the different ways to use the system, and therefore defines all behavior required of the system, bounding the scope of the system. Use case steps are written in an easy-to-understand structured narrative using the vocabulary of the domain With some help from graphical notations, such as UML use case and sequence diagrams CSCE 431 Requirements

Use Cases and Scenarios Use cases (often) defined based on scenarios Use cases vs. scenarios: Use case encapsulates a set of scenarios Each scenario is a single thread through a use case CSCE 431 Requirements

What is UML? UML == Unified Modeling Language Nonproprietary standard for modeling software systems, OMG Convergence of notations used in object-oriented methods OMT (Object Modeling Technique, James Rumbaugh and colleagues) Booch (Grady Booch) OOSE (Ivar Jacobson) Current Version: UML 2.3 (May 2010) Information at the OMG portal http://www.uml.orghttp://www.uml.org Commercial tools: Rational (IBM), Together (Borland), Visual Architect (business processes, BCD) Open Source tools: ArgoUML, BOUML, Dia, CSCE 431 Requirements

UML Diagrams CSCE 431 Requirements

UML Diagrams Use case diagrams Describe the functional behavior of the system as seen by the user Class diagrams Describe the static structure of the system: Objects, attributes, associations Sequence diagrams Describe the dynamic behavior between objects of the system Statechart diagrams Describe the dynamic behavior of an individual object Activity diagrams Describe the dynamic behavior of a system, in particular the workflow CSCE 431 Requirements

UML Conventions All UML Diagrams are graphs of nodes and edges Nodes are entities and drawn as rectangles or ovals Rectangles denote classes or instances Ovals denote functions Names of Classes are not underlined SimpleTimer Employee Names of Instances are underlined aTimer:SimpleTimer JohnSmith:Employee An edge between two nodes denotes a relationship between the corresponding entities CSCE 431 Requirements

Use Case Diagrams Used during requirements elicitation and analysis to represent behavior visible from outside the system An actor represents a role (a specific kind of a user of the system) A use case represents a class of functionality provided by the system Use case model is the set of all use cases that completely describe the system functionality CSCE 431 Requirements

Actor A model for an external entity that interacts with the system End user, administrator External system Physical environment (weather) Has a unique name and an optional description Examples: Student: a person that studies Teaching assistant: member of teaching staff who supports the instructor Random number generator CSCE 431 Requirements

Use Case Class of functionality Focus of description of a use case is the event flow between actors and system Not just UML use case diagrams, narrative should describe in detail: Participating actors Entry condition Flow of events Exit condition Exceptions Nonfunctional requirements CSCE 431 Requirements

Use Case Model CSCE 431 Requirements Bruegge, Dutoit: Object-Oriented Software Engineering: Using UML, Java, and Patterns

Related Use Cases Extend Relationship To represent seldom invoked use cases or exceptional functionality extend relationships model exceptional or seldom invoked cases The exceptional event flows are factored out of the main event flow for clarity The direction of an extend relationship is to the use case being extended Use cases representing exceptional flows can extend more than one use case. Include Relationship To represent functional behavior common to more than one use case include behavior is factored out for reuse, not because it is an exception The direction of an include relationship is to the use case being used CSCE 431 Requirements

Example: extend, include CSCE 431 Requirements Bruegge, Dutoit: Object-Oriented Software Engineering: Using UML, Java, and Patterns

Description Example 1. Name: DoHomework 2. Participating actor: Student 3. Entry condition: 1. Student ready to download exercise sheet 4. Exit condition: 1. Student delivered solution 5. Flow of events: 5.1. Student downloads the exercise sheet 5.2. Student reads through the assignments 5.3. Student processes the assignments and types the solution in his Computer. 5.4. Student prints out the solution 5.5. Student delivers the solution through the submission system 6. Special requirements: None CSCE 431 Requirements

Advice A good use case must: Describe a business task Not be implementation-specific Provide appropriate level of detail Be short enough to be implemented by one developer in one release CSCE 431 Requirements

Value of Use Cases Debated According to Meyer: Use cases are a minor tool for requirement elicitation but not really a requirement technique. They cannot define the requirements: Not abstract enough Too specific Describe current processes Do not support evolution Use cases are to requirements what tests are to software specification and design Cannot capture all requirements of a system CSCE 431 Requirements

Summary of Requirements Goal: SRS that describe the problem, not solution Variety of sources and means for eliciting requirements Use what makes most sense in the situation Variety of definition and specification techniques Use what makes most sense in the situation Requirements should be validated (that they meet customer expectations) Specifications should be verified (that they satisfy requirements) CSCE 431 Requirements

csce 431: requirements some material from b. meyer, m. oriol, b. schoeller, eth zurich

Documents