RequirementsEngineering

Southern Methodist University

CSE 7316 – Chapter 4, Functional Details

Requirements abstraction (Davis)“If a company wishes to let a contract for a large softwaredevelopment project, it must define its needs in a sufficientlyabstract way that a solution is not pre-defined. The requirementsmust be written so that several contractors can bid for the contract,offering, perhaps, different ways of meeting the clientorganisation’s needs. Once a contract has been awarded, thecontractor must write a system definition for the client in moredetail so that the client understands and can validate what thesoftware will do. Both of these documents may be called therequirements document for the system.”

Types of requirement User requirements

Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers

System requirements A structured document setting out detailed

descriptions of the system services. Written as a contract between client and contractor

Software specification A detailed software description which can serve as a

basis for a design or implementation. Written for developers

Definitions and specifications

1. 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

Requirements readers

Client managersSystem end-usersClient engineersContractor managersSystem architects

System end-usersClient engineersSystem architectsSoftware developers

Client engineers (perhaps)System architectsSoftware developers

User requirements

System requirements

Software designspecification

Functional and non-functional requirements Functional requirements

Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.

Non-functional requirements constraints on the services or functions offered by the

system such as timing constraints, constraints on the development process, standards, etc.

Domain requirements Requirements that come from the application domain of

the system and that reflect characteristics of that domain

Functional requirements

Describe functionality or system services Functional user requirements may be high-

level statements of what the system should do but functional system requirements should describe the system services in detail

Examples of functional requirements The user shall be able to search either all of the

initial set of databases or select a subset from it.

The system shall provide appropriate viewers for the user to read documents in the document store.

Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the account’s permanent storage area.

Requirements imprecision

Problems arise when requirements are not precisely stated

Ambiguous requirements may be interpreted in different ways by developers and users

Consider the term ‘appropriate viewers’ User intention - special purpose viewer for each

different document type Developer interpretation - Provide a text viewer

that shows the contents of the document

Requirements completeness and consistency In principle requirements should be both

complete and consistent Complete

They should include descriptions of all facilities required

Consistent There should be no conflicts or contradictions in the

descriptions of the system facilities In practice, it is impossible to produce a complete

and consistent requirements document

Non-functional requirements Define system properties and constraints e.g.

reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc.

Process requirements may also be specified mandating a particular CASE system, programming language or development method

Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless

Non-functional requirement types

Performancerequirements

Spacerequirements

Usabilityrequirements

Efficiencyrequirements

Reliabilityrequirements

Portabilityrequirements

Interoperabilityrequirements

Ethicalrequirements

Legislativerequirements

Implementationrequirements

Standardsrequirements

Deliveryrequirements

Safetyrequirements

Privacyrequirements

Productrequirements

Organizationalrequirements

Externalrequirements

Non-functionalrequirements

Non-functional requirements examples

Product requirement 4.C.8 It shall be possible for all necessary communication

between the APSE and the user to be expressed in the standard Ada character set

Organisational requirement 9.3.2 The system development process and deliverable

documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95

External requirement 7.6.5 The system shall not disclose any personal

information about customers apart from their name and reference number to the operators of the system

Goals and requirements

A system goal The system should be easy to use by

experienced controllers and should be organised in such a way that user errors are minimised.

A verifiable non-functional requirement Experienced controllers shall be able to use all

the system functions after a total of two hours training. After this training, the average number of errors made by experienced users shall not exceed two per day.

Requirements measuresProperty MeasureSpeed Processed transactions/second

User/Event response timeScreen refresh time

Size K BytesNumber of RAM chips

Ease of use Training timeNumber of help frames

Reliability Mean time to failureProbability of unavailabilityRate of failure occurrenceAvailability

Robustness Time to restart after failurePercentage of events causing failureProbability of data corruption on failure

Portability Percentage of target dependent statementsNumber of target systems

Requirements interaction

Conflicts between different non-functional requirements are common in complex systems

Spacecraft system To minimise weight, the number of separate chips

in the system should be minimised To minimise power consumption, lower power

chips should be used However, using low power chips may mean that

more chips have to be used. Which is the most critical requirement?

Domain requirements

