CS 501: Software Engineering Fall 2000 Lecture 3 (a) Feasibility Study (b) Requirements Definition.
1 CS 501 Spring 2008 CS 501: Software Engineering Lecture 9 Requirements II.
-
date post
20-Dec-2015 -
Category
Documents
-
view
219 -
download
1
Transcript of 1 CS 501 Spring 2008 CS 501: Software Engineering Lecture 9 Requirements II.
1 CS 501 Spring 2008
CS 501: Software Engineering
Lecture 9
Requirements II
2 CS 501 Spring 2008
Administration
Quiz 1
If you did not pick it up on Thursday, you can collect your quiz from reception at 301 College Avenue
Feasibility Study
Comments have been sent to several groups. I plan to have them all sent out by the end of today.
3 CS 501 Spring 2008
Weekly Progress Report
Every project will be assigned a Teaching Assistant.
Weekly progress reports
• Every Friday beginning, February22
• Send email to Teaching Assistant
• Three short sections (total less than one page)
-> What has been accomplished in the past week (list of tasks)?
-> What is planned for the next week?
-> Have any problems arisen?
4 CS 501 Spring 2008
Requirements Analysis v. System Design
Dilemma.
• 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.
5 CS 501 Spring 2008
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.
6 CS 501 Spring 2008
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
7 CS 501 Spring 2008
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
8 CS 501 Spring 2008
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.
9 CS 501 Spring 2008
Rational Rose
Rational Rose is an IBM-owned system for creating and managing UML diagrams.
It is available for Computer Science Department computers.
10 CS 501 Spring 2008
Diagrams and Specification in UML
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 documentation is of little value.
11 CS 501 Spring 2008
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
Use cases make more precise the concept of viewpoint analysis.
12 CS 501 Spring 2008
Use Cases and Actors
• A scenario is an instance of a use case
• 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.
13 CS 501 Spring 2008
Accessibility Profile
Accessibility
Creating computer systems that can be used by people with special needs, e.g., poor vision, lack of hearing, disabilities, etc.
Profile
A description of a user with special needs, e.g.,
• an elderly person with 20/70 vision who is unable to control a mouse
• a 20 year old student who is red-green color blind
14 CS 501 Spring 2008
Scenario
A scenario is a tool used during requirements analysis to walk through a specific interaction with a proposed system.
Example
The requirements are being developed for a system that will enable university students to take quizzes online from their own rooms using a Web browser.
Create a scenario for a typical student.
15 CS 501 Spring 2008
Scenario: a Typical Student
Individual: Philip Glass, senior at Cornell, major in computer science, location Risley Hall.
Equipment: Dell laptop attached to Cornell dormitory network. Firefox 2.0 browser and Sidecar authentication system installed.
Scenario:
1. PG powers up computer and authenticates using Sidecar.
2. PG starts browser and types URL of Quiz system.
3. Quiz system displays list of options.
16 CS 501 Spring 2008
Scenario (continued)
4. PG selects CS 501 Quiz 1.
5. A list of questions is displayed, each marked to indicate whether completed or not.
6. PG selects a question and specifies whether he will submit a new answer or edit a previous answer.
7. For the first question, he is submitting a new answer. He has a choice whether to type the solution into the browser or to attach a separate file. He decides to attach a file.
8. For the second question, he is editing a previous answer. He chooses to delete a solution previously typed into the browser, and to replace it with an attached file.
17 CS 501 Spring 2008
Scenario (continued)
9. PG has now completed the quiz. He selects an option that submits the quiz to the grading system.
10. PG now wishes to change a solution. The system does not permit changes once the solution has been submitted.
11. PG logs off.
18 CS 501 Spring 2008
Modeling Scenarios as Use Cases
A scenario is useful in discussing a proposed system with a client, but needs to be generalized as part of the requirements modeling.
A use case provides such a model.
There is a detailed discussion of use cases in Wikipedia. The approach used in this course is less complex than the Wikipedia article.
19 CS 501 Spring 2008
Specification of Use Case
Name: TakeQuiz
Actor(s): QuizTaker
Flow of events:
1. QuizTaker connects to the Quiz server.
2. Quiz server checks whether student is already authenticated and transfer to Sidecar for authentication if necessary.
3. QuizTaker selects a quiz from a list of options.
4. QuizTaker repeatedly selects a question and either types in a solution, attaches a file with a solution, edits a solution or attaches a replacement file.
20 CS 501 Spring 2008
Specification of Use Case (continued)
Flow of events (continued):
5. QuizTaker either submits completed quiz or saves current state.
6. If a completed quiz is submitted, Quiz server checks that all questions have been attempted and either sends acknowledgement to QuizTaker, or saves current state and notifies QuizTaker of incomplete submission.
7. QuizTaker logs out.
Entry conditions:
1. QuizTaker must have Cornell NetID.
2. Computing requirements: CIT supported browser and Sidecar
21 CS 501 Spring 2008
Use Case Diagram for Quiz System
TakeQuiz
QuizTaker
CheckGrades
RequestRegrade
22 CS 501 Spring 2008
Use Cases for Quiz System
SetQuiz
Instructor
Grade
RegradeNote that actor is a role. An individual can be a QuizTaker on one occasion and an Instructor at a different time.
23 CS 501 Spring 2008
Relationships Between Use Cases: <<includes>>
QuizTakerAuthenticate
TakeQuiz
<<includes>>
<<includes>>
CheckGrades
24 CS 501 Spring 2008
Relationships Between Use Cases: <<extends>>
TakeQuizQuizTaker
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.
25 CS 501 Spring 2008
Use Cases in the Development Cycle
• Use cases are a tool in requirements analysis
• Intuitive -- easy to discuss with clients
• Use cases are often hard to translate into class models
• Scenarios are useful to validate use cases and the design of a system.
26 CS 501 Spring 2008
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 currentappropriate for audiencemaintained online (usually)simple but professional in style and appearance
Documentation is expensive --> Quality not volume
27 CS 501 Spring 2008
Documentation of Requirements Specification: Purpose
1. Document that describes the requirements to the stakeholders in a precise manner
• Expressed in the terms that the stakeholders understand
• As precise and specific as possible
• Comprehensible from many viewpoints
• Reviewed by stakeholders so that they understand implications
• Must be clear about assumptions (things left out)
28 CS 501 Spring 2008
Requirements Specification: Purpose
2. It describes the requirements to the implementers
• As precise and specific as possible
• Expressed in terms that they understand
• Comprehensible to new team members
29 CS 501 Spring 2008
Requirements Specification: Purpose
3. It records the requirements for the future
• An essential part of system evolution
4. It may be a contractual document
30 CS 501 Spring 2008
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.
31 CS 501 Spring 2008
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.]
*