CS 5150 Software Engineering Lecture 9 Requirements 2

Administration Feasibility Study Comments will be sent to all groups. Contact me if you have any questions.

Feasibility Studies: First Comments The purpose of a feasible study is to establish if a project is feasible, at reasonable cost, within the planned period. • Many of your reports had not gone into the requirements in enough detail to understand the challenges thoroughly. • Several of the reports were vague about the scope. Without a clear definition of scope, it is not clear that the project is feasible. • Almost every project is too ambitious. How will you monitor the progress and adjust the scope if necessary?

Weekly Progress Report Weekly progress reports • Every Friday beginning October 2, except weeks when there is a milestone. • Send email to Teaching Assistant. • Three short sections (total about one page) -> What has been accomplished in the past week (list of tasks)? -> What is planned for the next week? -> Have any problems arisen? • Respond to any concerns that we have raised about your plans (e.g., in comments on the feasibility study or by email).

Functional Requirements Functional requirements describe the functions that the system must perform. They are identified by analyzing the use made of the system: • Functionality • Data • User interfaces Analyzing and specifying the functional requirements is the theme of the this lecture and the next.

Non-Functional Requirements Requirements that are not directly related to the functions that the system must perform Product requirements performance, reliability, portability, etc... Organizational requirements delivery, training, standards, etc... External requirements legal, interoperability, etc... Marketing and public relations Example: In the NSDL, the client (the National Science Foundation) wanted a system that could be demonstrated by the end of 2002

Example of Non-Functional Requirements Example: Library of Congress Repository Use technology that the client's staff are familiar with: Hardware and software systems (IBM/Unix) Database systems (Oracle) Programming languages (C and C++) Recognize that the client is a federal library: Regulations covering government contracting, accessibility to people with disabilities, etc. Importance of developing a system that will be respected by other major libraries

Unspoken Requirements Examples: Resistance to change Departmental friction Management strengths and weaknesses Discovering the unspoken requirements is often the most difficult part of developing the requirements.

Requirements Analysis v. System Design Dilemma about technical decisions • Requirements analysis should make minimal assumptions about the system design. • But the requirements definition must be consistent with computing technology and the resources available. In practice, analysis and design are interwoven. However: 1. Do not to allow the requirements analysis to prejudge the system design. 2. Do not allow assumptions about the design to influence the requirements analysis.

Scenarios Scenario A scenario is a tool used during requirements analysis to analyze a user's interactions with a proposed system. Scenarios capture the system as visualized by the user, by use of operational examples. Note on terminology Some authors restrict the word "scenario" to refer to the user's total interaction with the system. Other authors use the word "scenario" to refer to parts of the interaction. In this course, the term is used with both meanings.

Developing a Scenario with a Client Example of how to develop a scenario with a client The requirements are being developed for a system that will enable university students to take exams online from their own rooms using a Web browser. Create a scenario for how a typical student interacts with the system. In the next few slides, the questions in blue are typical of the questions to ask the client while developing the scenario.

Developing a Scenario with a Client: a Typical Student Individual: Jane Smith, senior at Cornell, major in computer science. [Where can she be located? Do other universities differ?] Equipment: [What equipment is supported? What software is required? Are there any network restrictions?] Scenario: 1. JS authenticates. [How does she authenticate?] 2. JS starts browser and types URL of Exam system. [How does she know the URL?] 3. Exam system displays list of options. [Is the list tailored to the individual user? If so how?]

Developing a Scenario with a Client (continued) 4. JS selects CS 1234 Exam 1. [Does she have other options?] 5. A list of questions is displayed, each marked to indicate whether completed or not. [Where does this information come from?] 6. JS selects a question and specifies whether she will submit a new answer or edit a previous answer. [Does she always have these options?] 7. For the first question, she is submitting a new answer. She has a choice whether to type the solution into the browser or to attach a separate file. She decides to attach a file. [What types of question are there: text, multiple choice, etc? What types of file are accepted?]