Derived from the application domain and describe system characteristics and features that reflect the domain

May be new functional requirements, constraints on existing requirements or define specific computations

If domain requirements are not satisfied, the system may be unworkable

Example domain requirements Library system

there shall be a standard user interface to all databases which shall be based on the Z39.50 standard.

Train protection system The deceleration of the train shall be computed as:

Dtrain = Dcontrol + Dgradient

where Dgradient is 9.81ms2 * compensated gradient/alpha and where the values of 9.81ms2

/alpha are known for different types of train.

Domain requirements problems Understandability

Requirements are expressed in the language of the application domain

This is often not understood by software engineers developing the system

Implicitness Domain specialists understand the area so well

that they do not think of making the domain requirements explicit

Documenting user requirements Should be understandable to system users

who don’t have detailed technical knowledge Use natural language, tables and diagrams some problems with NL

Precision vs lack of clarity Confusion - functional and non-functional

requirements tend to be mixed-up Amalgamation

Editor grid requirement2.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. 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

.6 Grid facilities

.6.1 The editor shall provide a grid facility where a matrix ofhorizontal and vertical lines provide a background to theeditor window. This grid shall be a passive grid where thealignment of entities is the user's responsibility.Rationale: A grid helps the user to create a tidy diagram withwell-spaced entities. Although an active grid, where entities'snap-to' grid lines can be useful, the positioning is imprecise.The user is the best person to decide where entities should bepositioned.

Specification: ECLIPSE/WS/Tools/DE/FS Section 5.6

Detailed user requirement

3.5.1 Adding nodes to a design3.5.1.1 The editor shall provide a facility for users to add nodes of a

specified type to their design.3.5.1.2 The sequence of actions to add a node should be as follows:

1. The user should select the type of node to be added.2. The user should move the cursor to the approximate node position in the

diagram and indicate that the node symbol should be added at thatpoint.

3. The user should then drag the node symbol to its final position.

Rationale: The user is the best person to decide where to position a node on thediagram. This approach gives the user direct control over node typeselection and positioning.

Specification: ECLIPSE/WS/Tools/DE/FS. Section 3.5.1

Specifying system requirements

More detailed specifications of user requirements

NL structures are inadequate to structure system requirements Ambiguity Over-flexibility Lack of modularisation

Alternatives to NL specification

Structured natural language Design description languages - PDL or

psuedocode Graphical notation - UML, SADT Mathematical specifications - Z, Object Z,

VDM, CSP

Structured language specifications

A limited form of natural language may be used to express requirements

This removes some of the problems resulting from ambiguity and flexibility and imposes a degree of uniformity on a specification

Often best supported using a forms-based approach

Form-based node specification

ECLIPSE/Workstation/Tools/DE/FS/3.5.1

Function Add node

Description Adds a node to an existing design. The user selects the type of node, and its position.When added to the design, the node becomes the current selection. The user chooses the node position bymoving the cursor to the area where the node is added.

Inputs Node type, Node position, Design identifier.

Source Node type and Node position are input by the user, Design identifier from the database.

Outputs Design identifier.

Destination The design database. The design is committed to the database on completion of theoperation.

Requires Design graph rooted at input design identifier.

Pre-condition The design is open and displayed on the user's screen.

Post-condition The design is unchanged apart from the addition of a node of the specified typeat the given position.

Side-effects None

Definition: ECLIPSE/Workstation/Tools/DE/RD/3.5.1

Requirements and design

In principle, requirements should state what the system should do and the design should describe how it does this

In practice, requirements and design are inseparable A system architecture may be designed to structure the

requirements The system may inter-operate with other systems that

generate design requirements The use of a specific design may be a domain

requirement

PDL-based requirements definition

Requirements may be defined operationally using a language like a programming language but with more flexibility of expression

Most appropriate in two situations Where an operation is specified as a sequence of

actions and the order is important When hardware and software interfaces have to be

specified

Part of an ATM specification

