requirements engineering (1) re is the process of establishing the services that the customer...

Requirements engineering (1)

RE is the process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.The requirements themselves are the descriptions of the system services (functions) and constraints that are generated during the requirements engineering process.

RE should focus on the WHAT and not on the HOW.

The critical issue is to identify and represent the functions that the user requires and NOT how they might be implemented

In practise, especially, with iterative SD methods, separating RE and design is not fully possible

In other words, what does the customer want the system to do and how does the customer want the system to behave !


Feasability studies

Requirements elicitation and analysis

Requirements validation

Requirements management

Requirements engineering involves:-


Feasibilitystudy

Requirementselicitation and

analysisRequirementsspecification

Requirementsvalidation

Feasibilityreport

Systemmodels

User and systemrequirements

Requirementsdocument

From: Sommerville (Software Engineering)


Requirementsspecification

Requirementsvalidation

Requirementselicitation

System requirementsspecification and

modeling

Systemrequirements

elicitation

User requirementsspecification

Userrequirements

elicitation

Business requirementsspecification

Prototyping

Feasibilitystudy

Reviews

System requirementsdocument

From: Sommerville (Software Engineering)


A requirement description may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification.

This is inevitable as requirements may serve a dual function:

it may be the basis for dialogue with the clients/users and therefore must be understandable by them

It may serve as a specification on which software design & implementation will be based

Often called “user requirement”

Often called “system requirement”


Example of user requirement (A library system where the user may need to access and view files of many different types (formats)):

1. The system must provide a means of accessing and representing external files created by various tools.

Example of system requirement:

1.1 The user should be provided with facilities to define the types of external files

1.2 Each external file type should have an associated tool which can be applied to the file

1.3 Each external file type should be represented as a separate specific icon on user’s display monitor

1.4 A facility should be provided for the icon representing a specific file type to be defined by the user

1.5 When a user selects an icon representing a specific file, the effect of this should be to apply the tool associated with this type of external file to the file represented by the selected icon

User requirements

System requirements

Client managers

System users

Contractor managers (if involved)

System engineers

End-users

System designers

Software developers

Read by

Read by



Types of Requirements:

Functional requirementsStatements 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 requirementsconstraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. (e.g response time, security, memory/storage constraints)

Domain requirementsRequirements that come from the application domain of the system and that reflect characteristics of that domain. (e.g. a requirement to use the terminology of the application area)


Examples of Requirements:

Functional requirementThe system should generate a list of students (sorted by Student ID) takinga particular module if the user submits the appropriate module code.

Non-functional requirementsThe system should not require more than 30 secs to start-upThe system should be able to search the database and retrieve details of A specific student in no more than 1.5 sec.The system should provide security for all electronic money transfers

Domain requirementsA commodity broking system should identify all commodities by the codes used on the International Commodity Exchange and units of weight measurements Should beas used by the ICE for each particular commodity


Requirements should be:

Complete

Consistent

Description of all facilities required

No conflict or contradictions in the description of system facilities

In practice, this is very difficult to achieve


Requirements may interact!

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

Take a system to control a spacecraft -

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?

but

Requirements may interact!

A more commonplace example:

In a company trading goods -

SALES may want x number of all product items to be held in stock

WAREHOUSE may request that no more than 1 item should be held in stock for any product larger than 0.5 m3

FINANCE may require that the total value of all stock held should not exceed€250,000

Conflicting requirements can reflect political/territorial battles within an organisation. Resolutions are rarely simple and run a real risk of introducing a degree of compromise into systems which will make them significantly sub-optimal.


but

while


Requirements Gathering

Interviewing

Observation of work flows

Examination of previous reports

Recording a user’s “story” (see Agile)

Questionnaires

Structured (closed) orunstructured (open)

Examination of forms used by organisation

Interviewer should not havepreconceived ideas – no prompting interviewee with required answer

and/or

No interrogation or implied

threats!

Write interview report and confirm with interviewee

More accurate than interviews

Probably low % response

Useful when opinions of hundreds of users needed

Learn about system’s data and its transformation


Representing requirements:

Narrative (written) English

Program Design Language (Structured English)

Decision tables

User requirements

System requirements

Use-case diagrams

Formal specification

Often ambiguous sorarely used (but see Slide 6)

Brief instructions within “begin-end”, “if-then-else-endif”, “repeat-until” structures

“Actors “ and their “roles”

Where values of several conditions decide action to take

Formal specification (provable)

Sequence diagramsGraphical picture of sequence of messages between objects


Program Design Language(prev. Structured English)

Embed precise English-language statementswithin structured program design statements