Developing a Scenario with a Client (continued) 8. For the second question, she is editing a previous answer. She chooses to delete a solution previously typed into the browser, and to replace it with an attached file. [Can she edit a previous answer, or must she replace it?] JS has now completed the exam. She selects an option that submits the exam to the grading system. [What happens to the solution? What if she has not attempted every question? Where is the exam stored? Is the grader notified?] 10. JS logs off. 11. JS now wishes to change a solution. The system does not permit changes once the solution has been submitted. [Can she still see her solution?]

Developing a Scenario with a Client (continued) 12. As an alternative to completing the entire exam in a single session, JS completes several questions, then saves her work to continue later. [Is this permitted?] 13. Later JS log in, finishes the exam, submits her answers, and logs out. [What is the process for re-authenticating?] 14. Later JS logins in to check her grades. [When are grades made available? How does she know?] 15. JS requests a regrade. [What are the policies? What are the procedures?]

Modeling Scenarios as Use Cases Models Scenarios are useful in discussing a proposed system with a client, but requirements need to be made more precise before a system is fully understood. This is the purpose of requirements modeling. A use case provides such a model. There is a good discussion of use cases in Wikipedia. The approach used in this course is less complex than the Wikipedia article.

Models: Useful Texts Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modeling Language. Addison-Wesley 1999. Grady Booch, Object-Oriented Analysis and Design with Applications, second edition. Benjamin/Cummings 1994. Rob Pooley, Perdita Stevens, Using UML Software Engineering with Objects and Components. Addison-Wesley 1999.

Models A model is a simplification of reality. • We build models so that we can better understand the system we are developing. • We build models of complex system because we cannot comprehend such a system in its entirety. Models can be informal or formal. The more complex the project the more valuable a formal model becomes. BRJ

Principles of Modeling • The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped. • Every model can be expressed at different levels of precision. • The best models are connected to reality. • No single model is sufficient. Every nontrivial system is best approached through a small set of nearly independent models. BRJ

The Unified Modeling Language UML is a standard language for modeling software systems • Serves as a bridge between the requirements specification and the implementation. • Provides a means to specify and document the design of a software system. • Is process and programming language independent. • Is particularly suited to object-oriented program development.

Rational Rose Rational Rose is an IBM-owned system for creating and managing UML diagrams. It is available on Computer Science Department computers.

Models: Diagrams and Specification in UML In UML, a model consists of a diagram and a specification. A diagram is the graphical representation of a set of elements, usually rendered as a connected graph of vertices (things) and arcs (relationships). Each diagram is supported by technical documentation that specifies in more detail the model represented by the diagram. A diagram without a specification is of little value.

Actor and Use Case Diagram • An actor is a user of a system in a particular role. An actor can be human or an external system. • A use case is a a task that an actor needs to perform with the help of the BookBorrower PressureSensor Borrow book RecordPressure

Use Cases and Actors • Actor is role, not an individual (e.g., librarian can have many roles) • Actor must be a beneficiary of the use case (e.g., not librarian who processes book when borrowed) In UML, the system boundary is the set of use cases. In naming actors, use names that describe the use case, not generic names, such as "user" or "client".

Outline of ExamTaker Use Case Name: TakeExam Actor(s): ExamTaker Flow of events: 1. ExamTaker connects to the Exam server. 2. Exam server checks whether student is already authenticated and transfer to Sidecar for authentication if necessary. 3. ExamTaker selects a exam from a list of options. 4. ExamTaker repeatedly selects a question and either types in a solution, attaches a file with a solution, edits a solution or attaches a replacement file.

Outline Specification of Use Case (continued) Flow of events (continued): 5. ExamTaker either submits completed exam or saves current state. 6. When a completed exam is submitted, Exam server checks that all questions have been attempted and either sends acknowledgement to ExamTaker, or saves current state and notifies ExamTaker of incomplete submission. 7. ExamTaker logs out. Entry conditions: 1. ExamTaker must have Cornell NetID. 2. Computing requirements: Supported browser and Sidecar

