Docsity
Docsity
Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity

Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan

Guidelines and tips
Guidelines and tips
Sell on Docsity
Sell on Docsity
Docsity AI
Docsity AI
Log inSign up

Prepare for your exams

Study with the several resources on Docsity

Find documents

Prepare for your exams with the study notes shared by other students like you on Docsity

Search for your university

Find the specific documents for your university's exams

Docsity AINEW

Summarize your documents, ask them questions, convert them into quizzes and concept maps

Explore questions

Clear up your doubts by reading the answers to questions asked by your fellow students

Earn points to download

Earn points by helping other students or get them with a premium plan

Share documents
download point icon20 Points

For each uploaded document

Answer questions
download point icon5 Points

For each given answer (max 1 per day)

All the ways to get free points
Get points immediately

Choose a premium plan with all the points you need

Study Opportunities

Choose your next study program

Get in touch with the best universities in the world. Search through thousands of universities and official partners

Community

Ask the community

Ask the community for help and clear up your study doubts

Free resources

Our save-the-student-ebooks!

Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors

1 UCLA CS130 – Software Engineering Structured Analysis ..., Summaries of Software Engineering

University of Chicago (UC)Software Engineering

UCLA CS130 – Software Engineering. Structured Analysis. Winter, 2002. Lecture Notes. January 28, 2002. Announcements. Summary of Last Lecture.

Typology: Summaries

2022/2023

Uploaded on 05/11/2023

amodini
amodini 🇺🇸

4.7

(19)

257 documents

1 / 6

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
1
UCLA CS130 – Software Engineering
Structured Analysis
Winter, 2002
Lecture Notes
January 28, 2002
Announcements
Summary of Last Lecture
Today’s Lecture
1. Topics
1.1. Analysis Concepts – how do we describe the functional and performance character-
istics of the system to be constructed?
• Requirements elicitation
• Analysis principles
• Software prototyping
• Specification
1.2. Analysis modeling
• Data modeling
• Functional Modeling, Information Flow
• Behavioral Modeling
• Structured Analysis Mechanics
• Data Dictionary
2. Analysis Concepts and Principles
2.1. Requirements analysis
2.1.1. SW engineering task resulting in:
• Specification of software’s operational characteristics (function, data, behav-
ior)
• Description of interface with other system components (e.g., following com-
mands can be sent to the wide-field camera; the wide-field camera will return
an image line every 10ms with an image having 910 lines).
• Identification of constraints (e.g., must run on a FOOBAR 911 CPU running
RISK-OS version 2.7 or later; functions A, B, and C must repeat every 20 ms
plus or minus 1ms; …).
2.1.2. Five areas of effort
• Problem recognition – identify problem elements using project plan, system
specification (if it exists), and customer communication.
• Evaluation and synthesis – uses problem elements identified in previous step
as input. Analyst defines:
• Externally-observable data objects
• Model information flow, content
• Define and elaborate SW functionality – what is SW supposed to do?
pf3
pf4
pf5

Partial preview of the text

Download 1 UCLA CS130 – Software Engineering Structured Analysis ... and more Summaries Software Engineering in PDF only on Docsity!

UCLA CS130 – Software Engineering Structured Analysis Winter, 2002 Lecture Notes January 28, 2002

Announcements

Summary of Last Lecture

Today’s Lecture

  1. Topics 1.1. Analysis Concepts – how do we describe the functional and performance character- istics of the system to be constructed? - Requirements elicitation - Analysis principles - Software prototyping - Specification 1.2. Analysis modeling - Data modeling - Functional Modeling, Information Flow - Behavioral Modeling - Structured Analysis Mechanics - Data Dictionary
  2. Analysis Concepts and Principles 2.1. Requirements analysis 2.1.1. SW engineering task resulting in: - Specification of software’s operational characteristics (function, data, behav- ior) - Description of interface with other system components (e.g., following com- mands can be sent to the wide-field camera; the wide-field camera will return an image line every 10ms with an image having 910 lines). - Identification of constraints (e.g., must run on a FOOBAR 911 CPU running RISK-OS version 2.7 or later; functions A, B, and C must repeat every 20 ms plus or minus 1ms; …). 2.1.2. Five areas of effort - Problem recognition – identify problem elements using project plan, system specification (if it exists), and customer communication. - Evaluation and synthesis – uses problem elements identified in previous step as input. Analyst defines: - Externally-observable data objects - Model information flow, content - Define and elaborate SW functionality – what is SW supposed to do?
  • Define SW behavior in context of events affecting system (e.g., how do we respond to an undervoltage condition on the spacecraft power bus?)
  • Establish system interface characteristics
  • Identify design constraints

SW engineers begin developing solutions to problems during this activity. Data objects defined in more detail, as are processing functions and behavior. SW architectures considered at this point.

Evaluation/synthesis continues until customer/SW engineers are confident that SW can be adequately spec’d for further development steps.

