1. CS 5150 Software Engineering
Lecture 9
Requirements 2

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

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

4. Weekly Progress Report
Weekly progress reports
• Every Friday beginning October 2, except weeks when there is a milestone.
• Send 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 ).

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

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

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

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

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

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

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

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

13. 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?]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

34. 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)

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

36. 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)

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

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

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

40. Requirements Specification: Details
Requirements must be specific
Examples -- university admissions system
Requests for information received by 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.

41. 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.]