Use Case Diagram for Exam System TakeExam ExamTaker CheckGrades RequestRegrade Three separate use cases

Use Cases for Exam System SetExam Instructor Grade Note that actor is a role. An individual can be a ExamTaker on one occasion and an Instructor at a different time. Regrade

Relationships Between Use Cases: <<includes>> TakeExam <<includes>> Authenticate CheckGrades <<includes>> ExamTaker The Authenticate use case may be used in other contexts

Relationships Between Use Cases: <<extends>> ConnectionFails TakeExam ExamTaker <<include>> is used for events that are in the flow of events of the source use case. <<extends>> is used for exceptional conditions, especially those that can occur at any time.

Scenarios for Analyzing Special Requirements Scenarios are very useful for analyzing special requirements. Examples • Reversals. In a financial system, a transaction is credited to the wrong account. How is it reversed? • Errors. A mail order company has several copies of its inventory database. What happens if they become inconsistent? • Malfeasance. In a voting system, a voter has houses in two cities. What happens if he attempts to vote in both of them? Murphy's Law: "If anything can go wrong, it will". Create a scenario for everything that can go wrong and how the system is expected to handle it.

Scenarios and Use Cases in the Development Cycle Scenarios are a tool for requirements analysis. • They are useful to validate use cases and in checking the design of a system. • They can be used as test cases for acceptance testing Use cases are a tool for modeling requirements • They are intuitive -- easy to discuss with clients • Use cases are often hard to translate into class models • The requirements specification may be based on a set of use cases.

Documentation: General Reasons for documentation: visibility (e.g., project plan, interim report) user support (e.g., user manual) team communication (e.g., interface specifications) maintenance and evolution (e.g., requirements) Characteristics of documentation: accurate and kept current appropriate for audience maintained online (usually) simple but professional in style and appearance Documentation is expensive --> Quality not volume

Documentation of Requirements Specification: Purpose Describe requirements to stakeholders in a precise manner • Expressed in the terms that the stakeholders understand • Precise and specific • Comprehensible from many viewpoints • Reviewed by stakeholders so that they understand implications • Must be clear about assumptions (things left out)

Requirements Specification: Purpose Describe the requirements to the implementers • Precise and specific • Expressed in terms that they understand -- must have details • Comprehensible to new team members

Requirements Documentation (continued on next slide) The form of documentation varies, but is likely to contain the following: General Purpose and scope of system Objectives and criteria for success List of terminology, organizations involved, etc. Description of current system(s)

Requirements Documentation (continued) Requirements of proposed system Overview Functional Requirements Usability requirements Non-functional requirements Models Scenarios Use cases Models used during analysis

Requirements Documentation (continued) Detailed Specifications Business rules, specifications, etc. (e.g., reference to an accounting standard) Data flow, sources of data, data formats and constraints, data validation etc., etc., The most common fault in requirements documentation is to gloss over the details. This results in misunderstandings between the client and the developers.

Realism and Verifiability Requirements must be realistic, i.e., it must be possible to meet them. Wrong: The system must be capable of x (if no known computer system can do x at a reasonable cost). Requirements must be verifiable, i.e., it must be possible to test whether a requirement has been met. Wrong: The system must be easy to use. Right: After one day's training an operator should be able to input 50 orders per hour.

Requirements Specification: Details Requirements must be specific Examples -- university admissions system Requests for information received by email must be answered within one business day. An admissions officer who is talking to an applicant by telephone must be able to retrieve the applicant's records within 10 seconds. No financial aid offer may exceed the maximum defined in Section 8.7.

Requirements Specification: Process The client must understand the requirements specification • Do not assume that anybody has read a document. • Do not assume that anybody understands a document. Go through the requirements specification with the client, line by line. It is usual for the client and developer to sign the requirements document when it is agreed. [Compare with the plans to build a house. This is the specification of the system that you are about to build.]