CSE 5324:
Software Engineering I
(Analysis, Design, Creation) Spring 1998
Today's class:
OR February 26, 1998
3. Brooks Book Chapter
4. Today:
Requirements, Structured Analysis
Finalize Teams (for projects)
EXAM 1:
Over ALL material since beginning of class:
(Introduction, terms, products, processes, life cycles,
CMM, Systems Engineering, Re-engineering,
Analysis, Requirements, SA, Formal Methods,
Cleanroom)
Textbook: Chaps: 1, 2, 10, 27, 11, 12, 24, 25
Brooks: Not specific (maybe bonus), General
Review: Thursday: Feb.19, 1998, in class
When:
February 26, 1998 (Requested) ß AS REQUESTED!
Last:
Requirements:
When to do?
What to do?
List of whats. Black Box.
Why important.
Definition. Specification.
Errors, cost of errors.
What are good requirements (specification)?
The requirements process.
TODAY: Requirements:
What are Good Requirements?
(Specification Principles)
Separate functionality from implementation.
A process-oriented systems specification language
is required.
A specification must encompass the system of which
the software is a component.
A specification must encompass the environment in
which the system operates.
A system specification must be a cognitive model.
A specification must be operational.
The system specification must be tolerant of
incompleteness and be augmentable.
A specification must be localized and loosely
coupled.
Characteristics of Good Requirements
Applicability - relevant to the application domain.
Correctness - describe proper behavior of system.
Completeness - everything that the software is
supposed to do is included in the requirements.
Consistency - no subset of individual requirements
conflict.
Feasibility - can be implemented.
Free of design detail
Non-ambiguous - every requirement stated has only
one interpretation.
Testable - every requirement stated can be tested.
Traceability - origin of each requirement is clear.
Requirements Analysis Process
Domain Understanding
Understand the problem to be solved
Identify and research the problem domain
Requirements Collection
Elicit the requirements.
Record the requirements.
Classification
Organize the requirements into related groupings.
Conflict Resolution
Examine requirements to find and remove conflicts.
Prioritization
Prioritize the requirements.
Requirements Validation
Check requirements.
Are they complete and consistent?
These steps interact and are not necessarily sequential!
Communication Problems During Analysis
Users and analysts may find it difficult to communicate.
Developer usually does not understand the client's
problem domain.
The client often does not understand the issues
involved with software systems.
The above two points reflect a communication gap
between developer and client.
Problems with English (natural) language:
Ambiguous.
Details are often omitted or not clearly expressed.
Leads to misunderstandings.
Using formal languages or notations:
Not always understood by client.
However, permits requirements to be stated
precisely.
How Do You Find Requirements?
REQUIREMENTS ELICITATION -
is the process of drawing forth or extracting,
understanding, and communicating requirements.
Talk to client about what they want the system to do.
Common sources of requirements include: people,
documents, and existing systems.
Ask how they plan to use the system (scenarios)
Identify external events to which system must
respond
Think about how to make it useful
Specify user interface and how it behaves
Build a model of the requirements and ask the client for
feedback.
QFD
Analysis:
Principles, DP-Information, Modeling, Partitioning, Views
Prototyping
Specification
Review
For Example:
Balance parenthesis:
( ( ( ) ( ) (( ) ) ) )
or ( ( ) ) ) ( ) )
) (
Requirements:
What to do.
Between System Engineering and Design.
What, NOT how.
Communication and the "process"
QFD:
Normal - stated
Expected - implicit
Exciting - beyond expectations
Analysis:
Principles, DP-Information, Modeling, Partitioning, Views
Prototyping
Specification
Review
Analysis "modeling"
What is modeling?
Many methods for analysis modeling:
Structured Analysis
Object-Oriented Analysis
Warnier-Orr (DSSD)
SADT
Jackson
How can one describe (technically) what is needed?
"Viewpoint-oriented" analysis
Method-based
Data Flow Models
Semantic data model
Requirements
Definition and Specification
Functional
Natural Language
Description Languages
Graphical Notation
Mathematical
Non-Functional
Quality
Maintainability
Product
Organizational
External
Data Modeling:
Data Objects
Attributes
Relationships
Entity-Relationships (ERD)
Functional:
Data Flow (DFD)
Graphical, with words
(Real Time)
Control Flow (CFD)
Process descriptions (PSPEC)
CSPEC
Levels of DFD
Data Dictionary (DD)
For Example:
Verify telephone numbers:
(Textbook)
Verify e-mail address:
Name
(how long, what characters)
Domains
What is legal?
EXAMPLE:
How are people's names usually written or stated?
Mr. Henry Badillo, Dr. C. Shen,
Krishna O'Brian, Ms. M. Lewinsky
(Should we ignore: Prince, Cher, Bill,
Dr. Ted Longfeather M.D. ?)
EXAMPLE:
(How are people's names usually written or stated?)
name = (title) + first-name
+ (middle-name) + last-name
title = [ Mr. | Mrs. | Ms. | Dr. | Professor ] first-name = {legal-character}
middle-name = {legal-character}
last-name = {legal-character}
legal-character = [ A - Z | a-z | 0-9 | ' ]
But this allows:
Tom 3 Benoit
Li 1 2
Dr. ' '
Ms. barbara 4be
And not:
Bob Chen-Ramamurthy
Claude Thâce(Can you correct this?)