class ATM {// declarations herepublic static void main (String args[]) throws InvalidCard {

try {thisCard.read () ; // may throw InvalidCard exceptionpin = KeyPad.readPin () ; attempts = 1 ;while ( !thisCard.pin.equals (pin) & attempts < 4 )

{ pin = KeyPad.readPin () ; attempts = attempts + 1 ;}if (!thisCard.pin.equals (pin))

throw new InvalidCard ("Bad PIN");thisBalance = thisCard.getBalance () ;do { Screen.prompt (" Please select a service ") ;

service = Screen.touchKey () ;switch (service) {

case Services.withdrawalWithReceipt:receiptRequired = true ;

PDL disadvantages

PDL may not be sufficiently expressive to express the system functionality in an understandable way

Notation is only understandable to people with programming language knowledge

The requirement may be taken as a design specification rather than a model to help understand the system

Interface specification

Most systems must operate with other systems and the operating interfaces must be specified as part of the requirements

Three types of interface may have to be defined Procedural interfaces Data structures that are exchanged Data representations

Formal notations are an effective technique for interface specification

PDL interface description

interface PrintServer {

// defines an abstract printer server// requires: interface Printer, interface PrintDoc// provides: initialize, print, displayPrintQueue, cancelPrintJob, switchPrinter

void initialize ( Printer p ) ;void print ( Printer p, PrintDoc d ) ;void displayPrintQueue ( Printer p ) ;void cancelPrintJob (Printer p, PrintDoc d) ;void switchPrinter (Printer p1, Printer p2, PrintDoc d) ;

} //PrintServer

Users of a requirements document

Use the requirements todevelop validation tests forthe system

Use the requirementsdocument to plan a bid forthe system and to plan thesystem development process

Use the requirements tounderstand what system is tobe developed

System testengineers

Managers

System engineers

Specify the requirements andread them to check that theymeet their needs. Theyspecify changes to therequirements

System customers

Use the requirements to helpunderstand the system andthe relationships between itsparts

Systemmaintenance

engineers

Functional details

Focus has been on identifying functional details

More precision needed now Good intermediate work products UML based

Complex and simple functions

Makes sense to only describe semi complex functions

Must be able to distinguish non-obvious from obvious to save time

We have to live with tacit requirements

Tables and decision tables

Good for non-trivial sets of rules existing in the domain When is a deposit needed When is a supervisor signature needed When is a discount given

Can describe in programming language form but a table is better

Pros and cons

Good for describing business rules Customer can V & V Can be turned easily into program

Rules expressed as programs with loops or recursion are not suitable

State diagrams

Describes how a certain entity changes state as a result of various events

Can model the life cycle of any entity or group of entities with a state diagram

Use only for entities with complex behavior and several states

Pros and cons

Verification; state diagrams are an excellent basis for development and testing

Validation; huge state diagrams can get to be messy

Hard to distinguish from a DFD or activity diagram

State transition matrices

Another way to show state transitions Forces us to look at every combination of

state and event Good for resolving hard problems

Pros and cons

Good for checking that all situations and features have been covered

Can easily be converted into a program Can become too large and sparsely

populated (cells contain “not possible”)

Activity diagrams

Kind of like a traditional flow chart Expanded to show object flows and

concurrent flows Combines flow chart and DFD Swim lanes for actors

Pros

Good for designing new activities into the domain

Specifying communication between technical components

Outlining the internal structure of large programs

Validation – most customers can read and understand them

Cons

Poor at describing the actual data communication between actors Combine with data expressions

Take a lot of space Flow chart may be messy and unstructured

from a programming point of view

Class diagram

Static class diagram is an extension to the E/R model Each class stores behavior as well as data

UML allows more precision than the crows feet representation

Relationship is called an association

Pros

Widely used, must know about them Class diagrams are useful in designing the

inner workings of the product but be careful with business objects

Cons

In business applications class modeling with operations is not suitable for requirements

Use it as if it were a data model and gloss over the operations

Sequence diagrams

Show how objects communicate by means of messages

Shows sequences graphically with time running down the diagram

An event is the message where the initiative starts

Message is some data sent from a sender to a receiver

Pros and cons

Widely used and designer should know about them

Correspond closely to use cases using a graphical instead of textual description

Can be used as design level requirements for technical interfaces as well as user interfaces

Models: Analysis/DesignModels: Analysis/DesignAdditional DiagramsAdditional Diagrams

Sequence Diagrams

Activity Diagrams

Decision Tree

Models: Textual Models: Textual ScenarioScenarioScenarios

You can write a textual specification of a scenario

A scenario for the Change Machine State use case appears below

1. The Operator informs a Machine that the Machine should changeits state to “off”

2. The Machine sets its state to the new state

3. The Machine logs the state change with the Log

4. The Log creates the appropriate Log Entry(The Machine was not previously in the running state, so thesuccessor machines need not be informed)

ScenariosYou can write a textual specification of a scenario

A scenario for the Change Machine State use case appears below

1. The Operator informs a Machine that the Machine should changeits state to “off”

2. The Machine sets its state to the new state

3. The Machine logs the state change with the Log

4. The Log creates the appropriate Log Entry(The Machine was not previously in the running state, so thesuccessor machines need not be informed)

Models: Sequence Models: Sequence DiagramDiagram

Models: Sequence Models: Sequence DiagramDiagram

Developing Sequence DiagramsYou can “walk through” your use cases to develop sequence diagrams

• You first identify all of the scenarios for each use caseA scenario is one execution path through a use case

• You then draw a sequence diagram for each scenarioA sequence diagram describes how objects interact in one scenario

(As you do this, you might discover additional features your class diagram must have)

Developing Sequence DiagramsYou can “walk through” your use cases to develop sequence diagrams

• You first identify all of the scenarios for each use caseA scenario is one execution path through a use case

• You then draw a sequence diagram for each scenarioA sequence diagram describes how objects interact in one scenario

(As you do this, you might discover additional features your class diagram must have)

Models: Sequence Diagram - Models: Sequence Diagram - Example ElevatorExample Elevator

A Sequence diagram shows the explicitsequence of messages suitable formodeling a real-time system.

Models: Activity DiagramModels: Activity Diagram

A Use case presents a static view of system functionality

Activity diagrams depict a workflow view of activities

An activity diagram “flowcharts” the steps in the use case

Models: Activity Diagram Models: Activity Diagram Example ElevatorExample Elevator

Floor Button Pressed Controller Detects Floor Button Pressed

Elevator Moves to Floor

Elevator Door Open

Passenger GetsIn

No Passengar Presses Floor ButtonYes

Elevator Door Closes

Elevator Moves to Selected Floor

Elevator Door Opens

Passenger GetsOut

Yes

No

Models: Activity Diagram Models: Activity Diagram ExampleExample

FindBeverage

Put Coffeein Filter

Put Filterin Machine

Turn OnMachine

BrewCoffee

PourCoffee

Add Waterto Reservoir

GetCups

Get Canof Cola

DrinkBeverage

[no cola][no coffee]

[found cola][found coffee]

^coffeePot.TurnOn

light goes out

Start

Activity

JoinEnd

Branch

Guard

Merge

Fork

UML Distilled, Fowler, Martin and Kendall Scott, Addison-Wesley,1997, page 130.

UML Distilled, Fowler, Martin and Kendall Scott, Addison-Wesley,1997, page 130.

Models: SA Decision TreeModels: SA Decision Tree

is userAuthorized?

is userAuthorized?

is chemical

hazardous?

is chemical

hazardous?

is chemicalavailable?

is chemicalavailable?

is usertrained?

is usertrained?

rejectrequest

rejectrequest accept

request

acceptrequest

acceptrequest

acceptrequest

rejectrequest

rejectrequest

rejectrequest

rejectrequest

nononono

nono

nono

yesyes

yesyes

yesyes

yesyes

User interfaces with state machines

“Constructing the User Interface with State Charts” by Ian HorrocksPublisher: Addison-Wesley Professional; 1st edition (January 17, 1999) ASIN: 0201342782

Event-driven software

Large systems usually have control passed from one subroutine to another

User interface software is event driven Objects programmed to respond to events using

event handlers Developer cannot anticipate order or events

Top down control

Event-Action Paradigm

An event supplied by a user determines the sequence of actions that is executed by the software

Example; word processor; user event supplied to one object can affect the state of another

Example; saving a document; when an event is supplied to a user interface object, actions executed can vary

Event-Action Paradigm

Another example; business application used to display data about customers; data displayed in a user interface object can affect the state and behavior of other user interface objects

Bottom up approach

Because of event-action paradigm, most UI SW is constructed bottom up

Event handlers built up gradually Needs information shared between objects

Calculator application

Problems with this approach

No abstract view of software Event handlers using global variables SW is not object oriented Contexts are not explicit Difficult to get SW to work correctly Difficult to enhance software

User Interface Control Model (UCM) UI objects must be coordinated to work

together as a whole Control should be centralized Event handlers forward user events to the

right objects Control objects send messages to model

objects (store long term info)

Event handlers in a UI app

UCM architecture

Tabbing between objects

Issues with UCM

Creating control objects that are easy to understand requires a powerful design notation

Problem is that each control object will be constructed from a set of global variables that can be accessed and updated

Event-state-action paradigm

Events that a user supplies cause the software to move from one state to another and the state defines the set of possible events that a user can supply

States not made explicit in the UI code State based approach to UI design

Event driven UI

Design notation for control layer objects Control layer philosophy is that UI as a whole

moves from one state to another

CD player UI

Writing specs

Forces developers to make assumptions about many aspects of a UI behavior

Others believe development of prototypes should replace natural language specs

Another approach is to produce a model

State diagram

Table form (STD matrix)

Table form (contd)

Table form

UCM architecture for CD player

Public methods of CD player

Use of state machines

Application like the CD player is controlling an electrical device

State machine controlling the UI objects and not the CD player itself

Can represent state machines in many ways

CD player UI

UCM architecture for CD player

Basic STD

More accurate model of CD player

STD capturing extra requirements

Actions and state transitions

Extended STD

Extended behavior

More complicated STD

Object behavior

More behavior

Extra behavior

FSM and the control of UI objects FSM cannot model UI objects without being

extended # states increases rapidly with only a modest

rise in system complexity Many duplicated states and events STD can be large and difficult to read STD are not scalable

Statecharts

Harel proposed extension to STD called state charts

Rich and expressive notation that allows complex systems to be specified concisely and at different levels of abstraction

Used widely

CD player example

Two high level states the CD player can be in CD not in machine CD in machine

Notation like STD with a few obvious differences

High level CD behavior

More substates

Closing the CD drawer

CD stopped and paused

Adding “Paused” behavior

History mechanism

Conclusion

Natural language spec of CD player composed of many basic fragments of information

Statecharts better than STDs in UI spec # states in a statechart rises in proportion to the complexity

of the system Statecharts avoid duplication Hierarchical structure

Statecharts; the behavioral language for user interfaces

Data Flow Models

Data-flow models

Show the processing steps as data flows through a system

Intrinsic part of many analysis methods Simple and intuitive notation that customers

can understand Show end-to-end processing of data

Order processing DFD

Completeorder form

Orderdetails +

blankorder form

Valida teorder

Recordorder

Send tosupplier

Adjustavailablebudget

Budgetfile

Ordersfile

Completedorder form

Signedorder form

Signedorder form

Checked andsigned order

+ ordernotification

Orderamount

+ accountdetails

Signedorder form

Orderdetails

Data-flow diagrams

May be used to show processing at different levels of abstraction from fairly abstract to fairly detailed

May also be used for architectural description showing data interchange between the sub-systems making up the system

Not a good way to describe system interfaces

Equipment procurement DFD

Get costestimates

Acceptdelivery ofequipment

Checkdelivered

items

Validatespecification

Specifyequipmentrequired

Choosesupplier

Placeequipment

order

Installequipment

Findsuppliers

Supplierdatabase

Acceptdelivered

equipment

Equipmentdatabase

Equipmentspec.

Checkedspec.

Deliverynote

Deliverynote

Ordernotification

Installationinstructions

Installationacceptance

Equipmentdetails

Checked andsigned order form

Orderdetails +

Blank orderform

Spec. +supplier +estimate

SupplierlistEquipment

spec.

Software Engineering Theory and PracticeShari Lawrence Pfleeger and Joanne M Atlee