CS 501: Software Engineering Requirements 3 CS 501 Spring 2005 Lecture 9

advertisement
CS 501: Software Engineering
Lecture 9
Requirements 3
1
CS 501 Spring 2005
Course Administration
Feasibility Study
Everybody should received comments shortly.
Teaching Assistants have been assigned.
Quiz 1
Uncollected answer books are at the reception at
301 College Avenue.
2
CS 501 Spring 2005
Discussion of Feasibility Study
General
Who will read the feasibility study?
What is needed to decide to go ahead?
Scope and understanding of project
Statement of the task
Preliminary requirements and technical analysis
Deliverables and business considerations
Confidence
Outline plan. Does it inspire confidence?
Visibility plan. How will progress be reported?
Risk analysis. How are the risks to be minimized?
3
CS 501 Spring 2005
Quiz 1 (c)
A U.S. government agency, which manages huge numbers of
documents, has received funds to build a large-scale computer
system.
The agency proposes to use a waterfall model of software
development, but an independent study recommends a
phased development using iterative refinement in the first
phase and a waterfall model in the second.
[On the next three slides, a short answer is given in Roman
type. Material in italic extends the short answers.]
4
CS 501 Spring 2005
Quiz 1 (c)
i Before this system is implemented some difficult technical
choices have to be made. How much should the choice of
technology be considered during the feasibility study?
During the feasibility study, it is necessary to know that there is at
least one technical approach that would allow the system to be
built. It should be studied in sufficient detail to allow estimates
of costs and time table.
If there appear to be several very different technical approaches
possible, more than one might be analyzed in sufficient detail to
understand the implications for the costs and timetable.
5
In this project, the feasibility study should also plan the process
by which the technical decisions will be made.
CS 501 Spring 2005
Quiz 1 (c)
ii These technical choices are one of the reasons that
iterative refinement is recommended for the first phase of
development. Why?
The first iteration will use the team's initial technical
knowledge, but will likely show weaknesses in the approach
chosen. Subsequent iterations will replace or improve aspects
of the technical choices until a version is established that
meets the requirements of the project.
A waterfall model is unsuitable because of the large-scale
changes that may need to be made. Because of uncertainty, it
is difficulty to judge the cost and timetable of the project until
this stage is complete.
6
CS 501 Spring 2005
Quiz 1 (c)
iii What is the advantage of using the waterfall model in the
second phase?
The waterfall model with feedback is an effective way to
build a system that is well understood, so that few changes
are likely to be made in either the requirements or the design.
At its best, a waterfall process results in each stage being
done once and being done well. For this system, the
iterations made during the first phase should have created a
high level of understanding and agreement about the entire
system.
7
CS 501 Spring 2005
Software Development Principles and
Practices
Software development
Software development is a craft. Software
developers have a variety of tools that can be
applied in different situations.
Part of the art of software development is to
select the appropriate tool for a given
implementation
8
CS 501 Spring 2005
Modeling Techniques for
Requirements Analysis and Definition
The craft of requirements analysis and specification is to
select the appropriate tool for the particular task.
• A variety of tools and techniques.
• Many are familiar from other courses.
• There is no correct technique that fits all situations.
As you build understanding of the requirements through
scenarios and use cases, use modeling tools to specify
requirements. The models provide a bridge between the
client's understanding and the developers.
9
CS 501 Spring 2005
Decision Table: Bad Example
University Admission Decision
High SAT
T
F
F
F
F
F
High grades
-
T
F
F
F
F
Sports
-
-
T
T
F
F
Recommendations
-
-
T
F
T
F
X
X
X
Reject
Accept
X
X
X
Note that the rules are too vague.
10
CS 501 Spring 2005
Decision Table: Good Example
University Admission Decision
SAT > S
T
F
F
F
F
F
GPA > G
-
T
F
F
F
F
Athletics code = 
-
-
T
T
F
F
Recommendations > A-
-
-
T
F
T
F
X
X
X
Send rejection letter
Send acceptance letter
X
X
X
Note that the rules are now specific and testable.
11
CS 501 Spring 2005
Data-Flow Models
An informal modeling technique to show the flow of
data through a system.
External entities
Processing steps
Data stores or sources
Data flows
12
CS 501 Spring 2005
Data-Flow Example:
University Admissions
Rejection
Application
Completed
form
Receive application
Evaluate
application
Applicant
Acceptance
Shows the flow, but where
is the data stored?
13
CS 501 Spring 2005
Data-Flow Example:
Assemble Application Stage
Acknowledgment
Application
form
Receive
Applicant
Supporting
information
14
Completed
application
Acknowledgment
AND
Initiate
evaluation
Evaluation
request
AND
Pending
database
Does this model
cover all
applications? Are
there special cases?
Applicant
database
CS 501 Spring 2005
Data-Flow Example:
Process Completed Application Stage
The data-flow diagram will
need specification of the
decision-making process.
Rejection
Evaluation
request
Acceptance
Evaluation
Financial
aid
Offer
Special
request
Applicant
database
15
CS 501 Spring 2005
Procedural Models: Flowchart
An informal modeling technique to show the decisions
and paths that data takes through a system.
Operation
Decision
Manual operation
Report
16
CS 501 Spring 2005
Flowchart: University Admissions
Form
received
New?
T
Database
record
F
Update
database
Complete? T
F
Notify
student
Evaluate
Notify
student
17
CS 501 Spring 2005
Procedural Models: Pseudo-code
An informal modeling technique to show the logic
behind part of a system.
Example: Check project plan
check_plan (report)
if report (date_time) > due_date_time then error (too_late)
if report (client) = none then error (no_client)
if report (team) < min_team or > max_team
then error (bad_team)
if error() = none
then comments = read_report (report)
return (comments (text), comments (grade))
else return error()
18
CS 501 Spring 2005
Entity-Relation Model
A requirements and design methodology for relational
databases
• A database of entities and relations
• Tools for displaying and manipulating entity-relation
diagrams
• Tools for manipulating the database (e.g., as input to
database design)
Warning: There is much confusion about definitions and
notation
19
CS 501 Spring 2005
Entity-Relation Diagram
An entity
A relation between
entities
An entity or relation
attribute
An inheritance
relation
20
CS 501 Spring 2005
Example: CS 501 Project
Major
Client
0:1
1:n
Student
Client team
member
Project
0:n
1
CS501
Student
21
5 to 7
0:1
Tech contact
Member of
CS 501 Spring 2005
Example: Schema for Web Data
22
CS 501 Spring 2005
MARC Format for Books
The MARC format defines a set of tagged fields that are
used to catalog books in libraries. Here are some examples.
001
245
260
650
650
700
Control number
Short title
Publisher
Subject heading
Subject heading
Author
Suppose you wish to use a relational database to store MARC
records.
23
CS 501 Spring 2005
Part of an Entity-Relation Diagram
for MARC
Book
0:n
Author of
0:n
1
0:n
Editor of
Describes
1
Catalog
record
Short title
24
1:n
Is about
Creator
0:n
0:n
Subject
heading
Control numb
CS 501 Spring 2005
Data Dictionaries
A data dictionary is a list of names used by the system
• Brief definition (e.g., what is "date")
• What is it (e.g., number, relation)
• Where is it used (e.g., source, used by, etc.)
• May be combined with a glossary
As the system is implemented, the data dictionary in the
requirements is input to the system data dictionary, which is a
formal part of the system specification.
25
CS 501 Spring 2005
Petri Nets
A Petri Net models parallelism
A
Event
S
f(A; E)
S
f(A; E1,..,En)
Event 1
A
S
S
Event n
Event 1
A
Event n
26
S1
..
f(A; E1,..,En)
S1,..,Sm
Sm
CS 501 Spring 2005
Transition Diagrams
A system is modeled as a set of states, Si
A transition is a change from one state to another.
The occurrence of a condition, Ci, causes the transition
from one state to another
Transition function:
f (Si, Cj) = Sk
0
Example
1
S1
0
27
1
S3
S2
0
1
CS 501 Spring 2005
Therapy Control Consol: Scenario
"The set up is carried out before the patient is made ready.
The operator selects the patient information from a database.
This provides a list of radiation fields that are approved for
this patient. The operator selects the first field. This
completes the set up.
The patient is now made ready. The lock is taken off the
machine and the doses with this field are applied. The
operator then returns to the field selection and choose
another field."
28
CS 501 Spring 2005
Therapy Control Consol:
Finite State Machine
Example: Radiation Therapy Control Console
You are developing requirements for the operator's
control console. In a client interview, the client describes
the dangers inherent in using the machine.
The operator must follow a strict procedure before the
machine is ready to run.
You use a finite state machine to specify the procedures.
This shows the client that you understand the
requirements and specifies the procedures for the
developers.
29
CS 501 Spring 2005
State Transition Diagram
Discuss each state
and transition with
the client.
Select field
Enter
Patients
Enter
Fields
Start
(lock off)
Setup
Beam
on
Ready
Stop
(lock on)
Select patient
30
CS 501 Spring 2005
Therapy Control Consol:
State Transition Table
Select Select
Enter lock off Start
Patient Field
Patients
Fields Patients
Setup Patients Fields
Ready Patients Fields
Beam
on
31
Stop
lock on
Fields
Setup
Ready
Beam
on
Setup
Ready Setup
CS 501 Spring 2005
Prototyping Requirements
Rapid prototyping is the most comprehensive of all
modeling methods
A method for specifying requirements by building a
system that demonstrates the functionality of key
parts of the required system
Particularly valuable for user interfaces
32
CS 501 Spring 2005
A Note on Object Models
This course teaches object models as a tool for design.
Some people recommend object models for requirements
definition, but it is difficult to use them without constraining
the system design.
Flow charts and finite state machines are supported by UML
as design models, but can also be used for requirements.
*
33
CS 501 Spring 2005
Download