csc480 software engineering lecture 7 september 16, 2002
DESCRIPTION
Requirement Analysis Requirements generally express what an application is meant to do (i.e., explore the problem domain) Generally, they don’t try to express how to accomplish these functions (i.e., explore the solution domain)TRANSCRIPT
CSC480 Software Engineering
Lecture 7September 16, 2002
Topics
User & system requirements Functional & non-functional requirements Ways to express requirements
Requirement Analysis
Requirements generally express what an application is meant to do (i.e., explore the problem domain)Generally, they don’t try to express how to
accomplish these functions (i.e., explore the solution domain)
What Is a Requirement?
The following statement (Y) sounds like oneThe system should allow the user to access
his account balance And what is not? See the following
statement (N)Customers’ account balances will be stored in
a table called “balance” in an Access database
Types of Requirement
Targeted audienceC-requirements – targeted primarily for
customers, in a non-techie formatD-requirements – targeted primarily for
developers, with detailed descriptions Levels of description
Requirements ReadersClient managersSystem end-usersClient engineersContractor managersSystem architects
System end-usersClient engineersSystem architectsSoftware developers
Client engineers (perhaps)System architectsSoftware developers
User requirements
System requirements
Software designspecification
Types of Requirement
Levels of descriptionAs the basis for a bid for a contract
A high-level abstract statement of a service or of a system constraint
Open for interpretation As the contract itself
A detailed mathematical functional specification must be defined in detail
Definitions and Specifications1. The software must provide a means of representing and1. accessing external files created by other tools.
1.1 The user should be provided with facilities to define the type of1.2 external files.1.2 Each external file type may have an associated tool which may be1.2 applied to the file.1.3 Each external file type may be represented as a specific icon on1.2 the user’s display.1.4 Facilities should be provided for the icon representing an1.2 external file type to be defined by the user.1.5 When a user selects an icon representing an external file, the1.2 effect of that selection is to apply the tool associated with the type of1.2 the external file to the file represented by the selected icon.
Requirements definition
Requirements specification
Why Req’ts Must Be Written?
Developers tend to believe that the source code express all the requirements
But without requirements, the team cannotKnow what goals it is trying to accomplish Inspect and test its work properlyTrack its productivityGather data for estimations in future projectsSatisfy its customer
Each Requirement Must Be expressed properly, (clarity) made easily accessible, numbered, (traceability) accompanied by tests that verify it, (testability) provided for in the design, (traceability) accounted for by code, (traceability) tested in isolation, tested in concert with other requirements, and validated by testing after the application has been built.
IEEE 830-1993 SRS Table of Contents1. Introduction 1.1. Purpose 1.2. Scope 1.3. Definitions, acronyms & abbreviations 1.4. References 1.5. Overview2. Overall description 2.1. Product perspective 2.1.1. System interfaces 2.1.2. User interfaces 2.1.3. Hardware interfaces 2.1.4. Software interfaces 2.1.5. Communications interfaces
2.1.6. Memory constraints 2.1.7. Operations 2.1.8. Site adaptation requirements 2.2. Product functions 2.3. User characteristics 2.4. Constraints 2.5. Assumptions and dependencies 2.6. Apportioning of requirements3. Specific requirements -- see chapter four --4. Supporting information-- see chapter four --
Functional v.s. Non-Functional Functional requirements
Specify services must be provided Non-functional requirements
Performance – speed, throughput Reliability and availability Error handling Interfaces (with user or other applications) Constraints – tool & language, standards, platform, etc
Inverse requirements – what the app doesn’t do
Performancerequirements
Spacerequirements
Usabilityrequirements
Efficiencyrequirements
Reliabilityrequirements
Portabilityrequirements
Interoperabilityrequirements
Ethicalrequirements
Legislativerequirements
Implementationrequirements
Standardsrequirements
Deliveryrequirements
Safetyrequirements
Privacyrequirements
Productrequirements
Organizationalrequirements
Externalrequirements
Non-functionalrequirements
Non-functional requirement types
Desired Attributes for SRD
Completeness Consistency Nonambiguity Each requirement should be testable Each requirement should be numbered
and the number should be used in tracing the fulfillment in design through testing
Problems w/ Natural Language
Lack of clarity Precision is difficult without making the document
difficult to read Requirements confusion
Functional and non-functional requirements tend to be mixed-up
Requirements amalgamation Several different requirements may be expressed
together
Editor Grid Requirement
2.6 Grid facilities To assist in the positioning of entities on a diagram, the user may turn on a grid in either centimetres or inches, via an option on the control panel. Initially, the grid is off. The grid may be turned on and off at any time during an editing session and can be toggled between inches and centimetres at any time. A grid option will be provided on the reduce-to-fit view but the number of grid lines shown will be reduced to avoid filling the smaller diagram with grid lines.
Requirement problems
Grid requirement mixes three different kinds of requirement Conceptual functional requirement (the
need for a grid) Non-functional requirement (grid units) Non-functional UI requirement (grid
switching)
Structured presentation
2.6 Grid facilities2.6.1 The editor shall provide a grid facility where a
matrix of horizontal and vertical lines provide abackground to the editor window. T his grid shall bea p assive grid where the alignment of entities is theuser's responsibility.Rationale: A grid helps the user to create a tidydiagram with well-spaced entities. Although an activegrid, where entities 'snap-to' grid lines can be useful,the positioning is imprecise. The user is the best personto decide where entities should be positioned.
Specification: ECLIPSE/WS/Tools/DE/FS Section 5.6
Using Diagrams – informal
Story-boarding Informal diagrams with icons and links
Mock-up screensUse simple GUI screens/pages to illustrate
navigation among them
Using Diagrams – formal
Use case diagramsActors-system interactions
Data flow diagrams (DFD)Data traffic among processing units
State-transition diagramsThe logics of transitioning from one state to
another
Initialize Use Case for Encounter
Encounterforeign
character
player
designer Set rules
actors Encounter
Travel toadjacent
area
Initialize1. System displays player’s main character in the dressing room.2. System displays a window for setting his character's qualities. 3. Player allocates the qualities of his main character. 4. Player chooses an exit from the dressing room.5. System moves player’s main character into the area on the other side of the exit.
InitializeUse case
Use case details
Engage Foreign Character Use Case
player
designer
InitializeUse case
Encounter
Travel toadjacent
area
Set rules
Engage Foreign Character1. System displays the foreign character in the same area as the player’s.2. System exchanges quality values between the two characters.3. System displays the results of the engagement. 4. System displays player’s character in a random area.
Engageforeign
character
Use case details
Data Flow Diagram: Explanation of Symbols
Account #& deposit
Get deposit
Check deposit
Processingelement
Data typeDirectionof data flow
Data Flow Diagram: Explanation of Symbols
Account #& deposit
balancequery
User
accountdatabase
accountdata
Get deposit
Create account
summary
Check deposit
Printer
Input
Output
Processingelement
Data typeDirectionof data flow
Data store
…...
Partial Encounter State-Transition Diagram
Setting up Preparing
Waiting
Complete setup
Foreign character
enters area
Engaging
Player clicks
qualities menu
Using Conditions in State-Transition Diagrams
Engaging
Waiting
[foreign character absent]
[foreign character present]
Player moves to adjacent
area
eventcondition
condition
state
state