REPEAT UNTIL activate_switch is turned off reset all signal.values and switches; DO FOR alarm.type = smoke, fire, water, temp, burglar; READ address[alarm.type] signal.value; IF signal.value > bound[alarm.type] THEN phone.message = message[alarm.type] set alarm.bell to “on” for alarm.timeseconds PARBEGIN CALL alarm PROCEDURE WITH “on”, alarm.time in seconds; CALL phone PROCEDURE WITH message[alarm.type], phone.number; ENDPAR ELSE skip ENDIFENDREPEAT

Requirements Engineering (16): Decision Trees

Action Policy for Book Sales & Dispatch:

Educational Institution

Other: 0%

<= 4 packages: 10%

> 4 packages: 15%

Order value <= €200: no insurance

Order value > €200: Insure

Conditions Values

Educational institution

No packages < 4

Order Value > €200

Y, N

Y, N

Y, N

Educational institution

No packages < 4

Order Value > €200

Conditions Rules

Y N Y N Y N Y N

Y Y N N Y Y N N

Y Y Y Y N N N N

Actio

ns 0% discount

10% discount

15% discountInsure YY

YYYY

Y

YY

YYY

An online book sales company needs to specify what are the rules for sales orders to determine discounts and whether or not to charge insurance .

Note that a condition may have more than 2 values:

e.g.“postal zone” could be

- A = Ireland & UK - B = Rest of Europe - C = Rest of World

therefore 3 values

No. of rules = No. values for Condition 1 x No. values for Condition 2 …. x No. values for Condition n

Requirements Engineering (17): Decisions Tables

Look for – impossible rules; indifferent rules.(example on white board


Use Case Diagrams – Representing Process by Actors and their Roles

Use Case Diagrams (part of UML) provide a means of representing required functionality by depicting part of a system in terms of actors (the “things” that the system interacts with) and use cases (the services or functions that the system should provide.)

Use Case Diagrams are not intended to represent sequence, iteration or exception behaviour.

Structured text specifications (PDL style) can be developed for each use case diagram.

One use case diagram can be used to represent all the functions in a specific part of a system or else to represent all the functions relating to a single actor.


Use Case Diagrams Notation

Actor 2 is a more specialised instance of Actor 1

Use Case 4 is a more specialised instance of Use Case 3

The execution of Use Case 2 always includes the execution of Use Case 4

Use Case 5 is a special case of Use Case 2


Use Case Diagram Example


Sequence Diagrams

Sequence models are diagrams that represent the sequence of objectInteractions that may take place for a particular subset of actors and objects


Formal specification (1)

The Z specification language allows the description of a system (or part of) in terms of states and operations.

In its simplest form a Z specification consists of :

Given sets, data types, and constants

State definition

Initial state

Operations

Use of Z requires knowledge of set theory, functions and discrete mathematics



Some definitions:

Predicate A statement about something which returns a True or False result

A schema (in Z) Variable declarations + list of predicates that constrain the possible values of the variables

P The power set (the set of all subsets of a given set)

The intersection of 2 sets (the elements that they have in common)

The union of 2 sets (all elements in both sets – without duplicates)

Is a member of a named set

An operation which changes a state

Is not a member of a named set

{set name}’ The new state of the set called {set name}

Logical AND

Logical OR

Also -

? = input variable

? = output variable



An elevator system has 4 subsets of the type Button:

the floor buttons,

the elevator buttons,

buttons (the set of all buttons), and

pushed (the set of all “on” buttons - buttons that have been

pushed).


Formal specification (4) Declarations of data,state definitions

4 subsets of the power set Button

The sets of floor_buttons and elevator_buttons have no common (shared) elements

The sets of floor_buttons and elevator_ buttons constitute the set Button

(From Schach, 2007, Object-Oriented & Classical Software Engineering)



Value of input(?) button must be member of set buttons

AND

input button is NOT a member of pushed button set

AND

set of pushed buttons is updated to include button?

OR

if button already a member of set of pushed buttons then the new state of pushed is the same as the old state

(From Schach, 2007, Object-Oriented & Classical Software Engineering)



Z specification allows definition of data, preconditions, relationships between states and between sets, and postconditions.

Correctness is provable mathematically. Software tools exist to prove the correctnessof a specification in Z (or in other formal specification languages)

Writing Z specifications forces the specifier to be extremely precise.

As a result of this need for exactness, it has been found that Z-specifiedrequirements have fewer ambiguities, contradictions and omissions than with Informal specifications.

Therefore, using a formal specification method (such as Z) can havedefinite advantages even if “proving correctness” is not done.

requirements engineering (1) re is the process of establishing the services that the customer...

Documents

types of requirements

system requirement slide

system constraint

library system

example of system requirement

system services functions

external file type

type of external file