31
CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

Embed Size (px)

Citation preview

Page 1: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 1

CS 5150 Software Engineering

Lecture 9

Requirements 2

Page 2: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 2

Administration

Feasibility Study

Comments have been sent to all groups. Contact me if you have any questions.

Page 3: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 3

Feasibility Studies: Scope

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 activities in enough detail to estimate the effort convincingly.

• Several of the reports were vague about the scope. Without a clear definition of scope, it is not clear that the project is feasible.

• Several projects are too ambitious. How will you monitor the progress and adjust the scope if necessary?

Page 4: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 4

Feasibility Studies: Reports

Appoint a team member to read and edit the entire report.

Content

• If different authors write different sections of the report are they consistent? E.g., do the scope, requirements, and plan agree on what is to be done?

Style

• Is the text comprehensible? Does the report use jargon that is not clear to the client?

• If possible, have a native English speaker do the final editing.

Page 5: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 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

Modeling the functional requirements is the theme of the this lecture and the next.

Page 6: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 6

Non-Functional Requirements

Requirements that are not directly related to the functions that the system must perform

Product requirementsperformance, reliability, portability, etc...

Organizational requirementsdelivery, training, standards, etc...

External requirementslegal, interoperability, etc...

Marketing and public relationsExample: In the NSDL, the client (the National Science Foundation) wanted a system that could be demonstrated by the end of 2002

Page 7: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 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

Page 8: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 8

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 allow assumptions about the design to influence the requirements analysis.

2. Do not to allow the requirements analysis to prejudge the system design.

Page 9: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 9

Scenarios

Scenario

A scenario is a tool used during requirements analysis to describe a user's interactions with a proposed system. Scenarios capture the system as visualized by the user, by use of specific 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.

Page 10: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 10

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.

Page 11: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 11

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

Page 12: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 12

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

Page 13: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 13

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

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

Page 14: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 14

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

Page 15: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 15

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

Page 16: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 16

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

Page 17: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 17

Models: Useful Texts

Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modeling Language. Addison-Wesley 1999.

Grady Booch, et al., Object-Oriented Analysis and Design with Applications, third edition. Benjamin/Cummings 2007.

Rob Pooley, Perdita Stevens, Using UML Software Engineering with Objects and Components, second edition. Addison-Wesley 2005.

Page 18: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 18

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.

Page 19: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 19

Rational Rose

Rational Rose is an IBM-owned system for creating and managing UML diagrams.

It is available on Computer Science Department computers.

Page 20: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 20

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.

Page 21: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 21

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.

Page 22: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 22

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

Borrow book

BookBorrower

RecordPressure

PressureSensor

Page 23: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 23

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, choose names that describe the use case, not generic names, such as "user" or "client".

Page 24: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 24

Use Cases for Exam System

TakeExam

ExamTaker

CheckGrades

RequestRegradeThree separate

use cases

Page 25: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 25

Outline of TakeExam Use Case

Name of Use Case: TakeExam

Actor(s): ExamTaker

Flow of events:

1. ExamTaker connects to the Exam server.

2. Exam server checks whether student is already authenticated and runs authentication process 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.

Page 26: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 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

Page 27: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 27

Use Cases for Exam System (continued)

SetExam

Instructor

Grade

Regrade

Note that actor is a role. An individual can be a ExamTaker on one occasion and an Instructor at a different time.

Page 28: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 28

Relationships Between Use Cases: <<includes>>

ExamTaker

Authenticate

TakeExam

<<includes>>

<<includes>>

CheckGrades

The Authenticate use case may be used in other contexts

Page 29: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 29

Relationships Between Use Cases: <<extends>>

TakeExamExamTaker

ConnectionFails

<<extends>>

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

Page 30: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 30

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.

Page 31: CS 5150 1 CS 5150 Software Engineering Lecture 9 Requirements 2

CS 5150 31

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

• A set of use cases can provide a framework for the requirements specification.