ics 52: introduction to software engineeringtaylor/ics_52_fq02/ics52fq02-02.pdf · udelivering a...
TRANSCRIPT
![Page 1: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/1.jpg)
University of California, Irvine
ICS 52: Introduction to SoftwareEngineering
Fall Quarter 2002Professor Richard N. Taylor
Lecture NotesWeek 2: Principles and Requirements Engineering
http://www.ics.uci.edu/~taylor/ICS_52_FQ02/syllabus.htmlCopyright 2002, Richard N. Taylor. Duplication of course
material for any commercial purpose without written permission is prohibited.
![Page 2: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/2.jpg)
University of California, Irvine
Recurring, Fundamental Principlesu Rigor and formalityu Separation of concerns
– Modularity– Abstraction
u Anticipation of changeu Generalityu Incrementality
These principles apply to all aspects of software engineering
![Page 3: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/3.jpg)
University of California, Irvine
Rigor and Formalityu Creativity often leads to imprecision and inaccuracy
– Software development is a creative process– Software development can tolerate neither imprecision nor inaccuracy
u Rigor helps to…– …produce more reliable products– …control cost– …increase confidentiality in products
u Formality is “rigor -- mathematically sound”– Often used for mission critical systems
![Page 4: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/4.jpg)
University of California, Irvine
Separation of Concernsu Trying to do too many things at the same time often leads to mistakes
– Software development is comprised of many parallel tasks, goals, andresponsibilities
– Software development cannot tolerate mistakesu Separation of concerns helps to…
– …divide a problem into parts that can be dealt with separately– …create an understanding of how the parts depend on/relate to each
other
![Page 5: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/5.jpg)
University of California, Irvine
Example Dimensions of Separationu Time
– Requirements, design, implementation, testing, …– Dial, receive confirmation, connect, talk, …
u Qualities– Efficiency and user friendliness– Correctness and portability
u Views– Data flow and control flow– Management and development
![Page 6: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/6.jpg)
University of California, Irvine
Modularityu Separation into individual, physical parts
– Decomposability» Divide and conquer
– Composability» Component assembly» Reuse
– Understanding» Localization
u Special case of separation of concerns– Divide and conquer “horizontally”– “Brick”-effect
![Page 7: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/7.jpg)
University of California, Irvine
Modularity
Big
SmallSmall SmallSmall
![Page 8: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/8.jpg)
University of California, Irvine
Abstractionu Separation into individual, logical parts
– Relevant versus irrelevant details» Use relevant details to solve task at hand» Ignore irrelevant details
u Special case of separation of concerns– Divide and conquer “vertically”– “Iceberg”-effect
![Page 9: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/9.jpg)
University of California, Irvine
Abstraction
Big
Abstraction
Details
![Page 10: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/10.jpg)
University of California, Irvine
Anticipation of Changeu Not anticipating change often leads to high cost and unmanageable software
– Software development deals with inherently changing requirements– Software development can tolerate neither high cost nor unmanageable
softwareu Anticipation of change helps to…
– …create a software infrastructure that absorbs changes easily– …enhance reusability of components– …control cost in the long run
![Page 11: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/11.jpg)
University of California, Irvine
Generality
u Not generalizing often leads to continuous redevelopment of similarsolutions– Software development involves building many similar kinds of
software (components)– Software development cannot tolerate building the same thing over
and over againu Generality leads to…
– …increased reusability– …increased reliability– …faster development– …reduced cost
![Page 12: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/12.jpg)
University of California, Irvine
Incrementalityu Delivering a large product as a whole, and in one shot, often leads to
dissatisfaction and a product that is “not quite right”– Software development typically delivers one final product– Software development cannot tolerate a product that is not quite right or
dissatisfies the customeru Incrementality leads to…
– …the development of better products– …early identification of problems– …an increase in customer satisfaction
» Active involvement of customer
![Page 13: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/13.jpg)
University of California, Irvine
Cohesion
VERSUS
![Page 14: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/14.jpg)
University of California, Irvine
Coupling
VERSUS
![Page 15: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/15.jpg)
University of California, Irvine
Provided Interface
ImplementationRequired Interface
A Good Separation of Concerns, 1
Abstraction through the use of provided/required interfacesModularity through the use of componentsLow coupling through the use of hierarchiesHigh cohesion through the use of coherent implementations
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
![Page 16: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/16.jpg)
University of California, Irvine
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
A Good Separation of Concerns, 2
Abstraction through the use of provided/required interfacesModularity through the use of componentsLow coupling through the use of a central “blackboard”High cohesion through the use of coherent implementations
Implementation
Provided Interface
![Page 17: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/17.jpg)
University of California, Irvine
Benefit 1: Anticipating Change
Separating concerns anticipates change
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Implementation
Provided Interface
![Page 18: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/18.jpg)
University of California, Irvine
Benefit 1: Anticipating Change
Separating concerns anticipates change
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Implementation
Provided Interface
![Page 19: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/19.jpg)
University of California, Irvine
Benefit 2: Promoting Generality
Separating concerns promotes generality
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
![Page 20: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/20.jpg)
University of California, Irvine
Benefit 3: Facilitating Incrementality
Separating concerns facilitates incrementality
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
Implementation
Provided Interface
Provided Interface
ImplementationRequired Interface
Provided Interface
ImplementationRequired Interface
![Page 21: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/21.jpg)
University of California, Irvine
Recurring, Fundamental Principlesu Rigor and formalityu Separation of concerns
– Modularity– Abstraction
u Anticipation of changeu Generalityu Incrementality
These principles apply to all aspects of software engineering
![Page 22: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/22.jpg)
University of California, Irvine
ICS 52 Life CycleRequirements
phaseVerify
DesignphaseVerify
ImplementationphaseTest
TestingphaseVerify
![Page 23: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/23.jpg)
University of California, Irvine
Requirements Phase
uTerminology–Requirements analysis/engineering
»Activity of unearthing a customer’s needs–Requirements specification
»Document describing a customer’s needs
![Page 24: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/24.jpg)
University of California, Irvine
Requirements Analysisu System engineering versus software engineering
– What role does software play within the full solution?– Trend: software is everywhere
u Contract model versus participatory design– Contract: carefully specify requirements, then contract out the
development– Participatory: customers, users, and software development staff work
together throughout the life cycle
![Page 25: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/25.jpg)
University of California, Irvine
Techniques for Requirements Analysisu Interview customeru Create use cases/scenariosu Prototype solutionsu Observe customeru Identify important objects/roles/functionsu Perform researchu Construct glossariesu Question yourself
Use the principles
![Page 26: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/26.jpg)
University of California, Irvine
Requirements Specificationu Serves as the fundamental reference point between customer and software
produceru Defines capabilities to be provided without saying how they should be
provided– Defines the “what”– Does not define the “how”
u Defines environmental requirements on the software to guide theimplementers– Platforms– Implementation language(s)
u Defines software qualities
![Page 27: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/27.jpg)
University of California, Irvine
Requirements Specification (the Document)u Purpose
– Serve as the fundamental reference point between builder and buyer/"consumer "(contract)
– Define capabilities to be provided, without saying how they should be provided– Define constraints on the software
» e.g. performance, platforms, languageu Characteristics
– Unambiguous» Requires precise, well-defined notations
– Complete: any system that satisfies it is acceptable– Consistent
» There should be no conflicts or contradictions in the descriptions of the system facilities– Verifiable (testable)– No implementation bias (external properties only)
» "One model, many realizations"
![Page 28: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/28.jpg)
Users of arequirementsdocument
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5
![Page 29: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/29.jpg)
University of California, Irvine
Lifecycle Considerations
u Serve as basis for future contractsu Reduce future modification costs
– Identify items likely to change– Identify fundamental assumptions
u Structure document to make future changes easy– e.g. have a single location where all concepts are defined
![Page 30: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/30.jpg)
University of California, Irvine
Recurring, Fundamental Principlesu Rigor and formalityu Separation of concerns
– Modularity– Abstraction
u Anticipation of changeu Generalityu Incrementality
These principles apply to all aspects of software engineering
![Page 31: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/31.jpg)
University of California, Irvine
Requirements Volatility
Source: David Alex Lamb, Software Engineering, Planning for ChangePrentice Hall, 1988
![Page 32: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/32.jpg)
University of California, Irvine
Structure of a Requirements Specificationu Introductionu Executive summaryu Application contextu Functional requirementsu Environmental requirementsu Software qualitiesu Other requirementsu Time scheduleu Potential risksu Future changesu Glossaryu Reference documents
![Page 33: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/33.jpg)
University of California, Irvine
Content of a Requirements Specificationu Application context
– Describe the situations in which the software will be used. How will thesituation change as a result of introducing the software system?
– Identify all things (objects, processes, other software, hardware, people)that the system may, or will, affect.
– Develop an abstraction for each of those things, characterizing theirproperties/behavior which are relevant to the software system. ("Worldmodel.")
– How might this context change?u Functional requirements ("features")
– Identify all concepts (objects) that the system provides to the users.– Develop an abstraction for each of those concepts, characterizing their
properties and functions which are relevant to the user.» What is the system supposed to do?» What is supposed to happen when something goes wrong?
![Page 34: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/34.jpg)
University of California, Irvine
Contents of aRequirements Specification, cont..
u Performance requirements: speed, space
u Environmental requirements: platform, language, ...
u Subsets/supersets
u Expected changes and fundamental assumptions
u Definitions; reference documents
![Page 35: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/35.jpg)
University of California, Irvine
Non-functional requirement types
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5
![Page 36: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/36.jpg)
University of California, Irvine
World Model (OOA) versus Simple Input/OutputCharacterizations as Reqt.s Specs
u The application context may change because of extrinsic factorsu The software system modifies the usage context
u I/O is only meaningful in a specific contextu "Input" and "output" may not be simple concepts
– Cruise control systems: many sensors, complex conditions, and timingconstraints only understandable in the application context
![Page 37: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/37.jpg)
University of California, Irvine
Techniques for Requirements Analysisu Conduct interviewsu Build and evaluate prototypesu Construct glossariesu Separate concernsu Focus on structure
– Abstraction and hierarchical decompositionu Use precise notation (be careful with diagrams!)u Ask yourself:
– Is it testable? Complete? Consistent?
![Page 38: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/38.jpg)
University of California, Irvine
Canonical Diagram for Requirements Objects
Object Name
Description/Attributes
Operations it can be asked to perform• op1• op2• ...
Requests made of other objects
Note: this will not be the appropriate notation for all application contexts!
Nested objects (hierarchical structure)
![Page 39: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/39.jpg)
A place where mail can be delivered.Name, Title, Street, City, State, ZipCode.Operations: (1) change any of the specifiedattributes to have a particular value.(2) read any or all of the attributes(3) create/delete address
Mailing Address
A list of Mailing_Address objects.Name (of list)Operations: (1) Add Mailing_Address to list(2) Delete Mailing_Address from list(3) Sort list(4) “Print” list
Mailing List
Note: What about querying the list tosee if a particular address --- or part ofone -- is already a member?
An indexed set of places where chunks of ASCII data can be stored. Number of indices, size of data currently stored in each indexOperations: (1) Fetch data at index(2) Store data at index
Storage
Supports manipulation of multiple mailing lists. Operations: (1) Union of two lists(2) Intersection of two lists(3) Subtraction of one list from another
Mailing List Set Ops
What the human user interacts with inorder to manipulate or obtain any info.Attributes: media and modesOperations: (1) Login (authenticate user)(2) Parse and execute command
User Interface
Note: requests between objects not shown. Neither the applicationcontext nor the customer imposes any constraints on how theseobjects may interact.
Note: are the values to the “puts” or receivedfrom the “gets” strings? Only strings?
Mailing List Manager
![Page 40: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/40.jpg)
A list of Mailing_Address objects.Name (of list)Operations: (1) Add Mailing_Address to list(2) Delete Mailing_Address from list(3) Sort list(4) “Print” list(5) Combine (union) two lists(6) Intersection of two lists --> list(7) List2 = List1 - List0(8) Store list(9) Retrieve list
Mailing List
An indexed set of places where chunks of ASCII data can be stored. Number of indices, size of data currently stored in each indexOperations: (1) Fetch data at index(2) Store data at index
Storage
What the human user interacts with inorder to manipulate or obtain any info.Attributes: media and modesOperations: (1) Login (authenticate user)(2) Parse and execute command
User Interface
Mailing List Manager, Take 2
A place where mail can be delivered.Name, Title, Street, City, State, ZipCode.Operations: (1) change any of the specifiedattributes to have a particular value.(2) read any or all of the attributes(3) create/delete address
Mailing Address
Is this better, or worse?
![Page 41: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/41.jpg)
Cruise Control System
Controls vehicle throttle
Operations: (1) Apply throttle x%(2) Get current throttle setting?(3) Throttle pedal depressed?
Throttle Controller
Determines state of braking system
Operations: (1) Brake pedal depressed?(2) ABS active?
Brake Controller
Determine vehicle speedOperations: (1) Get speed
Vehicle Speed
Determine rate of rotation of front axleOperations: (1) Get rotation rate
Front axle sensor
Operations:
Cruise Controller
Determines state of CC buttons and leversunder driver’s controlOperations: (1) Get button state 1(2) Get button state 2(3)...
Cruise Control Interface
Determine rate of rotation of rear axleOperations: (1) Get rotation rate(2) Get rotation direction
Rear axle Sensor
Notes:
1. No transmission status?
2. CC doesn’t access axlesensors directly
![Page 42: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/42.jpg)
University of California, Irvine
Different Circumstances,Different Techniques
uFinite state machines–telephony examples–http://www.uclan.ac.uk/facs/destech/compute/s
taff/casey/integ/mscfsm.htmuNumerical systems
–e.g. matrix inversion package
![Page 43: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/43.jpg)
University of California, Irvine
Acceptance Test Planu An operational way of determining consistency between the requirements
specification and the delivered systemu If the system passes the tests demanded by this plan, then the buyer has no
(legal) basis for complaintu Develop a plan for conducting test to examine
– Functional properties– Performance properties– Adherence to constraints– Subsets
u Representative technique: Property/test matrix: for each test case, whatproperties/behaviors will be demonstrated?
![Page 44: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/44.jpg)
University of California, Irvine
V-Model ofDevelopment and Testing ActivitiesSpecify Requirements
Requirements Review
Develop System/Acceptance Tests
Design Review
Develop Integration Tests
Develop Unit Tests
Code Review Unit Tests Review/Audit
Integration Tests Review/Audit
System/Acceptance Tests Review
Execute System Tests
Design
Code Execute Unit Tests
Execute Integration Tests
![Page 45: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/45.jpg)
University of California, Irvine
Incremental Development of Tests
uAcceptance test plan (and tests): develop duringrequirements analysis
uIntegration test plan (and test): develop duringsystem architecture and detailed designspecification
uUnit test plan (and tests): develop duringimplementation
![Page 46: ICS 52: Introduction to Software Engineeringtaylor/ICS_52_FQ02/ICS52FQ02-02.pdf · uDelivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product](https://reader033.vdocuments.mx/reader033/viewer/2022042313/5edc7bc5ad6a402d666728b5/html5/thumbnails/46.jpg)
University of California, Irvine
ICS 52 Requirements Analysis Exercise
uDevelop a requirements specification andacceptance test plan for the class project
uTAs are the customer