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