Focus is on “what”, not “how”

  • Modeling – models created during evaluation and synthesis to understand system behavior, data and control flow, functional processing, operational behavior, info content. Models serve as:
    • Basis for creating SW specs
    • Foundation for SW design
  • Specification
  • Review – hold FTRs to ensure specification is correct, complete, properly addresses customer requirements. 2.1.3. Focus is on “what”, not “how”. 2.2. Eliciting Requirements 2.2.1. Requirements must be gathered before analysis, modeling, or specification can begin. 2.2.2. Interview with customer – most common technique to start process. Initial inter- view with customer was discussed during lecture on project management. We did this last week with Sapient visit. 2.2.3. Facilitated Application Specification Techniques - FAST 2.2.3.1. “Us vs. them” – frequent problem in communications – drove devel- opment of FAST
  • Customers, SW engineers should work as a team to identify/refine requirements.
  • Often, each side defines its territory instead – communication is through documents, position papers, IOMs, Q&A sessions – this has been shown to be ineffective. 2.2.3.2. FAST – encourages team creation for purpose of:
  • Identifying problem
  • Propose solutions
  • Negotiate different approaches
  • Specify preliminary set of requirements Used primarily in info sys community, but applicable to development of many types of systems. 2.2.3.3. FAST guidelines

2.2.4.6. Raw data translated into customer voice table – reviewed with cus- tomer. 2.2.4.7. Various techniques then used to extract expected requirements, derive exciting requirements. 2.2.5. Use Cases 2.2.5.1. Set of scenarios describing how the system will be used. 2.2.5.2. To create a use case, need to identify actors – different types of people, devices, other system components will use the system.

  • Actors represent roles that people or devices play as system oper- ates. In an elevator, might have:
    • Passenger – calls elevator, selects floor
    • Repairman – interacts with elevator controls forbidden to pas- sengers to identify trouble
    • Fireman – additional control of elevator motion forbidden to passengers, but no repair usage

Actors often identified iteratively – primary actors during initial meetings with customer, secondary actors later. Primary actors work directly with system to do their work, secondary actors sup- port system to primary actors can do work.

2.2.5.3. Defining use cases – done after actors identified. Use cases should an- swer following questions concerning interaction with the system:

  • What main tasks/functions provided by the actor
  • What system information will the actor acquire, produce, or change?
  • What information does the actor want from the system?
  • Will the actor have to inform the system about changes in the ex- ternal environment?
  • Does the actor want to be informed about unexpected changes?

Use cases generally a simple written narrative describing role of actor as interaction with system occurs.

Use cases provide unambiguous scenario of interaction between an ac- tor and system.

Use cases can also provide timing/performance constraints for system. (e.g., elevator doors must shut 10 seconds after a destination floor is selected provided no other floors are selected in that interval).

2.3. Analysis Principles 2.3.1. All analysis methods have following operational principles:

  • Info domain of a problem must be understood, represented – allows better understanding of function
  • Functions to be performed must be defined
  • Behavior of SW w.r.t. external events must be represented
  • Models depicting info, function, behavior must be partitioned that uncovers detail in a layered approach – models communicate information in a com- pact, manipulable fashion. Partitioning reduces complexity.
  • Analysis process should move from essential information toward implemen- tation detail – Niklaus Wirth referred to this as “stepwise refinement” in mid- 1970s.

Additional guiding principles for requirements engineering – text, section

  • Understand problem before creating models – if you don’t, you may build software that solves wrong problem.
  • Use prototypes to let user know how user interface will work
  • Record origin, reason for each requirement. Establishes traceability back to customer.
  • Use multiple views of requirements – reduces likelihood of missing some- thing importance, having inconsistent requirements.
  • Rank requirements – you may not be able to build everything first time around.
  • Eliminate ambiguity – requirements often specified in natural language, and ambiguity is a consequence. Formal technical reviews can help. 2.3.2. Information Domain 2.3.2.1. All SW built to accept data, transform it, and produce some output. Data domain also includes events (e.g., interrupt from sensor) 2.3.2.2. First operational analysis principle requires examination of info do- main, creation of a data model. 2.3.2.3. Info domain contains 3 views of data:
  • Info content and relationships (data model) - represents individual data and control objects constituting collection of data transformed by SW. S/C telemetry frame, for instance, is a composite object containing:
  • Synchronization code
  • Header identifying transmitting S/C, telemetry mode
  • Engineering data (temperature, pressure, voltage, other meas- urements of S/C subsystems)
  • Science data – observations from zero or more science instru- ments, depending on telemetry mode. Examples are image line from cameras and mapping spectrometers, binned particle counts for dust detectors/energetic particle detectors.

Data objects can be related to other data objects (e.g., paycheck ob- ject is related to employee object, bank, timecard). These relation- ships should be defined during info domain analysis