CSCE 431: Requirements

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

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

3. 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

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

5. 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

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

7. 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 customer’s 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

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

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

10. 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

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

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

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

14. 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

15. 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

16. Domain Assumption? CSCE 431 Requirements

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

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

19. 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

20. Bad Requirements, Example 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. The messages shall be updated every 60 ± 10 seconds after background task processing begins. The messages shall remain visible continuously. Whenever communication with the background task process is possible, the BTM shall display the percent completed of the background task. CSCE 431 Requirements

21. Bad Requirements, Another 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. CSCE 431 Requirements

22. Bad Requirements, Another NOT SO GOOD The XML parser shall produce a markup error report that allows quick resolution of errors when used by XML novices. BETTER 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. If no parsing errors are found, the parser shall not produce an error report. CSCE 431 Requirements

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

24. 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

25. A Simple Problem NAUR’S 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: Line breaks must be made only where the given text has BLANK or NL; Each line is filled as far as possible as long as No line will contain more than MAXPOS characters. • Peter Naur, Programming by Action Clusters, BIT, vol. 9, no. 3, pp. 250-258 CSCE 431 Requirements

26. “Improved” Specification The program’s 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 characters—BL (blank) and NL (new line); • nonbreak characters—all others except ET; • the end-of-text indicator–ET. 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 program’s 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 program’s output should have the following properties: • A new line should start only between words and at the beginning of the output text, if any. • A break in the input is reduced to a single break character in the output. • As many words as possible should be placed on each line (i.e., between successive NL characters). • No line may contain more than MAXPOS characters (words and BLs). 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 CSCE 431 Requirements

27. Meyer’s Analysis • The following discussion is based on Bertrand Meyer’s 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

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

29. Noise The program’s 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 characters—BL (blank) and NL (new line); • nonbreak characters—all others except ET; • the end-of-text indicator–ET. 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 program’s 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 program’s output should have the following properties: • A new line should start only between words and at the beginning of the output text, if any. • A break in the input is reduced to a single break character in the output. • As many words as possible should be placed on each line (i.e., between successive NL characters). • No line may contain more than MAXPOS characters (words and BLs). CSCE 431 Requirements

30. Remorse The program’s 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 characters—BL (blank) and NL (new line); • nonbreak characters—all others except ET; • the end-of-text indicator–ET. 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 program’s 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 program’s output should have the following properties: • A new line should start only between words and at the beginning of the output text, if any. • A break in the input is reduced to a single break character in the output. • As many words as possible should be placed on each line (i.e., between successive NL characters). • No line may contain more than MAXPOS characters (words and BLs). CSCE 431 Requirements

31. 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

32. Contradictions The program’s 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 characters—BL (blank) and NL (new line); • nonbreak characters—all others except ET; • the end-of-text indicator–ET. 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 program’s 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 program’s output should have the following properties: • A new line should start only between words and at the beginning of the output text, if any. • A break in the input is reduced to a single break character in the output. • As many words as possible should be placed on each line (i.e., between successive NL characters). • No line may contain more than MAXPOS characters (words and BLs). CSCE 431 Requirements

33. Over-specification The program’s input is a stream of characters whoseend 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 characters—BL (blank) and NL (new line); • nonbreak characters—all others except ET; • the end-of-text indicator–ET. 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 program’s 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 program’s output should have the following properties: • A new line should start only between words and at the beginning of the output text, if any. • A break in the input is reduced to a single break character in the output. • As many words as possible should be placed on each line (i.e., between successive NL characters). • No line may contain more than MAXPOS characters (words and BLs). CSCE 431 Requirements

34. Ambiguity The program’s 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 characters—BL (blank) and NL (new line); • nonbreak characters—all others except ET; • the end-of-text indicator–ET. 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 program’s 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 program’s output should have the following properties: • A new line should start only between words and at the beginning of the output text, if any. • A break in the input is reduced to a single break character in the output. • As many words as possible should be placed on each line (i.e., between successive NL characters). • No linemay contain more than MAXPOS characters (words and BLs). CSCE 431 Requirements

35. Forward References (implicit) The program’s 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 characters—BL (blank) and NL (new line); • nonbreak characters—all others except ET; • the end-of-text indicator–ET. 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 program’s 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 program’s output should have the following properties: • A new line should start only between words and at the beginning of the output text, if any. • A break in the input is reduced to a single break character in the output. • As many words as possible should be placed on each line (i.e., between successive NL characters). • No line may contain more than MAXPOS characters (words and BLs). CSCE 431 Requirements

36. Improved (w/o Quotes) Given are a non-negative integer MAXPOS and a character set including two “break characters” blankand 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. Spec from Meyer CSCE 431 Requirements

37. 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

38. 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

39. 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

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

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

42. 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

43. IEEE Standard: Definitions Contract A 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. Customer The 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. Supplier The 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. User The 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

44. 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 system’s 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

45. IEEE Standard: SRS’s 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

46. 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

47. 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

48. 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

49. 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

50. 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